Hacker News Reader

Comment by amazingamazing | Hacker News Reader

It's a shame EmberJS fell by the wayside. The API has been pretty stable for a decade now. Ironically someone who wrote their EmberJS app last decade would have less trouble migrating than someone who did the same with React, Svelte, Vue, etc.

Sadly the Ember team made some strange decisions in the beginning and it wasn't easily grokable compared to regular JavaScript (most of that has been fixed now, though).

This is all to say that whether or not it's JavaScript doesn't really matter, compared to the stability of the API.

My personal problem with JavaScript is that things keep changing too much.

View on HN

I've witnessed a company that started moving away from their KnockoutJS solution to react.

In that time, the knockout parts have kept going strong. The react parts have seen three different paradigms ( React classes, Functional react with redux, React Hooks ) and still hasn't fully settled down given there's also churn in the CSS-in-JS space.

The very occassional time something in the remaining knockout parts need fixing, it's just a harsh reminder that it worked fine.

I'm fairly sure the react portion is still not even on the very latest version of react because some other dependencies are stuck on older versions and they themselves have breaking "API changes" (i.e. complete rewrites with no semblance to the original ).

As someone here also said, maintainers in the JS/TS ecosystem appear to have no respect for their users.

It might sound entitled, but sometimes not completely rewriting your framework's API to a completely incompatible one is a better choice. Even if that means putting up with a slightly worse API than you'd like.

I guess everyone moves so fast that there's a fear that sticking on the old API would just lead to dying off at the hands of a new upstart with a smoother API.

But the alternative is a constant abandonment of projects. If a major version change requires a complete re-write then really the new version is a new project entirely that's re-using the namespace and maintainership.

But perhaps emberJS fell away precisely because it didn't rewrite itself to stay "modern". Maybe this is a "worse is better" situation where the world optimises for the wrong things.

"Has had a mostly stable API for a decade" just isn't something people select for. If it were, then things like ASP.NET would be far more popular.

React has had a mostly stable API for over a decade

How so? Hooks are only ~5 years old.

Meanwhile they've deprecated parts of the class components.

> My personal problem with JavaScript is that things keep changing too much.

JavaScript itself barely changes - it's the flavor-of-the-month frontend frameworks that do. What language feature is commonly used now that wasn't 5 years ago? Some nicer builtin Array methods I guess?

There's a lot of dislike on here for Typescript as a backend language. But the difference with the frontend world with its dozen everchanging frameworks is striking. On the backend side, most projects don't even use a framework, and for those that do basically all of them use the same one (NestJS). And the rate of breaking changes on that has been much lower than something like React.

Of course, many will say that this lack of industry-wide adopted framework in itself is what they dislike about it. But it's hard to settle on that golden mean inbetween both extremes when it's the most popular language in the world (in terms of "Yearly new LOC going into production"). Python makes for a good contrast, with a dozen popularish backend frameworks. Not sure if that's really a better situation to be in, there's pros and cons.

And to expand on this further, I think the real driver of the "javascript always changes" is React. Depending on when your React project was built, it can be incompatible in so many different ways with a React project from a different vintage. Sure, a lot of other frameworks and tools that pop up here and there, but none of them are ever widely adopted. When compared to Vue and Angular which I think we can all agree are the other two frameworks of note, React has been very unstable, Vue and Angular appear quite stable.

The javascript language itself hasn't really had a breaking change of note that I can remember in the last 15 years? It's just expanded its API from years and years of browser implementations trying stuff and trying to get to an actual standard. HTML5/ES6/CSS3 brought a new kind of baseline sanity to the whole thing. That's not to say it's a perfect language without quirks, but to say it keeps changing is just not even accurate at all.

python has version evolution, C++ has version evolution, they kinda all do...

Have you worked with Angular much? I've built extensive component libraries (internal) for my org and maintaining the Angular one has been a nightmare. The frequency of breaking changes and conventions has been awful, particularly in the last few years. React, by contrast, has been a breeze ever since they introduced Context and Hooks.

