Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There is something close, even better, when overall API design/architecture is considered, that is ember.js. Check ember-cli/embroider which angular-cli initially forked from. I give it 1.5 years for ember to pretty much dominate SPA development, In the last two years some people were laughing at me, now Im laughing at them.


Our company trialed Ember this year alongside React, Angular, and Vue for a new SPA. Ember was the worst of the bunch:

- It is stringly typed. All over the place you're globally registering names as strings (or worse, using strings that implicitly resolve to filenames). You'll write `store.createRecord('mymodel')` instead of just importing things using standard ECMAScript imports.[1] This means static analysis is out the window, which makes it labor-intensive to find usages or do even simple refactors like renames.

- It leans on global state and object mutation way too much, instead of using functional state updating. This was the way older frameworks like Backbone, YUI, etc worked. Web development is moving away from this paradigm, and for good reason.

- Static typing support is non-negotiable in 2019 (and 2015 for that matter, but I digress). Support in Ember is just not there, and I don't see much promise for the future either. React and Angular have had good support for Typescript and/or Flow for a good 5 years now.

- One high point for Ember: the in-browser testing beat the pants off any of the other frameworks. We ended up going with React/Jest/Puppeteer, but this meant we (meaning, I) had to write 150 lines of boilerplate that Ember gives you for free.

Overall working in Ember honestly felt like being transported back in time by 10 years. I guess if you're a solo dev it's easy to whip up a quick demo that seems fine, but you'll hit the wall very quickly where the project becomes write-only. I think it's unlikely a brand new build system, no matter how fancy, can make up for these architectural problems.

[1]: https://guides.emberjs.com/release/getting-started/creating-...

EDIT: I regret taking the time to write this. Should have checked submission history first…


> It is stringly typed.

This is a big issue.

> - It leans on global state and object mutation

I dont see this as a problem, it's an implementation details. If the software works well (fast enough) and provides a nice API, I dont care much about the internals.

> - Static typing support is non-negotiable in 2019

Agreed, but I'd like to combine this point with the first.

EDIT: thanks for typing your reply. :)


There are 3 places where one can say ember is stringly typed:

1- controller/service dependency injection(no more with octane).

2- ember data API(store.createRecord(modelNameString) and serializerFor(modelNameString)). I don't mind it results in less imports and API might change in the future.

3- this.owner.lookup('$abstractionName:$fileName') => I like this one. It removes the need for an extra line of import code and import path could have been very verbose for something far away in dependency tree.

Therefore, I don't think it is a serious issue anymore.

Majority of the ember source code and internal packages are in typescript and there is a good typescript support for app development via addons. As a person who wrote an ember-cli alternative, I can say with confidence that you can build ember apps in typescript. Despite all that, the type analysis performance overhead/cost of typescript compiler today isn't worth the type benefits for really big SPAs yet in my opinion. I think instead those frontend teams should optimize their hiring and mentoring practices until we have a very fast typescript compiler.

Addon/package authors can write their code in typescript and make it work with JS or TS ember application code today.

TLDR for the ones who made weak typescript arguments here against ember.js: Don't be a hypester and claim certain things without making a good research.


Thanks for this breakdown, very helpful.


EDIT: I was going to respond to you then I realized your account is created on May 2018, so I decided not to.


?



I dont care about fashion too much, I care about code, maintenance and community quality more. It is in my opinion the only way to build good and sustainable development teams in the current environment. Contrarian opinion I know..


> > > I give it 1.5 years for ember to pretty much dominate SPA development

> > That appears unlikely: https://trends.google.com/trends/explore?date=today%205-y&q=....

> I dont care about fashion too much

Do you see the problem here?


I don’t, what’s the relationship between having an opinion in the minority and not caring for fashion (chasing hype) For something to dominate it needs some hype but having hype doesn’t lead to dominating the market


Someone who "give[s] it 1.5 years for ember to completely dominate SPA development" and is laughing at people who doubted it clearly cares about fashion.


The fact that ember doesn't integrate natively with typescript means that probably won't happen...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: