> From backend ORMs and headless APIs to frontend site generators, package managers, and build tools—it's a miracle any of it actually works properly in production! I think the issue is clear from this first sentence. Why are there any of these things in javascript ? The marvel is that in 2021 such a sentence can be written -- that these things are immature seems both obvious and to miss the point.
So engineers only have one language to absolutely master. This really hit home: Trying to recruit a Java + SpringBoot + Angular engineer is 1 order of magnitude harder than a NodeJS + Angular engineer.
The Shocking Immaturity of JavaScript
71–78 of 78 posts
Re: The Shocking Immaturity of JavaScript
#72Earlier quoted context omitted.
I can easily build a table in HTML with 70k cells (100 columns, 700 lines, it does happen, and users prefer that when getting an overview of their project), but in React, it takes 15s to render. Setting the innerHtml takes milliseconds.
Just use something like react-virtualized. Problem solved
part of it is that after all react is a library and not a compiler (which is good per se, I like that you could use react with only vanilla .js and .mjs files or even once big HTML file) which means that for the react runtime components are black boxes and cannot be statically analyzed nor statically optimized.
in the case of a table with 70k rows, even if the component only returned one jsx without any computation react would have to run the same diffing algorithms (this could be solved with a useMemo, but not always)
Re: The Shocking Immaturity of JavaScript
#73Earlier quoted context omitted.
I am talking about DOM manipulation operations such as creating and updating elements. See my other comment. React does not query the DOM at all (almost), so query speed is irrelevant
DOM operations are just a few common methods such as: appendChild, removeChild, setAttribute, getAttribute, removeAttribute, createElement, createTextNode. These were slow when injecting massive quantities of new nodes more than 12 years ago. Now they are fast. If you are that concerned with speed then just produce everything in a document fragment and when ready inject the document fragment into the document. Bottle…
I believe I am not exactly "know what I am doing" at least when it comes to implementation, so I would enjoy some clarifications
Re: The Shocking Immaturity of JavaScript
#74If top level tools devs interacted with bundled more of their deps things might be less likely to break, at the cost of a bigger node_modules folder.
Right now you occasionally run into situations where Webpack or ESLint stops working right because is-even released a bad patch update.
Re: The Shocking Immaturity of JavaScript
#75Earlier quoted context omitted.
>The often unmentioned killer feature part of js is that you can express tree data directly This is the case in almost all well-used programming languages. Calling it a "killer feature" is a bit of a stretch; it's more an expectation.
You are right. I was thinking of Java, C, C++, and C# but my knowledge about the last ones was outdated (long ago) https://stackoverflow.com/questions/138600/initializing-a-st... https://stackoverflow.com/questions/15501202/c-sharp-nested-... IF you are happy with some constraints or the syntax exploding with every level of tree depth added: public Dictionary > info = new Dictionary > ....
using dic = System.Collections.Generic.Dictionary;
Otherwise you can use an anonymous type: var person = new { name = "frank", address = new { city = "Berlin ", zip = 12345 } };
In this case you get a plain object, but all fields area read only.Re: The Shocking Immaturity of JavaScript
#76Earlier quoted context omitted.
DOM operations are just a few common methods such as: appendChild, removeChild, setAttribute, getAttribute, removeAttribute, createElement, createTextNode. These were slow when injecting massive quantities of new nodes more than 12 years ago. Now they are fast. If you are that concerned with speed then just produce everything in a document fragment and when ready inject the document fragment into the document. Bottle…
how do you replace event listeners? attach all of them at the document root and wait for bubbling/capture? attach single event listeners somewhere and then dispatch manually? use onclick="..." attributes? or maybe are you referring to native functionality like actually using semantic elements and using links and forms for page actions (with a service worker I believe you can make a nojs website quite interactive even…
* Event - an asynchronous action, possibly but not necessarily the result of human or network interaction
* Handler - a function that executes instructions upon the event
* Listener - an abstraction layer to bind handlers to events using an allocation pool and not assignment. One handler may be provided to multiple listeners and one event may receive multiple listeners
* Callback - A function provided to a handler such that instructions not associated with the event are executed via reference
You can assign a handler directly via a DOM property:
myNode.onclick = myHandler;
In this case there is no listener. There is a node, an event, and a handler only. The handler is implicitly provided an event object as its argument (if not explicitly specified), which in turn provides all the identity necessary for the event and node without further abstraction or external assistance. The node identity is `event.target` and the event identity is `event.type`.The limitation with handler assignment is that only one handler may be simultaneously assigned. This is bad when your media/analytics team, who has no idea what they are doing, installs a bunch of third party spyware on your business site without permission that wants add a bunch of data tracking to every user interaction.
The benefits of handler assignment are: guaranteed garbage collection bound to the assigned DOM node (and more specifically the actual event if the event is reassigned a different handler), code simplicity (forced), no listeners.
A listener allows association of multiple handlers to a single event and/or reuse of a single handler to multiple listeners.
The problems with listeners is that they wildly complicate code and the respective handlers are difficult to garbage collect. As the given node is removed from the document the best practice is to manually call `removeEventListner` on each listener associated with the DOM node. Garbage collection is difficult for these handlers because there is no clear relationship between them and their corresponding events. The risk of not garbage collecting resources is that the application grows in memory with every event interaction, often unnecessarily duplicating allocations, until the application fails. Performance is also impacted in a logarithmic fashion as the stack size increases. This is called leakage.
Frameworks attempt to solve some of these problems with handler/listener allocation, but they aren't universally successful and it is challenging to measure how unsuccessful they are as it varies by instance.
Re: The Shocking Immaturity of JavaScript
#77Earlier quoted context omitted.
You are right. I was thinking of Java, C, C++, and C# but my knowledge about the last ones was outdated (long ago) https://stackoverflow.com/questions/138600/initializing-a-st... https://stackoverflow.com/questions/15501202/c-sharp-nested-... IF you are happy with some constraints or the syntax exploding with every level of tree depth added: public Dictionary > info = new Dictionary > ....
You can define type aliases at the begin of the file to reduce verbosity, as example: using dic = System.Collections.Generic.Dictionary ; Otherwise you can use an anonymous type: var person = new { name = "frank", address = new { city = "Berlin ", zip = 12345 } }; In this case you get a plain object, but all fields area read only.
Re: The Shocking Immaturity of JavaScript
#78Earlier quoted context omitted.
This might worked on solo projects but if you’re working with people, I’d highly recommend enforcing type checking of some sort. People will ignore the IDE error messages.
> People will ignore the IDE error messages. Then they get caught in code review at least in any team I work. No way I accept any unnecessary "disable lint" statement in a PR. Also (of course, since it is default) the CI build system breaks if they commit and push without ignores, so no, trying to slide it past me doesn't work either.