I think your conclusion in point 2 is misguided, but I can see where you’re coming from. It’s true that virtual DOM has a lot of expressive power, and Svelte’s templating features are more limited in how you can approach certain problems. I find Svelte’s slots especially challenging for more advanced use cases, and wish they were more composable.
But in my experience, React’s openness to expressive experimentation is not a net positive for maintainability, productivity, or quality. There are lots of footguns, and bad ideas embraced by the ecosystem. HoCs were a terrible idea, and were replaced with an even worse idea, hooks. Compared to that, Svelte’s reactive statements and stores are a bliss.
Arguably, it’s because React has experimented and made those mistakes that Svelte has been able to focus on a constrained DSL that mostly supports the features that are actually a good idea.
I think there are two things that are interesting about your point of view.
First, I think a mistake the react team made was not exerting more control over the ecosystem. I think a lot of questionable content marketing pieces ended up as “best practices” which we are still unwinding as a community.
Second, I totally buy the idea that there are multiple personas and that different tools speak to different personas. The sustained popularity of constrained dsls among subsets of the frontend community speaks to this.
But are you against constrained templating DSLs on principle, or just the specifics of how Svelte does it? I think the reason bad ideas take hold is because people are looking for guidance; constraints, if you will. In React that is offered through libraries, frameworks and best practices, but not all of those are good. Svelte has a lot more control of its ecosystem because the constraints are built in to a compiler. And as I said, I think it falls short in certain areas, but all in all I think those restrictions are a net win.
I am against constrained DSLs in general unless it buys you something. In the general case, with a DSL you sacrifice expressivity in order to gain security guarantees or improved performance. In this case you are sacrificing expressivity to gain performance but I don't think the performance gains are meaningful enough to be worth sacrificing all of that expressivity. So to answer your question, I am generally opposed to constrained templating DSLs for web frontend applications overall.
I’d say DSLs in general are really annoying. They’re almost never as well designed as a mainstream language, their tooling is usually worse, and good luck if you ever need to do something that isn’t well supported by them.
These problems are surmountable, but man, I’ve used and created some crappy DSLs in my time. If you’re wondering, “Should I create a a DSL for this?” Default to “No” unless the evidence is overwhelmingly in favor of it.
I couldn't agree more. Every time I have to do a for-each loop in some templating language instead of just using a normal programming language I want to shoot it into the sun. Templated yaml is my current pain point. Why not build data structures in a normal programming language and then write the result to yaml. It feels like a lesson we learnt after templated XML 20 years ago that we keep forgetting.
But in my experience, React’s openness to expressive experimentation is not a net positive for maintainability, productivity, or quality. There are lots of footguns, and bad ideas embraced by the ecosystem. HoCs were a terrible idea, and were replaced with an even worse idea, hooks. Compared to that, Svelte’s reactive statements and stores are a bliss.
Arguably, it’s because React has experimented and made those mistakes that Svelte has been able to focus on a constrained DSL that mostly supports the features that are actually a good idea.