3 ms·
Great article! It clearly shows the tradeoffs and isn't afraid of stating personal preferences where applicable. IMO there are a bunch of rules of thumb and us
by dgb23 5y ago
Great article! It clearly shows the tradeoffs and isn't afraid of stating personal preferences where applicable.
IMO there are a bunch of rules of thumb and use cases for choosing something like htmx (great library, I've been using it more and more) as opposed to something like React or a React based library or web components and so on (much more powerful but comes with a cost).
- Progressive enhancement of a mostly static site.
- Most interactions need to query the backend (or hit a cache) - typical for DB heavy sites. (Seems to be the case here.)
- You have a fast backend and/or it doesn't make too much sense to offload computation to the client.
- You don't have the expertise/willingness/requirements to implement advanced and/or bespoke interactive UI features AKA your UI is KISS. (Like the ones mentioned in the article.)
- Your template/component library you use on the server is similarly productive and composable (was _not_ the case 10-8y ago IMO).
- You don't need integration with something like Storybook or Workspaces to develop and test components in isolation.
- You don't know if some of the above are true, but the way you develop your UI can be more or less easily extended or ported to a more frontend heavy solution without creating a JS spaghetti mess and spreading frontend logic across client and server.
There are probably few more? But the general point is: Use the right tool for the job.
- nawgz 5y ago> - You don't need integration with something like Storybook or Workspaces to develop and test components in isolation. You never needed this. Those things are pure bloat. If you're building React components... build a static CRA app out of those components. Voila, you have real-world React examples, no Storybook garbage creeping in, no 3minute compile times just to find you didn't configure their stupid webpack setup to actually catch your TS errors, just the literal environment you'll use them in perfectly ready to go Otherwise, I don't strongly disagree, I think that this point is the real key to all these non-framework libraries though: > - You don't have the expertise/willingness/requirements to implement advanced and/or bespoke interactive UI features AKA your UI is KISS. (Like the ones mentioned in the article.) I can promise you people like optimistic app behavior when you write it well. And that's not possible with backend rendering.
- presentation 5y agoIndeed I found Storybook to be insanely bloated. I don't hate the idea but the implementation is ridiculously heavy and inflexible. Being able to easily spin up example pages for components that let you set all the props interactively + hooking that up to tests is nice though.
- ozim 5y agoI have totally opposite view on the article. It does not show anything clearly it is just an opinion, because there is no description of "what the actual system was" and besides "toy project in go/mux" I don't see author selling real multipage-app to someone. So it all is theoretical "feel good" and I don't buy it. While I agree people are jumping to SPA too quick - I also see how full page reloads are clunky. I see also how people want to do "whole system" that should be multiple applications in one SPA because they think that loading Angular as dependency twice is soo bad while they have behemoth of an app that loading Angular even 10x would be still faster if they split it.