31–40 of 69 posts
That said, one of the major problems is that there is no clear explanation for these boundaries in the tooling and code. Yes, you can `npm install lib` and unless it is documented in readme, it won't be obvious will this run in node only or in web too.
And as developers we tend to like the next thing and complexity
I guess it starts by abusing a document system to develop interactive applications instead of using an actual application SDK.
I guess it starts by abusing a document system to develop interactive applications instead of using an actual application SDK.
This is the entire reason. HTML, JS, and CSS weren't designed for their current purpose and updating them requires slow coordination across browser developers. Once you start using compile-to-JS and get out of the JS ecosystem mess, the developer experience suddenly feels much less complicated.
The easiest approach I've ever worked with is vanilla JS. But of course, building complicated stateful apps without a view layer like React is its own complication.
I guess it starts by abusing a document system to develop interactive applications instead of using an actual application SDK.
That just explains why do we know about that complexity. Alternatives aren't less complex (and when you need some niche features W3 supports like printers and BT you're in deps hell -- at least you're operating without node.js), but data flows more linearly from server to client.
E.g. supporting printers there is just no issue. But maybe I misunderstood what you meant.
It is rather simple why: Frontend is not linear programming, most backend actions are single-flow (on A do B), in frontend at any point the user can interrupt things, which calls for state management. Most backend applications are stateless and state management is outsourced to a database which does the heavy lifting. So the complexities are in scaling. Maintaining a complex frontend application is akin to maintainin…
I will say that some of the complications he mentions are from web apps needing to compile down to a single executable, on a platform that only really supports one interpreted language. Perhaps WASM will help here, over time.
I don’t know which, if any, nodejs alternative will succeed it, but if say Deno were to do so, the stack would be immeasurably simpler.
Right now, hopping between 2 different JS projects both of which do the exact same thing, means you may have to learn completely different build processes, completely different minting rules, completely different typescript compilers, completely different module import syntaxes/formats/configurations, completely different test runners, test description languages, etc. completely different standard libs (one may have lodash while the other is importing individual functions from npm), etc.
Heck, even your nodejs may not be nodejs but rather could be yarn, pnpm, etc
I believe nodeJS’s decision to essentially outsource all basic functionality while the JS ecosystem figured itself out was a huge reason for its success, but now that many things are more established, it’s causing a lot of unnecessary complexity.
It is rather simple why: Frontend is not linear programming, most backend actions are single-flow (on A do B), in frontend at any point the user can interrupt things, which calls for state management. Most backend applications are stateless and state management is outsourced to a database which does the heavy lifting. So the complexities are in scaling. Maintaining a complex frontend application is akin to maintainin…