Hacker News Reader

Comment by genmud | Hacker News Reader

I might be going against the grain here, but the JS ecosystem is just a series of goalposts that are constantly moving and it has burned so many people over the years that folks just don’t want to deal with it.

I’m fine learning JS, but with the ecosystem it isn’t just learning JS. It’s learning the new hotness for packaging / versioning, it’s the frameworks that are constantly in flux, it’s the inconsistent abstractions that seem to be mercurial and constantly changing.

If we were to sit down and write some frontend code to say, make a simple kanban board every 9 months using “current” JS best practices or popular frameworks over the last 6 years…

How many different tools might you run across?

How easy would it be to take that 6 year old code and bring it up to modern standards?

The reason you see people allergic to the JS ecosystem is because it is incredibly opinionated while simultaneously being a free for all.

View on HN

What I hate is that you don't even write JavaScript anymore.

You write fantasy future JavaScript. Sure, it will be available in ECMAScript 23, scheduled to drop in real browsers in 2092. But for now, here's a convoluted mess of polyfills, Babel, and WebPack, that we HOPE papers over the real behaviour of browsers, and suddenly your test-and-debug cycle has introduced a flow-shattering 15-second build cycle each time you change a file.

There's actually no need for that anymore. JavaScript as is supported right now in the latest Chrome, Firefox and Safari is already pretty good. You can get quite far without any backend tooling these days.

The only thing which I believe is still needed is a bundler when your project grows to a certain size. Fetching a complex graph of thousands of files will likely never be fast.

> The only thing which I believe is still needed is a bundler

And a type system... And maybe a styling system... Oh and let's have some nice Rx data flows!

But, jokes aside, even if you go that Route you still end up with a complex npm project that involves dozens of libraries.

I've been at that point every year since starting doing npm spas in 2014ish (mostly as side projects, my work is typically more serverside). At some point I just decided that the upkeep wasn't worth it any more as you create the same stack every year but with wildly different libs. For me the solution was to switch to an elm+sass+webpack boilerplate that hasn't changed since 2018 or there abouts.

Even bundlers can be pretty stupid and simple. I still just use r.js for even large apps. Webpack isn't hard to set up, either. But my frontend code has almost no dependencies... I refuse to deal with React, Angular, etc etc. I have a very nice, simple component-building / screen scaffolding system that's about 1000 LOC. You extend the component and load up some HTML and just work with it directly in JS when you want to update data, resize it, etc. There's no need for all these frameworks that try to plant logic back into HTML. I love having the HTML templates pure and the logic unbound from them.

Do you still use gulp or is it webpack nowadays?

Gulp is extremely out of date these days.

Using webpack resulted in some of the most painful experiences of supporting serious production software in my career.

The progress and maturity of JS tooling/DX as a result of stuff like esbuild and Vite, or Typescript more generally, can not he understated.

For people not doing frontend it can seem like a neverending series of new stuff but there is a very rational and tangible level of progress being made. Especially for serious JS devs not jumping on hype trains.

I don't miss the days of gulp and webpack at all and I don't blame anyone for hating on JS if they experienced using them professionally.

> Using webpack resulted in some of the most painful experiences of supporting serious production software in my career.

I never invested too much time in understanding webpack but it does feel like fighting it a lot of the time when I want to change something in my personal projects.

Care to share some anecdotes of those painful experiences?

Gulp / Babel and then transition to webpack was my introduction to JS.

Now Vite seems to be all the rage? But is it a bundler?

Wepack seems to be very hard to configure. Looks like nginx config vs caddy config.

Tools such as babel, webpack, esbuild, postcss, etc. are now considered a bit low-level, and usually do not need to be set up manually these days.

Rather, one would opt for something like vite, the spiritual successor to react-scripts, that bundles all of these tools together with some good defaults/plugins, a means to configure them, and usually also some kind of dev server with hot module reloading, for a complete developer experience using your preferred toolchain.

Check out 'parcel' for something pretty modern, universal, and low effort, IMHO.

It's JavaScript. Everyone is moving on to Turbopack. Or Vite. Or ESBuild. Or Bun.

I definitely like the batteries included and speed of bun.

Please don't tempt me.

You're outdated. Everyone is using Parcel now.

Funny, how even the sibling comment states something different. Maybe there are a lot of bundler bubbles in the JS world?

sorry, I said that 9 hours ago... now we're using Bun actually :D

