Hacker News Reader

Comment by thawaway1837 | Hacker News Reader

Having interacted with Core Ember devs I would be very surprised if the author didn’t know anything about React. I’d wager that he indeed knows a lot about React.

At least the ones I interacted with did not only know React, they knew it well enough to identify its pitfalls, and be able to translate what they believed to be its best parts to EmberJs.

Also, the comment about different files is a thing even outside this example (and is one reason I prefer react over Ember personally). React has no defined file system, and strongly encourages components are written in a single file. Ember, OTOH, does a lot of file separation, and a lot of convention over configuration.

View on HN

Having worked with React/Hooks for the past few months - I think he did a good job of identifying the benefits and problems of hooks. In a production application, you are likely to use something like redux or xstate to keep the state in your components minimal which in turn allows you to avoid a lot of the complexity that hooks have.

React has no defined file system, and strongly encourages components are written in a single file.

Sure, but there's a lot more to the example that a single component. There's the app component, 3 other components, a reducer, and a custom hook. Putting all that in a single file is fine for an extended example explaining how things work together with a further chapter explaining how to break it down in to separate files, but it's not how you'd write a real app. The article author clearly doesn't know that if his criticism is that Ember does it better by using more files, so it not unreasonable to question if his knowledge of React is up to comparing it to Ember. It's quite a fundamental mistake he's making.

I don’t think that’s what he is talking about here though. And note, his point about the multiple files isnt even a complaint.

As someone who worked with Ember in the past (our company inherited a new product with an acquisition so we were forced to change tech stacks), this comment really comes from the fact that Ember has a very comprehensive file layout system. And one of the major criticisms about Ember classic was how different core pieces for the same component, were located in so many distant folders (hence the comment about colocation of component code, which seems trivial, but is a huge usability gain IMO).

I think that sentence should be read more as a reflection on Ember, than suggesting the author does not think React components can be broken into multiple files, and hence an indication of their knowledge of react.

Convention over configuration is one of the worst ideas ever in software in my opinion. All it means is that you have to memorize all the implicit assumptions about how an app is put together before you can work productively. It makes for great convention talk demos but in production what you really want is very explicit and obvious relationships between pieces. For example, this is the reason I find a React/Typescript codebase vastly easier to understand than Rails.

If your language is so verbose that making things explicit is too painful then maybe it's time to reach for a more expressive language instead of hiding everything behind a set of implicit rules.

No, it means that there's a way things are usually done, but if, in you situation, a different way works better, you are free to use it without having to fight the framework.

In a React codebase, for example, I can look at the imports and see immediately where everything in play in that file came from. In real production codebases this is invaluable.

I definitely agree with this! In large codebases especially. This is ultimately why Ember has decided to move toward using JS imports to stitch components together as well, we recently merged an RFC to do just that.

This was my favorite part about Ember, and what I miss the most.

The Ember team is one of the least dogmatic teams that I have come across, and has been willing to change their entire strategy when presented with a better idea (while providing a well defined and fairly convenient upgrade path).

I still remember when React first came out, and showed how one way binding was so much better than 2 way bindings, and the Ember team was able to quickly switch to this new philosophy via DDAU, while still providing an easy upgrade path for our code. And all this was before 1.0 if I remember correctly.

> I can look at the imports and see immediately where everything in play in that file came from.

I'm confused, ember uses standard js imports as well so what's the difference?

> Convention over configuration is one of the worst ideas ever in software in my opinion.

When I first started working with ember many years ago, I felt the same way. But now after working on many ember apps, I feel the opposite. The "convention over configuration" really only applies to basic application structure e.g. routing/templates/controllers etc. All it's really doing is creating a standard place to put files, which itself is flexible and more recently allows e.g. colocated components like you'd see in react/vue/etc.

I think the core point from the article is just how much ember.js has changed and matured. If you read to the bottom it looks like single-file components with glimmer are in the pipeline as well.

I dislike convention over configuration big time. It’s the reason I could never do RoR as much as I tried to learn it when moving from C/C++ dev to more web dev.

But it’s definitely not the worst idea. People who like that approach seem to be extremely productive with it.

It’s definitely not my cup of tea though.

Reply on news.ycombinator.com