[austincheney]

> The DOM is also very slow.

https://news.ycombinator.com/item?id=22391509

> I still have people argue with me that the DOM is slow even though all the evidence and browser vendors claim updates to the DOM is simply switching a bit in memory. In other words many web developers have utterly no idea how their platform works.

I guess not much has changed in 25 years. Most developers still fear the language, have no idea how it works, and will do everything in their power to pretend this language is some other language.

> ever tried to make your own UI framework from scratch only using low level GUI calls? z-index, styling with CSS, screen-reader support, etc.

https://news.ycombinator.com/item?id=22321333

[z3t4]

I meant creating a GUI from scratch. Creating a GUI using the DOM is easy. Working with the DOM overall is simple. What I mean is that the DOM do so much work for us (that we take for granted).

What I mean by slow is for example adding a element to the screen, or updating some text. Compared to for example everything that happens on the screen in a 3d game.

I do everything using vanilla JS and I cannot understand why anyone would use a web framework, (although most web project does). I do however have a vague memory that the learning curve was fairly steep, as I have been working with vanilla JS for over 20 years. (whereas the average developer has only used JS for one year) it wasn't until I started to use JS full stack (with Node.JS) that I started to like it!

[piva00]

I worked with vanilla JS for some time (before Prototype.js or jQuery existed) and used a bunch of incantations of different libraries and frameworks over the years and I cannot understand why anyone would choose to use JS for platforms where you can use any other language (aka... any platform that isn't a browser).

No construct or design decision of JS is better than in other languages, the lack of a basic standard library hurts a lot. Dependency management was inexistent until recently, the same for a lot of basic constructs, data types and other utilities that should be baked into any modern language.

The current landscape of JS is so convoluted and with such a varying level of quality that is intractable for me just trying to get things done without getting into the community and everything around it, it's not an easy tool to use and it's not an ergonomical one.

I have used JS for the past 15+ years for different kinds of software and I dislike it, not intensely but I'd never choose to work solely on JS. Yes, you can be productive in it but there are much better tools for most of the job it does around, its only power was to be the only language you could use to script a browser and I hope that WASM kills that.

[austincheney]

JavaScript has taught me that there are only two things separating a novice programmer from an excellent programmer: writing and data structures.

In order to improve as a programmer over the years I have had to learn to improve my writing. This requires a clear vision before putting keys on a keyboard and a solid sense of organization. You should know what you are going to work on with a strong confidence on how to go about it before doing any of the actual work. Sure rough spots will emerge along the way, but that shouldn't stop you from solving for the original vision. Then once the original vision is achieve refactor, debug, and refactor again. In writing that is call drafts and second opinions. This applies to any programming language equally.

A confidence of data structures is also critically important. Once skills and conceptual mental modeling of data structures becomes as common as spelling your name algorithms and logic almost write themselves. JavaScript does some things right by providing simplified data structures (objects, arrays, sets, maps, and such) and is really expressive in how you use them. JavaScript also does a lot wrong in this regard with its loose typing and some of its sloppy conventions. Fortunately, TypeScript interfaces coupled with consistent use of strict type declarations close many of those gaps.

---

I have heard so much hope for WASM killing JavaScript over the last 3 years, and almost all of it based on ignorance of how the technologies work. So much of this hope hinges on the availability of the page's DOM to a WASM instance by people who have never written to the DOM and have no idea what they are really asking for. While the WASM working group says this will never happen I suspect that very simple technology reasons will get in the way first regardless of what anybody wants.

If, however, WASM does replace JavaScript because the page's DOM becomes available to a WASM instance I suspect it will be the same clusterfuck that those developers were hoping to replace. I suspect if those developers couldn't figure out the relationship-oriented tree structure of the DOM using JavaScript they fail all the same when using their favorite language.

I can understand replacing JavaScript for other reasons, but rarely (extremely rarely) are the well grounded reasons ever a primary motivation for wanting JavaScript replaced.