With evergreen browsers, you can write modern JavaScript and it'll run in the browser just fine. And it's not like TC39 is pumping out lots of wild changes. The largest recent change is what, top level await? That's not exactly a wildly different language feature.

A lot of this JavaScript criticism was appropriate circa 2017, but these days JavaScript's gotten a lot more stable.

Sure. With evergreen browsers. For anyone using old devices with outdated hardware--tough luck! They can, I guess, go buzz off and leave you in peace to write Modern JS. After all, that's the most important thing.

At this point you'd need a 10 year old never-updated browser to run into this issue. Which, sure, maybe you need to cater to people who use browsers 10 years out of date. I don't think it's a huge market frankly and 10 year old browsers have larger issues like security.

I mean, JavaScript doesn't just run in browsers. Some older forms of JavaScript run in all kinds of software--embedded in Windows (JScript), embedded JavaScript engines in other runtimes (Java, Qt Quick), older Node.js software that people are stuck on for whatever reason. I'm sure many people don't care about making all of those devices obsolete but maybe with a slight amount of effort we can try to slow down the inevitable filling of landmines with perfectly workable devices?

Okay, those cases seem like situations where you'd need to be explicitly targeting those devices. Like if you're shipping new code to users that is being run on an old runtime, then sure, you should make sure that code is legacy JS. I don't see how that is unreasonable?

This is my problem with a lot of HN comments about JS: they read like they were written in 2014 (see also the “a new framework every week!” jokes)

ES2015 was the one big language update, and although it took a while to all roll out and for older browsers to die off, at this point we’re now living in “the future” and almost all language changes are incremental.

Like, you can write ES modules with async/await and run it in all modern browsers without any compilation. If you add an HTML import-map element you can even import node_modules by name.

Now, most people still prefer to use a bundler so that their users can load a single script instead of dozens of tiny ones, but that’s optional, and the gap between “the code you write” and “code that runs in the browser” hasn’t been this small in years.

Part of it could be different audiences.

Not everyone is on a greenfield project with full authority to grab the freshest and latest. Some of us are effectively living in 2014-- they can't say "no, you can't use IE11" to paying customers, or committed to a platform at the wrong phase of maturity, and remain stuck around a state-of-the-art-in-2014 build process.

Out of curiosity, what features are you using that aren't already supported by all major browsers?

Maybe the tail-call optimization?

The "new hotness" only matters if you're going to try and get a job as a FE dev in a large team. The "old hotness" still works, and likely has the more obscure bugs worked out of it.

