3 ms·

tl;dr: I love web development again. You obviously haven't tried Svelte yet. I would have agreed with you a few years ago though. The churn as I've seen it ha

by ttfkam 3y ago

tl;dr: I love web development again. You obviously haven't tried Svelte yet. I would have agreed with you a few years ago though. The churn as I've seen it has been a direct result of React's ecosystem, not in spite of it. Here's a partial list of React libraries that just provide state management: MobX Recoil Redux Akita Context Hookstate Zustand Jotai Just for state management! And all exist solely because React state management is a monumental fustercluck. Then you get into React API nightmares the article mentioned that have nothing to do with HTML, CSS, and JS but have everything to do with React's API quagmire. You may scoff at pointing to Svelte as "just a new shiny", but it really is getting back to the web's roots. Htmx as well. I've been doing web development professionally since 1996. I have hated web development since soon after React was introduced. React solved a lot of big problems to be sure, but it introduced its fair share as well as made web development tedious in a way I hadn't experienced before. I wasn't developing for the web anymore; I was developing for React. I constantly felt detached from my actual target. Wrapper after wrapper of familiar vanilla libraries to shoehorn into the React ecosystem rather than living alongside it. Svelte (and Htmx to a lesser extent) gave me back plain ole HTML & CSS. Svelte also gave back that simple JS that described the problem I was trying to solve instead of endless boilerplate on an API layer on top of the browser API. Vue got close but didn't go far enough. SolidJS just made a faster React. Svelte and Htmx embraced the web with no holding back, and I love them for it.

text0404 3y ago
so you'd prefer that there was only one state management solution for every webapp? what if i don't need 99% of the features of this monolith library?
- ttfkam 3y ago
  Seriously, try Svelte. See how its Stores API works. For bonus points, look at the Context API. Between Stores, Context, and what looks like plain ole JS in the component, state management is a solved problem. With all due respect, calling it a "monolith" out of hand just screams you haven't even looked at solutions and don't know what you're talking about. SolidJS stores work the same. In other words, this is basically a solved problem unless you live in the React ecosystem.
robertoandred 3y ago
What state management does Htmx provide?
- ttfkam 3y ago
  Htmx defers almost all logic to server side. That's the tradeoff, and it's a major shift from what we've become accustomed to in the last decade (unless you've been writing PHP or something similar). You provide listening points to various parts of your app, and when something changes, all points listening to that key also make the corresponding call to the server for refresh. It sounds hokey, but it's very effective, very efficient, and pretty easy to wrap your head around.
  - robertoandred 3y ago
    Deferring all logic and state management to some mystery and messy server-side black hole? Sounds like a monumental fustercluck.
    - ttfkam 3y ago
      Not any more than REST is. Server-side rendering doesn't have to be messy. In fact for most modern frameworks, it's become table stakes.
      - robertoandred 3y ago
        And how many libraries and frameworks and methodologies are there for server-side state management?
        ttfkam 3y ago
        State on the server side is often a very different animal from client side. Whereas on the client, everything is either JS and/or a browser API, the server side allows for relational databases, Redis caches, and all sorts of other strategies, some based on session ids while others using whatever fits for that scenario. "It depends" but it's not just a library or framework as you'd imagine coming from frontend development. Htmx is quite popular among folks who prioritize and enjoy server-side development. Svelte is likely more popular among folks who enjoy browser-based development. There is certainly some overlap between the two camps, but that's my take on it.

by ttfkam 3y ago

text0404 3y ago

so you'd prefer that there was only one state management solution for every webapp? what if i don't need 99% of the features of this monolith library?

ttfkam 3y ago
Seriously, try Svelte. See how its Stores API works. For bonus points, look at the Context API. Between Stores, Context, and what looks like plain ole JS in the component, state management is a solved problem. With all due respect, calling it a "monolith" out of hand just screams you haven't even looked at solutions and don't know what you're talking about. SolidJS stores work the same. In other words, this is basically a solved problem unless you live in the React ecosystem.

robertoandred 3y ago

What state management does Htmx provide?

ttfkam 3y ago
Htmx defers almost all logic to server side. That's the tradeoff, and it's a major shift from what we've become accustomed to in the last decade (unless you've been writing PHP or something similar). You provide listening points to various parts of your app, and when something changes, all points listening to that key also make the corresponding call to the server for refresh. It sounds hokey, but it's very effective, very efficient, and pretty easy to wrap your head around.
- robertoandred 3y ago
  Deferring all logic and state management to some mystery and messy server-side black hole? Sounds like a monumental fustercluck.
  - ttfkam 3y ago
    Not any more than REST is. Server-side rendering doesn't have to be messy. In fact for most modern frameworks, it's become table stakes.
    - robertoandred 3y ago
      And how many libraries and frameworks and methodologies are there for server-side state management?
      - ttfkam 3y ago
        State on the server side is often a very different animal from client side. Whereas on the client, everything is either JS and/or a browser API, the server side allows for relational databases, Redis caches, and all sorts of other strategies, some based on session ids while others using whatever fits for that scenario. "It depends" but it's not just a library or framework as you'd imagine coming from frontend development. Htmx is quite popular among folks who prioritize and enjoy server-side development. Svelte is likely more popular among folks who enjoy browser-based development. There is certainly some overlap between the two camps, but that's my take on it.