4 ms·

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 a

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.

101404 6y ago
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.
- cageface 6y ago
  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.
  - pzuraq 6y ago
    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.
    - thawaway1837 6y ago
      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.
  - holler 6y ago
    > 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?
holler 6y ago
> 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.
thawaway1837 6y ago
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.

101404 6y ago

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.

cageface 6y ago
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.
- pzuraq 6y ago
  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.
  - thawaway1837 6y ago
    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.
- holler 6y ago
  > 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?

holler 6y ago

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

thawaway1837 6y ago

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.