4 ms·

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

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.

lelandfe 2y ago
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.
- yourapostasy 2y ago
  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?
  - deleted 2y ago
    [deleted]
  - combyn8tor 2y ago
    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.
TSiege 2y 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
- earthtograndma 2y ago
  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.
  - real_ate 2y ago
    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
eterm 2y ago
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.
- voat 2y ago
  React has had a mostly stable API for over a decade
  - eterm 2y ago
    How so? Hooks are only ~5 years old. Meanwhile they've deprecated parts of the class components.
nullvoxpopuli 2y ago
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/krausest/js-framework-benchmark/pull/1835... - https://github.com/NullVoxPopuli/markdown-table-viewer https://github.com/NullVoxPopuli/markdown-table-viewer - https://github.com/NullVoxPopuli/package-majors https://github.com/NullVoxPopuli/package-majors (older, needs update, which i can do pretty quickly if i remember to do it)
maeil 2y ago
> 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.
- 91bananas 2y ago
  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...
  - tracerbulletx 2y ago
    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.
holler 2y ago
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!".
deleted 2y ago
[deleted]
sagolikasoppor 2y ago
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.
- nullvoxpopuli 2y ago
  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
pier25 2y ago
> 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.

lelandfe 2y ago

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.

yourapostasy 2y ago
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?
- deleted 2y ago
  [deleted]
- combyn8tor 2y ago
  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.

TSiege 2y 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

earthtograndma 2y ago
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.
- real_ate 2y ago
  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

eterm 2y ago

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.

voat 2y ago
React has had a mostly stable API for over a decade
- eterm 2y ago
  How so? Hooks are only ~5 years old. Meanwhile they've deprecated parts of the class components.

nullvoxpopuli 2y ago

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

maeil 2y ago

> 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.

91bananas 2y ago
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...
- tracerbulletx 2y ago
  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.

holler 2y ago

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!".

deleted 2y ago

[deleted]

sagolikasoppor 2y ago

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.

nullvoxpopuli 2y ago
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

pier25 2y ago

> 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.