I do understand that reasoning, but that comes back to my annoyance with having to deal with a million files to do anything simple. I then need to create a backing controller if it wasn't there before, and if it is there, I need to add on an extra computed on top of the mess of other computeds already present. Why so complicated? JSX and Vue's flavor of templating is infinitely better, since it's basically just regular javascript in the template.
back
1 comments
I've read your comments and it looks like a mess of a codebase, more than a "framework mess". It seems like a bad experience and I would not want to deal with deep inheritance and over-reliance on old/deprecated functionality (computed properties), so... hug.
Controllers are not required for anything except query params mapping. It's perfectly fine, and I think very common, to load data in components. A rule of thumb is to load in the route only the minimum amount of data for your layout to work. As for the million of files ... React co-locates template and logic code while ember-cli generates a js/ts file, a hbs file and a test file. It's either 2 to 3 (if you count a test file for the React component) or 1 to 2 (discard test files). Finding the sweetspot between large components and multiple components is not easy. For example, it was considered a best practice to apply the presentation-container pattern in React, which means 2 components.
I'm not going to say anything about your claim that JSX is regular javascript in the template.