JavaScript

React has introduced hooks to replace classes. Some people are huge fans, while I am a bit more skeptical. An explanation.

Many popular npm packages depend on 6-8x more packages than they need to. Most of these are unnecessary polyfills and it's one of the key reasons node_modules folders are so large. The eslint ecosystem seems to be most affected by this.

It is now common knowledge that in 1995 Brendan was given only 10 days to write the JavaScript language and get it into Netscape. Date handling is a fundamental part of almost all programming languages, and JavaScript had to have it. That said, it’s a complex problem domain and there was a short timeline. Brendan, under orders to “make it like Java” copied the date object from the existing, infant, java.Util.Date date implementation. This implementation was frankly terrible. In fact, basically all of it’s methods were deprecated and replaced in the Java 1.1 release in 1997. Yet we’re still living with this API 20 years later in the JavaScript programming language. ~ https://maggiepint.com/2017/04/09/fixing-javascript-date-getting-started/

#javascript

I am used to Java/Maven which has a command "mvn site". This lifts project information, documentation and analysis to build a website like this.

What are people using in Node.js projects?

Every so often I remember how messy it is to be in the #JavaScript ecosystem. Updating from #React 16 to 17 also requires updating #ESLint which requires updating its plugins (fuck you #AirBnB ), which requires you to update #webpack and it’s loaders/plugins, which requires you update #Babel. This doesn’t even account for any other random libraries you’re using so even then you’ll still end up getting #npm peer dependency errors.

Please tell me there’s a better way…

[This was originally one of my posts on r/javascript from 2 months ago. Aside from the first few sentences, no edits have been made to the contents of the post.]

I'm playing around with concepts for a Javascript-inspired programming language, and I was met with a design decision:

When destructuring an object, should we pull from the object's entire prototype chain, or only the own properties (not inherited from the prototype chain) of the object?

In other words, in the equivalent to this line of code:

let {a, c, ...rest} = {a: 0, b: 1, __proto__: {c: 2, d: 3}}

Should [a, c, rest] be [0, 2, {b: 1, d: 3}], or should it be [0, <not assigned>, {b: 1}]?

On one hand, we probably don't want to pull from the object's entire prototype chain. Imagine if, after executing let {a, ...rest} = {a: 0, b: 1}, Object.hasOwn(rest, x) returned true for x = isPrototypeOf, toString, valueOf, etc and all of those properties were just the same functions as the ones on Object.prototype. And imagine how inefficient destructuring would be when we have long prototype chains with many properties on each prototype.

On the other hand, in something like let {a, b, c, d} = {a: 0, b: 1, __proto__: {c: 2, d: 3}}, we probably want c to be 2 and d to be 3, the same way <rhs object>.c would be 2 and <rhs object>.d would be 3. So we would want to pull from the entire prototype chain after all.

I decided to look at how Javascript itself dealt with this stuff (not what I actually put into the console, but it gets the general idea across):

>>> let {a, c, ...rest} = {a: 0, b: 1, __proto__: {c: 2, d: 3}}; [a, c, rest.b, rest.d]
[0, 2, 1, undefined]

It turns out that Javascript uses a hybrid approach: for ordinary properties like a and c, it searches the entire prototype chain. But for rest properties like ...rest, it only uses the object's own properties.

I wasn't expecting this inconsistency between the two types of properties, but it makes sense: each individual type of behaviour is probably what you want for the corresponding type of property. You would want to search the entire prototype chain when it comes to ordinary properties, but at the same time you would want to only look at the object's own properties when it comes to rest properties.

What do you guys think? Does Javascript handle this the right way, or should it have chosen a different approach? Maybe there's another, better option than all three of the approaches that I outlined here?

Post-mortem report for the Deploy outage on June 25th, 2023.

The primary need for the project was to make it faster (less button clicks) to resize images before uploading to websites. It has a super-optimized workflow that has size presets and auto-downloading baked in.

This one had me doubting if I had the logical thinking skills to learn how to code, and I am still doubting it, but I completed the project nonetheless.
VIDEO

#html #javascript #css

I am really proud of how it looks! Try it out: https://minnie.untone.uk/passwordgen.php

VIDEO

#css #frontend #javascript #html #webdesign

Unlike my past gallery which has similar code and took me hours upon hours upon hours,,, this took me about 2 hours in total. Still a lot! But taking into account designing the visuals and then the code I am a super beginner with, it makes sense. This marks like day 4 of my JS, CSS, and HTML journey C:

VIDEO

#javascript #html #css

I began learning JS abt 2 days ago. I watch a combined 12 hour course, but I went in feeling like I never saw JS in my life. It took me several hours of fiddling, looking things up, and skimming the course video until I managed to make the gallery. I am so excited to make more projects using #JS, #HTML, and #CSS!

VIDEO

GALLERY ON SITE

#javascript #frontend

I'm working on a personal project, https://www.packetradiomap.com. I need to npm install and npm run build but I'm getting this error:

@parcel/core: Failed to resolve ol/control/Control from ./node_modules/sidebar-v2/js/ol5-sidebar.js

I'm using this package: https://github.com/Turbo87/sidebar-v2 in my project, along with OpenLayers 5.4.

Previously, to get sidebar to work with OL, I've had to add this line to node_modules/ol/control.js:

export {default as Sidebar} from 'sidebar-v2/js/ol5-sidebar.js';

That would get things working. But now, I get the error mentioned in the title:

`@parcel/core: Failed to resolve 'ol/control/Control' from './node_modules/sidebar-v2/js/ol5-sidebar.js'

C:\Users\username\WebstormProjects\PacketMap\node_modules\sidebar-v2\js\ol5-sidebar.js:2:21
1 | // JS imports

2 | import Control from 'ol/control/Control';
| ^^^^^^^^^^^^^^^^^^^^
3 |
4 | export default class Sidebar extends Control {`

ol/control/Control definitely exists. Does something need to be changed?