On the app development side, we dealt with 3 major overhauls of PrimeNG's style system before we decided to invest in a custom library just to eliminate the risk of future upgrades. It took us 6 months to migrate our Angular 9 app to 18 because of the PrimeNG dependency. Granted, it's a massive application and they didn't maintain it properly, but I'd hardly call Angular stable regardless.

And then you have the Vue composition API, which was a major shift from Vue 2.

This isn't to say that React has been perfect. Depending on your stack, there are certainly a fair degree of breaking changes (looking at you, Next.js and react router). But that is far from abnormal in the JS world.

A React class component from 10 years ago will still work in React today perfectly well, and is doing so in large codebases around the world.

Then again, React projects tend to use fast-moving things on top of React, like Redux or NextJS or CRA or whatever. Personally, I enjoy writing stuff in bare React since I like its model, but people tend to steer well clear of that, especially these days with compilers and bundlers and whatnot attached to the frameworks.

I agree, bundlers and bundler plugins have probably been the main thing people see with JS ecosystem and think is overly complicated.

> A React class component from 10 years ago will still work in React today perfectly well,

This isn't true.

ComponentWillMount and related methods were deprecated and then removed.

Yes, they allowed an escape hatch of UNSAFE_ComponentWillMount etc, but that still requires work to make it compatible, so it definitely doesn't "[work] perfectly well".

> Vue and Angular appear quite stable.

I take it you didn’t have to deal with porting an AngularJS app to some other framework, like Angular 2.

I unfortunately learn best by book. I hunted for a React book, against the advice of the community, and found one that was current circa v18. It opens by saying the absolute standard for making React sites is create-react-app… which just got deprecated.

And any book older than that is useless due to class syntax or predating hooks. Just 3 years to turn a resource into a door stop.

So how up to date and idiomatic all the React code shoveled into production servers by LLM's can be, if their training data is mostly riddled with deprecated styles?

The linter picks them up. Then you pass the linter warning/error back into the LLM until the linter stops complaining. Then the slop compiles.

I have a number of ember projects on vite if anyone wants to take a look:

- https://github.com/krausest/js-framework-benchmark/pull/1835... - https://github.com/NullVoxPopuli/markdown-table-viewer - https://github.com/NullVoxPopuli/package-majors (older, needs update, which i can do pretty quickly if i remember to do it)

Agree, overall ember has felt stable and only improved with age, unfortunately becoming increasingly niche.

At my company I mentioned using it in passing to our cto as we were discussing a project to move our core web app from angular to react, and he laughed saying "maybe if this was 10 years ago!".

I haven't used EmberJS in 10 years and was eyeing svelte for some personal projects. Given this article it's made me shy about that. Maybe it's time to look at ember again. I know vanilla JS + htmx is mentioned elsewhere here and worth exploring too. However, as you've said a stable API is very nice these days in the JS world

Ember is working through a migration replacing their build system and bundler with Vite -- all while maintaining backwards compatibility to a version released in 2021. Ember will be fun to watch in the coming year.

Depending on how you count it that could be a version originally released in 2018 i.e. the version they are aiming to support is 3.28 which you should be able to easily update to from 3.0 (which was released in 2018) since it's a minor update with no breaking changes

> My personal problem with JavaScript is that things keep changing too much.

Yeah.

Last year I realized in my 10 or so years using Node I've changed my stack so many times (Express, Hapi, Fastify, Hono, Sequelize, Objection, Prisma, Drizzle, Mongo, Fauna, Postgres, Firebase, etc etc). So much time wasted.

Surprisingly, on the frontend I've found stability with Svelte. I've been using for 4-5 years now and still very happy with. I also love runes.

I used Ember and it sucked. It was too complicated and the community was elitist and hostile. Then it got extremely woke and political and even shut down the docs which made me lol and really dislike the project and its authors.

Nothing woke as far as i can see.

Sorry there was hostility when you were around. We try hard to keep hostility out and keep everyone civil now a days

Reply on news.ycombinator.com