Hacker News Reader

Comment by cageface | Hacker News Reader

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.

View on HN

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

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?

Reply on news.ycombinator.com