New front end frameworks that claim leaps in simplicity feel like the violate some kind of no free lunch principle to me. If they’re that simple, then I’m willing to bet they make some use cases very difficult or impossible
Depends on the definition of simplicity. People say they want simple, but then really want easy. The most easy is always somebody doing the work for you. I got tired of hearing people mention easy when really they probably mean some combination of fearful and/or lazy, so I chose to define easiness:
If developers really wanted simplicity or to be done with work faster they would just learn the primitives of their environment: DOM, functions, and events. Most of the frameworks have APIs that are huge, so clearly simplicity isn't what's wanted.
Thanks for sharing this. I’ve been recently into the concept of Digital Gardens where you evolve concepts and expand them over time (instead of the traditional chronological blogging style) and this is exactly the result that I imagine a page should look like when matured enough.
I would argue rather that the amount of complexity that frontend web devs put up with is more of a Stockholm Syndrome situation. You can be much simpler than most mainstream frameworks, using only standard JS, CSS, and HTML, and acheive better results.
Using custom elements and shadow DOM like this post is a big part of that. Custom elements give you a built-in component module, shadow DOM gives you compositions and style scoping.
I think using proxies like this post is a challenging because proxies are very hard to get correct when dealing with methods, collections, object identity, privacy, etc. but it turns out that many applications do just fine with a simple Redux-like store / action / subscribe system for data.
I personally think the project I work on (https://lit.dev) hits a sweet-spot of simplicity vs complexity because it also gives component reactivity, declarative templates, embedded CSS, with standard syntax and no build tools required. In more than 400 LoC, but only by ~3x.
Rather I feel like there's a now fairly well known set of requirements, and every so often, a new framework comes around and says: "It's simple, we just don't consider this."
For instance, the controllers introduced in Lit 2.0 feel like an admission that you forgot to consider the reasons why React moved away from classes in the first place. The example [1] could be written in less than half the amount of lines with hooks, and isn't any easier to understand.
Also, I can't find a solution for skipping expensive computations when re-rendering the component.
Admittedly, I only skimmed Lit's documentation. But with the frameworks that I have tried, I came across cases where I had to either implement my own workaround, or the framework began introducing more and more concepts to fix their fundamentally broken approach (cough Aurelia).
References from host to controller and controller to host are simple JS references that you can directly see in the debugger.
The React custom hook is a bit shorter, but it's only 13 lines vs 17, and I think hooks are harder to understand because of how much is happening under the hood and the fact that for some reason you need two separate useEffect() calls.
In terms of implementation, I can believe you that they're simpler.
In terms of conceptual load I disagree. In React I'd have to know two concepts: `useEffect` and `useState`. In Lit I have to know the API of LitElement; that it implements a host; the four methods of the controller; the boilerplate for registering my controller and triggering updates; plus all the conceptual baggage of classes.
Further, the hooks implementation considers when an effect should replace itself. For example, if you wanted to have the timeout change dynamically based on the component input, you'd get this for free in react by including `[timeout]` in the dependency array of `useEffect`, whereas with the controller you'd have to do the diffing and replacement yourself.
Then there's propagation of errors from controllers through the tree, where Lit just gives up [1].
Granted, you may not need these features for whatever project you're building, so a simpler framework may be perfectly fine. But don't call it Stockholm-syndrome when other projects _do_ need solutions to these problems.
I want to make clear that I'm not just picking these concepts because they're in React. I've used frameworks before React and I found myself naturally wishing for similar solutions. And React is by no means the only framework with such solutions.
PS: I was counting 10 Lines in React vs 23 in Lit on the ClockController. Although I would of course be fine with both, if I thought it improved on readability.
Do you have an example of a complex widget being implemented in a simpler way with better results? I see this sentiment often here, but most examples are toy examples or frivolous.
I've found that if they brag about how easy it is to get started, it usually ends up messy relatively quickly. On the other hand, if they brag about being easy to order when you have a lot of code, it's usually a bit harder to get started with.
It's like you get to chose one of "get started quickly" or "remain quick enough on the medium/long term"
Not always, some can hit the sweet spot of being simple in all phases of development and quick to learn. They are super rare though and their lessons are forgotten; industry often standardizes on inferior things with better marketing.
> industry often standardizes on inferior things with better marketing.
It standardizes to what’s cheaper on their eyes, sometimes in a very short-sided way, but also companies that work for profit never know if a project will still be running in the next quarter, right? It makes me think that open source and for profit companies should have very different considerations when it comes to choosing frameworks or technologies for their solutions. I should probably gather more info on that and expand it into a blog article.
When discussing this problem with ChatGPT it indeed said the best solution for this is for frameworks to be designed in a way that encourages extensibility: so a framework should stick to its core principles but allow “plugins” to extend its functionality for very specific use-cases. But I understand there’s always a trade off here, as simplicity in the framework shifts the complexity to the application.
One example of a framework that takes this approach is Apache Royale. It’s a reboot of the AS3 language and component library that works like Adobe/Apache Flex but compiles to JS targeting the browser runtime. This refactored Flex was rebuilt from the ground up with a Pay As You Go (PAYG) philosophy where components are composed of „beads“ on a strand that enable composition of the functionality you need rather than the kitchen sink.
Sure but they make certain things very hard or impossible, usually as things get more dynamic. But CSS has gotten a lot more dynamic capability in recent years.
https://github.com/prettydiff/wisdom/blob/master/Easiness.md
If developers really wanted simplicity or to be done with work faster they would just learn the primitives of their environment: DOM, functions, and events. Most of the frameworks have APIs that are huge, so clearly simplicity isn't what's wanted.