4 ms·

It's interesting how none of the JS/tooling fatigue discussions mention Ember, which has one public-facing tool.

aikah 11y ago
i wouldn't use Ember precisely because it strongly suggests using a command line tool specifically for the framework. I personally ended up with Typescript as a language + Bower for package management. When it comes to frameworks it is either the framework adapts my toolset or I don't use it. I refuse to compromise and embrace yet another asset pipeline or build tool, no matter how "good" the framework is supposed to be. Typescript support both decorators and JSX, so I can tolerate working with either Angular 2 and React. And since build steps are mandatory in Front End development I, at least, can take advantage of static typing.
- sotojuan 11y ago
  Fair point. My comment was pointing out how Ember isn't mentioned at all, not that it's necessarily better.
anonyfox 11y ago
So true. Ember is the antidote right now for the frontend land. - MVC (Backbone's big thing) - Two way binding (Angular's big thing) - Components (React's big thing) - SSR like the others now (FastBoot) - High performance with the Glimmer Engine (should beat react in theory) - Books. - dedicated package repository (emberaddons) - actually community driven - stable + mature (+ seamless upgrade paths) - and many more advantages plus, as you said, the ember-cli tool, that gets you up to speed fast. The tooling makes the final success, just have a look at go... the language appears fairly weak/trivial, but the tooling is excellent. I could freak out everytime I have to set up an react project, weighing everyones opinions about every little package for every usecase, IMO react shifts the complexity from the UI to the tooling. Ember is just perfect and the only real option I could recommend right now, and I'm just sick of thousands of "me too!" approaches for everything, this extreme diversification cripples actual progress to a halt.
- sotojuan 11y ago
  > Ember is the antidote right now for the frontend land Sounds familiar: http://brewhouse.io/blog/2015/05/13/emberjs-an-antidote-to-your-hype-fatigue.html http://brewhouse.io/blog/2015/05/13/emberjs-an-antidote-to-y...
- cshenoy 11y ago
  After working on a few large JS applications (using Backbone or Angular or React), I decided to try out Ember for a relatively smaller application. Ember feels very Rails-y (likely on purpose) and the documentation wasn't great. It took me a few hours to get a surface level understanding of how things worked with each other, especially Ember Data. I ultimately ended up dropping it because of my frustration. It was only a couple months ago (early December 2015). Obviously I'm just one data point but I know I've talked to other devs who feel the same way. I'm sure Ember will only get better but I don't think it's the antidote at all.
- realharo 11y ago
  Last time I had to use ember (about 2 months ago), the ember-cli tool had major performance issues. I remember rebuilds after a single line of code was changed taking almost 10 seconds. It also generated almost 10 gigabytes of temporary files over time. Plus I remember an issue with import paths not matching real filesystem paths, which was messing with my IDE (and my brain until I figured out what was going on). It's a good tool when it works properly, but they really need to work on those rough edges a bit.
  - orf 11y ago
    > I remember rebuilds after a single line of code was changed taking almost 10 seconds. Do you happen to be on Windows? My Ubuntu laptop compiles changes to our pretty large app in under a second, but on Windows it does take up to 10 seconds.
    - realharo 11y ago
      Yes, it was a Windows machine. I did all the "make it faster" steps, like running the recommended script that adjusts Windows Defender and search indexing configuration, but in the end it was still very slow, even on a fairly fast SSD.
auvrw 11y ago
tried to use ember-cli w/o enforcing some certain opinions (e.g. directory structure) on a project and reached out to the community via slack, but it hasn't really taken so far. maybe Goya was a bad choice? someone on the slack used the term "consume" for what i was trying to do w/ ember-cli, and.. https://github.com/ransomw/ember-cli-programmatic-usage https://github.com/ransomw/ember-cli-programmatic-usage

aikah 11y ago

i wouldn't use Ember precisely because it strongly suggests using a command line tool specifically for the framework. I personally ended up with Typescript as a language + Bower for package management. When it comes to frameworks it is either the framework adapts my toolset or I don't use it. I refuse to compromise and embrace yet another asset pipeline or build tool, no matter how "good" the framework is supposed to be. Typescript support both decorators and JSX, so I can tolerate working with either Angular 2 and React. And since build steps are mandatory in Front End development I, at least, can take advantage of static typing.

sotojuan 11y ago
Fair point. My comment was pointing out how Ember isn't mentioned at all, not that it's necessarily better.

anonyfox 11y ago

So true. Ember is the antidote right now for the frontend land. - MVC (Backbone's big thing) - Two way binding (Angular's big thing) - Components (React's big thing) - SSR like the others now (FastBoot) - High performance with the Glimmer Engine (should beat react in theory) - Books. - dedicated package repository (emberaddons) - actually community driven - stable + mature (+ seamless upgrade paths) - and many more advantages plus, as you said, the ember-cli tool, that gets you up to speed fast. The tooling makes the final success, just have a look at go... the language appears fairly weak/trivial, but the tooling is excellent. I could freak out everytime I have to set up an react project, weighing everyones opinions about every little package for every usecase, IMO react shifts the complexity from the UI to the tooling. Ember is just perfect and the only real option I could recommend right now, and I'm just sick of thousands of "me too!" approaches for everything, this extreme diversification cripples actual progress to a halt.

sotojuan 11y ago
> Ember is the antidote right now for the frontend land Sounds familiar: http://brewhouse.io/blog/2015/05/13/emberjs-an-antidote-to-your-hype-fatigue.html http://brewhouse.io/blog/2015/05/13/emberjs-an-antidote-to-y...
cshenoy 11y ago
After working on a few large JS applications (using Backbone or Angular or React), I decided to try out Ember for a relatively smaller application. Ember feels very Rails-y (likely on purpose) and the documentation wasn't great. It took me a few hours to get a surface level understanding of how things worked with each other, especially Ember Data. I ultimately ended up dropping it because of my frustration. It was only a couple months ago (early December 2015). Obviously I'm just one data point but I know I've talked to other devs who feel the same way. I'm sure Ember will only get better but I don't think it's the antidote at all.
realharo 11y ago
Last time I had to use ember (about 2 months ago), the ember-cli tool had major performance issues. I remember rebuilds after a single line of code was changed taking almost 10 seconds. It also generated almost 10 gigabytes of temporary files over time. Plus I remember an issue with import paths not matching real filesystem paths, which was messing with my IDE (and my brain until I figured out what was going on). It's a good tool when it works properly, but they really need to work on those rough edges a bit.
- orf 11y ago
  > I remember rebuilds after a single line of code was changed taking almost 10 seconds. Do you happen to be on Windows? My Ubuntu laptop compiles changes to our pretty large app in under a second, but on Windows it does take up to 10 seconds.
  - realharo 11y ago
    Yes, it was a Windows machine. I did all the "make it faster" steps, like running the recommended script that adjusts Windows Defender and search indexing configuration, but in the end it was still very slow, even on a fairly fast SSD.

auvrw 11y ago

tried to use ember-cli w/o enforcing some certain opinions (e.g. directory structure) on a project and reached out to the community via slack, but it hasn't really taken so far. maybe Goya was a bad choice? someone on the slack used the term "consume" for what i was trying to do w/ ember-cli, and.. https://github.com/ransomw/ember-cli-programmatic-usage https://github.com/ransomw/ember-cli-programmatic-usage