Hacker News Reader

Frontend JS frameworks have been a meme for a while now.

I think it's a combination of the front-end needing more boilerplate than back-end, and developers struggling with accounting. Maybe your cool new framework will save you 10% dev time, but you'll lose that 10% ten times over with the learning and error-bashing you and your teammates and future team members will have to go through.

My policy is that you can use pure JS where a framework is overkill (I'll also accept jQuery), and React otherwise. React has emerged as the winner, and trying other things isn't worth the cost if you're paying (which employee developers are not).

I recently built a small app using pure JS, just to remind myself how it used to be. It's definitely too verbose to avoid frustration. But HotNewFrameworkX vs React is never going to be big enough a benefit to be justified.

I'll just leave this here for the ones who have convinced themselves that react is the winner (whatever that means): https://andy-bell.co.uk/the-extremely-loud-minority/

The winner means I can easily hire people who can develop on it from the get go, I can sell it without resistance, it's effective enough, and the business is aligned with productive output rather than technical oneupmanship.

I feel like comparing Wordpress to React/Vue is strange. Do people build web apps using Wordpress these days? I know you can make Wordpress do more via extensions (site builder, e-commerce), but it seems weird creating something original with Wordpress to me, but I genuinely don't know what Wordpress is capable of these days. In the sense of what Wordpress was made for and the extensions available for it, it checks out to me that it would dominate the web landscape.

As far as not blindly following the advice of web advocates, I agree - they live on the bleeding edge. Unfortunately these are the people the new and impressionable devs come across on social media and hold their words like gospel because look how many followers they have and look at who they worked for, they must be right! Web tech moves fast, especially the shiny frontend stuff, and that generates discussion and leads people to believe that everything else is obsolete when in reality it's not.

It's not the frameworks.

React and Vue for example have been super stable for almost 10 years, and they don't really need anything other than one or two packages to work. CDN + alternative syntax is enough to make React as boilerplate-free as jQuery. Add another package (htm) if you want the good syntax back.

The problem has always been the ancillary stuff: JSX, Vue SFCs, wanting to use "import from" in the browser, IE11 compatibility, testing, linting, converting CSS, removing typescript types.

For those things we need tools like Webpack, Babel, ESLint, etc. And those just aren't "as good" as React, Vue, or even Typescript. Some of them break compatibility constantly, need a lot of boilerplate, need pulling several packages to do the most basic things, are the source of frustration for a lot of people and the source of the overkill you mention.

IMHO think part of the issue is that a lot of those ancillary projects are optimizing for cases that aren't significant in practice.

As someone whose been in this space for a while, there are always new frameworks, new ways of doing things, new libraries and tools, most of it is just noise. Sometimes a new tool comes out (like Vite) that is a seismic shift, but for the most part that new framework or state management library really isn't all that much better than what we currently have.

My best suggestion to those developing JS apps is to not get carried away with the noise, pick a solid framework (React, Vue, Svelte, etc), pick some solid libraries, stay away from the experimental stuff, and just run with the tools you've got. There will always be a new tool around the corner that claims to be better than the existing tool, forget about it and stick with what you got, then revisit that tool if you hear alot of noise around it.

What’s special about Vite?

I used Webpack before Vite and always ended up with super complicated scripts for generating configurations.

With Vite everything just basically works out of the box with no or very little configuration. And it's pretty fast.

And it works with Rollup plugins, which are easy to write.

I agree with you but it might be due to my own ignorance.

I've done react, vue, and old school jquery and miss the days when javascript was just something you had a script tag for in your website.

"Building" js projects and all of the other weird ... garbage ... that gets thrown in is just totally frustrating. The best I have been able to manage is to use esbuild + react + typescript in a very conservative fashion to keep things manageable for someone like my self: has a life and doesn't want that life to be consumed by yet-another-new-node-js-build-this-perpetually-differently-and-forever-and-with-much-pain system.

> miss the days when javascript was just something you had a script tag for in your website.

What's to stop you from doing this now?

In fact, in between all the fluff in the article, mentions of browser support for ES Modules makes this pretty straight forward. I used it recently for a small repro and i was surprised at how well it worked https://idb-perf-repro.netlify.app

I must point out for the record that this problem isn't novel. Apologies for bringing up his name here, but JWZ labeled this phenomenon "CADT," the "cascade of attention-defecit teenagers" model of development, all the way back in 2003.

Probably because all tooling comes from open source developers that are simply not happy with the status quo and are trying to improve things doing what they can, see Webpack, Babel, Vite, pnpm

What we really need is an end to end echo-system with funding, adoption and vision. Deno and Bun are both getting in this direction

To paraphrase a trite and old SNL line: "Simple Modern JS from last year is neither simple nor modern. Discuss amongst yourselves"

Ala https://en.m.wikipedia.org/wiki/Coffee_Talk_(Saturday_Night_...

Give Elm a shot.

We haven't had a breaking change to the current version since August 2018: https://github.com/elm/compiler/tags In fact, the single most frequent criticism of our community is, "Is Elm dead? It hasn't been updated in years". The truth of the matter is that it's not dead; it's just really stable.

Everything still works. You can use a bundler, like Vite or Parcel, but you don't really have to. You can use whatever Javascript library you like, through ports or web components, but again: you don't really have to, unless you need to do interop with another service (i.e., Google reCAPTCHA or Stripe) - and in that case, you're at their mercy regardless of whether you're building your application in Elm, or in something else.

Compared to the rest of the JS ecosystem, we have virtually zero dependencies on outside tools or infra, other than Github; but if Github "goes away", I'd be willing to bet that the rest of the Javascript ecosystem would be in a lot of trouble, too.

We are a small but passionate developer community. Enough of us - myself included - do this full time for it to feel like it's a safe bet and that it's not going anywhere anytime soon. Join us. https://elmlang.slack.com/

Elm looks quite interesting, I may have to try it out. But I feel that for many JS/TS devs, it may be too much of a jump to move to a functional language.

> it's not dead; it's just really stable.

Am I the only one who thinks this idea is somewhat contradicted by the TODOs that are still in the official docs, and seem to have been for years?

> I have not seen this pace in other languages/environments. For example, in Python

It happens in Python too. For example in ML, in 2015 everybody was using torch, then Keras, then TensorFlow, then PyTorch.

Pandas now being replaced by Polars.

If you look at MLOps, every 3 months there is a new hot library.

In other words, it happens in the active parts of the ecosystem (data-science), not in the old stable ones (standard library, reading files, ...)

Just want to point out that polars is not a complete replacement for pandas and they will likely live side by side in the data ecosystem. One of the main and original intentions of pandas is replacing highly dynamic and changing excel models for financial, econometric and physical systems. The rigid structure of polars syntax while great for stability and optimization is not practical for research/development iteration of these kinds of models.

> It happens in Python too.

Python ML maybe. That's a different community to Python in general. The only place where there's been churn in general Python is probably package management.

10 years ago there was a new Python web framework every month. Now that space is pretty much stable (dead).

The fact that JavaScript front-end is going through so much churn just shows that it's not obvious yet what the proper design looks like.

Rust is going through the same thing now with GUI frameworks, every couple months a new approach appears. Because it's not obvious yet what's the proper design for a Rust GUI API.

> 10 years ago there was a new Python web framework every month.

That doesn't fit my recollection. Only Django and Flask had much mindshare.

> Now that space is pretty much stable (dead).

Do you mean stable or dead?

> Only Django and Flask had much mindshare.

That's the status today.

A few other major ones back then - Zope, Tornado, Bottle.py, Pylons, TurboGears, CherryPy, web.py, Werkzeug.

Zope was an oddity and had already started to fade into the background 10 years ago. Bottle was eclipsed quickly by Flask. Werkzeug was more of a toolkit than a framework.

Is Tornado even a web framework?

There was some interest in the others you mention but I don't remember them ever being major contenders.

I guess my point was that it never felt like the javascript situation where there was genuine paralysis of choice on many fronts. You generally either went Django or Flask depending on your preference for "batteries included". All the other choices were pretty niche.

Javascript has stabilized a bit in the last few years but the number of choices needed to start a project are still much higher than anything I experienced in Python web dev.

Django was the big one back then.

But it was not clear at all that Flask would be the other winner. There were a lot of articles discussing Flask vs Bottle vs web.py.

> like the javascript situation where there was genuine paralysis of choice on many fronts.

I think that's the perception from the outside. If you start a project, it's pretty clear what's the recommended stack of the day. Sure, next year might be different, but today it's React/Vite/Tailwind/...

I wouldn't say it's stable or dead. Starlette and FastAPI are great async frameworks that seem to have replaced Tornado. Django is only recently getting some async support.

JS frontend seems to have been going through churn for over a decade now. It's a messy language, and because we've been forced to use it as the sole frontend language for a while people have been trying to figure out how best develop with it. Hopefully, with more language support in Wasm, JS will finally be replaced.

It’s one thing that the “standard library for X” changes every few years. The problem is when upgrades within the same library are backward incompatible, or require changes in unrelated things (such as the build system), or when the library gets dropped completely from support.

> Libraries, UI frameworks, build systems, preprocessing tools, the JS community seems to have a knack for rebuilding everything from the ground up with almost zero backward compatibility with a frequency I haven't seen anywhere

The modern web industry isn't that old yet. Give it time. We've been writing C++ since 1985.

React is 10 years old. Vue is 9 years old. Angular is 11 years old. The only "real" new kid on the block is Svelte, which is 7 years old now.

The web constantly strives towards simplicity. React was developed because AngularJS was this huge enterprise framework of global state. React includes immutability to make things simpler. Vue was developed because its developers saw React (then with classes) as too complicated. It's loved to this day even by the HN crowd for its simplicity. Svelte again was developed because their developers saw the possibility to make updating the DOM simpler. Again, the HN crowd and its users love it, because Svelte really is dead simple. It's been my drug of choice for 2 years now and I'm seeing unbelievable productivity among friends and colleagues which choose to use it.

The amount of libraries you see can be explained because of JS huge open source crowd, perhaps the largest among any language. There is no controlling entity, so people are free to write their own open source abstractions. We as an industry should see this as a good thing, because there are mountains of code now available for everyone, free of charge with MIT licensing. Startups can write applications that reach millions and generate billions, without worrying about QT licensing costs or paying for a Delphi compiler toolset. They need one codebase for an application that runs virtually the same on every device, mobile, tablet or desktop alike.

> Another example, I recently had to upgrade a Vue 2 application to Vue 3, because Vue 2 is going EOL this year. Well, apparently that means I also had to change the build system from Webpack to Vite

Again, Vite strives for simplicity. Vite is so simple that it took the industry by storm. Gone are the days of webpack 4 era configuration files that made you want to rip your hair out. Vite was written by Evan You, the man behind Vue, which could give you an indicator of the quality of the tool.

I hate working on our C++ / QT enterprise product, because each change takes ages for me to see and verify. If that product was a web app (which we are currently looking into), I could see changes instantly, with application state persisting through recompilations.

Grizzled seasoned developers have longed for a native application toolset that runs on every device for decades. Some just miss that web browsers do exactly that, with the added benefit of being a near perfect sandbox. Of course it's not perfect (yet?), but perfect is the enemy of good.

Minor correction, Svelte dispenses with the Virtual DOM an algorithm for making DOM updates, not the Shadow DOM which is a completely separate browser construct for isolating subtrees in the DOM.

Thanks. I'm not an expert on Svelte internals, but I simplified my statement.

>>We've been writing C++ since 1997.

1985

Thanks. Little mixup there.

I won't try to guess the industry trajectory as a whole. But I can speak from personal experience. I've been on teams jump on the single page application bandwagon. React in particular.

It's been 5 years since initiating that investment. Reflecting on it I'm frankly amazed at the amount of technology that we don't need. The standard type of UI we build really hasn't changed but the time code and overall cost continues upward.

Looking back to 2018 we might have been collectively beguiled by the self-perpetuating marketing machine of single page application technology. We've decided unless there's a very clear and specific justification to write a thick client on a web page we're avoiding it going forward.

Tools such as HTMX are perfectly effective substitutes at far lower cost. At least for what we need

It sucks. But part of the reason is ecosystem shift.

commonjs to esm is a massive shift. esbuild in place of babel is a ground breaking achievement.

Vite, which leverages ESM and esbuild, is very different, and better than webpack.

The ecosystems which haven't changed, I. E. react and angular, are either in middle of transition or suffering from not doing it.

So much of the effort of extending JavaScript via many frameworks and the constant updating feels brittle.

It makes having a relationship with a stable piece of code challenging to move on to the next big function.

Over time, maintaining anything too old or too new can drag momentum and progress.

Still it’s one of the most universal technologies. Some of the more recent simple frameworks like alpine.js, or lit as I rediscovered today on HN may have more merit than initially realized.

JS backends do the same thing too. Hapijs had a habit for a long time of making breaking changes often. Most recently for me was Strapi which took everything and threw it out the window with really no way to upgrade that didn't also involve re-writing a ton of code. It's exhausting. This is what makes me want to just stick with the old tried and true tools (like WordPress).

I love JS, but I agree with all of this. I will say that vite/parcel/etc. are genuinely simpler and worth the migration headaches. (They are also built in Go/Rust, which should probably cause some self-reflection in the Javascript community.)

I love the variety. But I understand how it can be head spinning.

IMO the important thing is to find what works for you. I’d be wary of every other article out there that offers their ideas of the best way of doing anything web.

Personally I wouldn’t consider the article’s solution “simple”.

It’s less about it being head spinning vs the need for it to be.

Creating beginners is important.

Having more attention to spend on the user than maintaining the brittleness that can be present is a real tax.

I did the vue2 - vue3 upgrade, while I see what you're saying and actually agree, I have no idea why you had change your build tool from webpack to Vite. I'm still on webpack, for better or worse.

Webpack wasn’t on the list of supported build systems when I made the upgrade, don’t know if it still isn’t there. I preferred to waste time making a supported build system work than wasting it making an unsupported one work.

A React project wouldn't have the same issues.