And you can always just write the thing in JS without any hotness at all. The JS ecosystem's obsession with frameworks is a diversion. You really only need a framework if your site is super complex. And even then, if you're careful about how you write your JS, you may not need a framework (you'll end up creating your own, probably).

I'm with you that the JS ecosystem is a seething mess, but I don't think that's actually a problem unless you want a job as a FE dev. You can just ignore it ;)

This.

90% of the toolchain is not required at all. Just quality of life improvements.

Good ES6 (and TS) idiomatic code feels actually closer to reading Scala than reading a legacy Jquery app.

And the V8 engine has so much investment in optimizations today that is actually closer to Java and in some cases lighter than Go.

IMHO people don't hate JS in reality. They hate the strawman made of the worst parts of Junior code ever encountered and inconsistencies that really don't happen in practice unless you actively look for them.

Same could be said for php…

I usually oppose the use of any new "hotness" in a project until that "hotness" is ~10 years old.

This is a great post. I'm not a web dev myself, but I have a couple on my team. I criminally underrated the challenge of maintaining a complex web app. It is madness: endless incompatible, forced upgrades.

Real Question: Why does this ecosystem have this issue, but others have it less? For example: Why doesn't Python or Java have the same madness?

Please don't read the question as criticizing web dev / JavaScript / etc. My curiosity is genuine.

To be fair, it does feel like C++ is more maddening than Python or Java, but part of can be explained by (1) native code generation (build is way harder than languages that run in a VM) and (2) the insane complexity of the language which _traditionally_ made IDEs much weaker than other languages. MSFT Visual Studio and JetBrains CLion have come a long way. (I can already feel the HN pitchforks poking at me for these C++ comments!)

Because the originals parts where broken. I am speaking of 90s JavaScript, the DOM/Browser API and the not so much "batteries included". They could neither get fixed without a standard by committee approach of the browser vendors.

So we started to compensate: end state: Typescript to fix JS, React/Angular/Svelte to fix DOM API and a npm package hell to have batteries included. And all of that bundles, compressed, etc to have a good download time.

Yes. When JavaScript is your only option, the only solution to JavaScript is... more JavaScript :(

Seems like the old joke about XML:

"XML is like violence: if it doesn't solve your problem, you're not using enough of it."

I’m pretty sure you can continue to use jquery and everything still works fine :D

I’m over here continuing to use react for 9+ years but every post on here acts like it’s changing every day.

Classes? Components as functions? Classes again? Hooks?

Classes still work fine if you want to keep using them.

This doesn't appear to be what the docs recommend anymore, which is exactly what my (obviously flippant) post was meant to highlight.

Hooks were introduced five years ago and have been stable since then. So that's half a decade with no changes to the API.

Great! I bailed in the first four years I guess, after the fourth change in API.

https://www.youtube.com/watch?v=pd8kWJVDQD4

As a Vue user things have changed a lot.

I think this comment is a bit out of date, especially if you’ve been watching JS from a distance for the past couple decades. This would’ve been true circa 2014. In 2023 it’s obsolete.

There’s one framework that won, that’s all you have to learn, as far as the industry goes (as opposed to hobbyists) it’s been decided. React won. React is the framework you learn.

“Popular frameworks for the past 6 years” - React has been dominant over that entire time period, from beginning to end. React is what you would’ve reached for 6 years ago (it was already mature then, in 2017) and it’s what you’d turn to now. This is what I mean. You could update your React code to use hooks instead of classes - or you could not, it will continue to work if you don’t.

The “JS changes all the time” take is frankly out of date in 2023. “Which framework do I learn…” you learn React, the framework that won. It’s pretty much that simple.

That’s a bubble. You are in a bubble. React is dominant, sure, like the US is dominant, but it’s not The World.

The important part is that it's a bubble you can choose to live in. Companies everywhere use React and almost no one need ever choose to learn something else. As long as you know it you will be employable for another 20 years, just like with Java.

But people in that bubble keep shaming people who aren’t… and react keeps changing, so it’s not like you learn it once, it requires careful study and understanding of all the different permutations that are used in different environments.

You generally can’t go from company A to company B who both use react and have the same calling convention, code structure or tool chains even though they are both using react.

Ouch, 20 years? I sincerely hope so for their sake, but I wouldn’t bet 10 dollars on it.

20 years is very optimistic; React is already losing users: https://2022.stateofjs.com/en-US/libraries/front-end-framewo...

Retention shows a clear trend for all frameworks and even in general conversation Solid.js has been taking up more and more of peoples' attention with signals.

The compound advertisement of hearing about Svelte and why it's always going to be faster than React because of not having a VDOM along with Solid.js will make a dent in React and it will become the next Angular. 20 years is not going to happen.

I don't use React.

Only VanillaJS.

And my clients are happy it seems.

So React clearly isn't the only choice, unless you're a new graduate with no clue about anything, then sure start with React.

Hard disagree… react is probably one of the best examples of this. React 15/16/17/18 over this period of time is a nightmare to maintain for people who don’t keep up with react if they want to casually jump in or out of.

If you built an app in react 16 and wanted to upgrade to 18, using the documentation it almost resembles 2 different frameworks. Sure, maybe the code executes, but all the js devs would be like “why did you write it like that”?

> React won. React is the framework you learn

So nobody should learn AngularJS any more?

Nope.

htmx is another tool just like that, another goalpost in the frontend webdev world. It's just happens that the most recent hype is "don't write JS", but fundamnetally it's no different. Just another framework/library that has gotten some traction. In a few years we'll be back full cycle and it will be in vogue to write JS again, probably because htmx and associated projects have grown to complex.

A key difference is the promise to be working even without JavaScript.

It's no different from anything else. The promise if every framework is to abstract away some low-level details. Whether that means writing "higher-level JS" like jQuery did many years ago already, and hundreds of other frameworks do today, or inventing some new DSL like htmx does that translated to JS internally. No difference.

"Htmx is a dependency-free, browser-oriented javascript library."

https://htmx.org/docs/#installing

The framework itself is written in Javascript

The end user is NOT writing Javascript.

> I might be going against the grain here, but the JS ecosystem is just a series of goalposts that are constantly moving

Welcome to real life.

Beware the ecosystem that does not change (COBOL).

Reply on news.ycombinator.com