React is holding me hostage

I had to eventually claw my eyes out and that solved part of my problems, at least I did not see the boilerplate and the ugliness.

Then soon after that we worked on a similar thing (form + draggable carousel with snap to grid animation) in Angular with Material.

And my conclusion is that whichever framework you pick, whatever libraries you end up using, you must have a strategy to allocate your time and maintenance budget, and many many many times the sane compromise is to write something in raw JS and encapsulate that in whatever the framework gives you, and move on. Don't try to solve it within the framework, because it's just not worth it.

The UI problem is not new. People were already building clunky UI cars long ago. MFC was introduced by Microsoft in 1992.

Of course the emergence of the web platform and mobile/touch devices complicates the matter as you now have a proliferation of platforms to address (desktop native, desktop web, mobile native, mobile web) but my argument is that fundamental patterns on how to do this efficiently should have emerged by now - and I see exactly the opposite.

It would be nice to see some sort of convergence. Reinventing the wheel might be "fun" or gainful in a narrow sense but it certainly doesn't help with productivity.

I hear normal, non-tech people with average hardware complain about "lagginess" of their machines all the time. And usually the only application they use is Chrome. They won't say that they had a 200ms lag when they clicked on a button, but the overall experience degrades when things are slow to respond. And when you sit that person in front of a good, optimized, snappy application, they will sing praise. Not particularly because of performance, but they will enjoy using it more, and they won't be able to explain exactly why.

You'd think that with the ridiculous amounts of money software engineers are paid to do what they do, they'd be able to swallow slightly more difficult collaboration and developer experience in order to deliver a more quality product. Forgive me for being harsh, and I don't mean this as directed to you (I don't know you), but our industry behaves like a bunch of babies.

Aside: if you're making an interactive game, you have 16ms to respond and render, not hundreds. In 16ms, modern games dispatch draw calls for millions of triangles, do AI, physics, netcode, level streaming and other bookeeping. Yet the teams there collaborate just fine.

It’s pretty hard to get more “this is my opinion rather than a statement of objective fact” than this.

> I do not like JSX. It’s not worth talking about why. It’s not an argument I want to have.

Ok.

Um… well, it’s hard to have a discussion if you won’t talk about it…

…but, “code” templates allow autocomplete and type checking in a way that is an objectively distinctive superset of text templates.

It’s because they are code.

A template is (almost always) a weakly typed DSL. Written, ignoring all the history of language design… by a bunch of folk who don’t really know how to write programming languages. …and, they. Are. Bad. Not always… but often. …because writing a language is hard, and because (reason) you can’t ever use an existing template language. Oh no. This framework has to have its own unique one, because otherwise it doesn’t integrate tightly.

Do you like DSLs? Or do they just hide the complexity somewhere else? What if the DSL is bad, not orthogonal in its feature set, poorly implemented …but cute, and useful for a very very narrow use case.

Isn’t the main critique of react that it hides complexity by moving it from one place to another?

Don’t you think it’s a tiny bit ironic that all the other templates based languages with their custom template DSLs are doing the same thing?

Anyway; I think it’s fair to evaluate template languages as what they are: DSLs.

JavaScript is a better language than most template languages by a variety of metrics. Other languages are better than JavaScript, absolutely… but, never, have I seen a template language that is.

You can love declarative configuration all you want, but it’s very very difficult to argue that just because you can make a mess with procedural approaches that they are worse; because they are a strict superset of what’s possible using the declarative approach.

…so sure. I don’t but “JSX is easier to maintain”, but it’s distinctly superior in capability.

That said, as a low-level library it should not move fast; it should make sound design decisions while maintaining compatibility. It’s completely open to frameworks with more opinions and friendlier DX to be built on top of it.