Item — HN Reader

I just got a new job, mostly backend but with a bit of Ember thrown in, and I despise the framework. It's slow to work with, massive, and incredibly over-engineered and makes it so that creating the simplest of features is an absolute mess. Maintaining a sizeable Ember project is pure hell of traversing through 800 folders and files to find the one place the thing you're looking for is, since you can have a controller inherit from another, which inherits from another, which inherits from another ad infinitum, so good luck guessing where exactly that one attribute is coming from, or even what the hell it even is. The base controller might have a variable called `foo`, but then somewhere down along the chain that variable has been aliased/transformed into a completely different variable name with 0 bearing on what it originally maps to.

Handlebars templating is also *awful*, I cannot describe with words how much I despise Handlebars and everything surrounding it. To create a simple `if (foo && bar)` in a template, you have to do `{{#if (and foo bar)`. Okay, the `and` DSL is a bit weird, but not that bad. But then `if (foo && !bar)` becomes `{{#if (and foo (not bar))}}`. God forbid you want to do any kind of comparison though, because `if (foo < 0 || bar > 1)` becomes `{{#if (or (gt foo 0) (lt bar 1))}}`. You get the point, it quickly dissolves into an unreadable soup of brackets and DSL for very simple logical operands.

I could go on for a while about why I hate Ember, but I'll leave it at that. </bigRant>

1 comments

Handlebars extends on Mustache which considers itself "logic-less" templating language. I think `{{#if (and foo bar)` goes against that principle, so introducing ie `shouldShowX` property on component which then depends on foo && bar and just using `{{#if shouldShowX` really helps.

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.

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.