3 ms·

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 willi

by klysm 3y ago

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

capableweb 3y ago
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"
- bitL 3y ago
  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.
  - karpierz 3y ago
    What are some examples?
    - ipaddr 3y ago
      jQuery
      - klysm 3y ago
        I’d argue it’s evident large jQuery apps are a pain in the ass to maintain
    - arcanemachiner 3y ago
      I think Alpine.JS hits this spot pretty well. https://alpinejs.dev/ https://alpinejs.dev/
  - balder1991 3y ago
    [deleted]
  - balder1991 3y ago
    > 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.
duxup 3y ago
I feel like the only things that provide “ leaps in simplicity” as far as web dev goes are basic css frameworks. Generally they really can save a lot of time / needed structure.
- klysm 3y ago
  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.
luisgvv 3y ago
The law of leaky abstractions - as systems become more complex eventually you rely on more abstractions that try to hide complexity. What makes it worse in the front-end framework world is that either: 1-Projects become convoluted with 3rd party libs to solve a problem 2-The framework maintainers eventually introduce APIs that aren't backwards compatible and existing ones stranded or deprecated
- balder1991 3y ago
  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.
  - arcticgeek 3y ago
    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.
austin-cheney 3y ago
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: https://github.com/prettydiff/wisdom/blob/master/Easiness.md 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.
- balder1991 3y ago
  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.
legulere 3y ago
Web components weren't as widely available as they are now when most web frameworks were written.
spankalee 3y ago
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 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.
- Freedom2 3y ago
  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.
- SebastianKra 3y ago
  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). [1]: https://lit.dev/docs/composition/controllers/ https://lit.dev/docs/composition/controllers/
  - 3y ago

by klysm 3y ago

capableweb 3y ago

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"

bitL 3y ago
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.
- karpierz 3y ago
  What are some examples?
  - ipaddr 3y ago
    jQuery
    - klysm 3y ago
      I’d argue it’s evident large jQuery apps are a pain in the ass to maintain
  - arcanemachiner 3y ago
    I think Alpine.JS hits this spot pretty well. https://alpinejs.dev/ https://alpinejs.dev/
- balder1991 3y ago
  [deleted]
- balder1991 3y ago
  > 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.

duxup 3y ago

I feel like the only things that provide “ leaps in simplicity” as far as web dev goes are basic css frameworks. Generally they really can save a lot of time / needed structure.

klysm 3y ago
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.

luisgvv 3y ago

The law of leaky abstractions - as systems become more complex eventually you rely on more abstractions that try to hide complexity. What makes it worse in the front-end framework world is that either: 1-Projects become convoluted with 3rd party libs to solve a problem 2-The framework maintainers eventually introduce APIs that aren't backwards compatible and existing ones stranded or deprecated

balder1991 3y ago
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.
- arcticgeek 3y ago
  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.

austin-cheney 3y ago

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: https://github.com/prettydiff/wisdom/blob/master/Easiness.md 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.

balder1991 3y ago
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.

legulere 3y ago

Web components weren't as widely available as they are now when most web frameworks were written.

spankalee 3y ago

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 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.

Freedom2 3y ago
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.
SebastianKra 3y ago
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). [1]: https://lit.dev/docs/composition/controllers/ https://lit.dev/docs/composition/controllers/
- 3y ago