4 ms·

I love React too, but it pulls in a lot of dependencies and the dependencies need periodic maintenance. Sometimes you get the feeling that you're spending a si

by rkwz 2y ago

I love React too, but it pulls in a lot of dependencies and the dependencies need periodic maintenance. Sometimes you get the feeling that you're spending a significant chunk of your time not writing code but fighting with configs and dependency churn. Using Go's html/template definitely makes the UI feel dated because of re-rendering, but I rarely notice it in my side project. My next exploration is to use HTMX. I'm planning to gradually add dependencies like HTMX to see how far I can go to reach React's smoothness.

verdverm 2y ago
There eventually has to be JavaScript somewhere, and once you have to use that for any dynamic frontend, might as well use a proper JS/TS framework. Not being a frontend person first, I have learned to choose whatever they are using these days. It will be hard to hire, onboard, and maintain anything that strays too far for the normal patterns they use. Next has skyrocketed in popularity for a reason. It makes the React DX much better, losing a lot of the config hell from other framework/library amalgamations
- rkwz 2y ago
  > There eventually has to be JavaScript somewhere, and once you have to use that for any dynamic frontend, might as well use a proper JS/TS framework. Yes, totally understand it's hard to escape JS in Web frontend. Even writing a simple dropdown requires a little bit of JS. > Not being a frontend person first, I have learned to choose whatever they are using these days. It will be hard to hire, onboard, and maintain anything that strays too far for the normal patterns they use. Since this is for my hobby project, it's more fun to be a irrational ;) I use standard React at work. > Next has skyrocketed in popularity for a reason. It makes the React DX much better, losing a lot of the config hell from other framework/library amalgamations Need to check Next again, I tried it many years back and it was good.
  - 8organicbits 2y ago
    If you really want, you can avoid JS for drop down menus too. I've seen the CSS hover [1] and the summary/details [2] approach before. My recent sites use Bulma for all the styling, so the only JavaScript I'm using is the toggle for the navbar burger icon on small screens [3]. [1] https://www.w3schools.com/Css/css_dropdowns.asp https://www.w3schools.com/Css/css_dropdowns.asp [2] https://codepen.io/Ajay-Anand/pen/OJoZjPd https://codepen.io/Ajay-Anand/pen/OJoZjPd [3] https://bulma.io/documentation/components/navbar/ https://bulma.io/documentation/components/navbar/
- tomohawk 2y ago
  "might as well" Those are the most expensive 3 words in the english language!
  - verdverm 2y ago
    It's very natural for humans to avoid choice perplexity and deviating from the norm when an unknown ROI or LOI is involved for alternatives. Sticking with the tried and true certainty has value and can reduce unforeseen or secondary "costs"
be_erik 2y ago
HTMX + React style server rendered components would solve 80% of the use cases for a modern SPA. Keep going! This is a breath of fresh air for many simpler applications.
- verdverm 2y ago
  I haven't tried HTMX, can it fetch and load html fragments into an existing dom?
  - dlisboa 2y ago
    That's pretty much all it does. It reacts to an event, fetches from an URL, swaps the result from that URL in some part of the DOM.
    - verdverm 2y ago
      Then does the server handling the requests needs to produce html fragments? If I request a page, how does it know to only serve / fetch / render the main content vs the full page? --- It seems like a lot of would be logic a real language has been moved to DSL and strings, i.e. https://htmx.org/docs/#swap-options https://htmx.org/docs/#swap-options `hx-on:htmx:config-request="event.detail.parameters.example = 'Hello Scripting!'"` Not a fan of this fad of moving programming to embedded strings, also seen in lots of Yaml based systems
      - dlisboa 2y ago
        Yes, the idea is to send HTML on the wire. HTMX sends some headers that help you identify the context, this way you can render just a portion of the HTML (e.g. just the partial of the "Todo" list in your "Todo App" homepage). You need some backend logic to handle that but still much less than a full blown JSON API would have. They also have extensions that can diff and merge the DOM so even a full page load would replace just what changed, this way your backend is pretty much unaffected (you just end up serving more MBs). There are other libs in this space by the way, like Unpoly and Hotwire, HTMX just got more mindshare. > Not a fan of this fad of moving programming to embedded strings, also seen in lots of Yaml based systems I absolutely agree. I had a comment thread with HTMX's creator about this, I feel like it's a bad idea to shove logic into that. He also created Hyperscript (https://hyperscript.org https://hyperscript.org) so it's something he doesn't think is an issue. In general I think it's pretty easy to rein that in. Just use HTMX to do most of the plumbing it's strong at (react, fetch, swap) and keep the logic server-side. In my experience that covers the vast majority of web apps. If I absolutely need more client-side logic I'd reach for a little JS code or create a Web Component.
dlisboa 2y ago
You can absolutely do it with HTMX. It'll feel SPA-smooth without all of the complexity. Some companies have rich and responsive UIs using plain HTML and an HTMX-like lib on top of it (like Hey.com). Pretty smooth and can be even reactive. This is a reaction video (sorry) because I couldn't find the original, but in it you see plenty of things associated with SPAs being done in HTMX, from a company that went from React to HTMX: https://www.youtube.com/watch?v=wIzwyyHolRs https://www.youtube.com/watch?v=wIzwyyHolRs Add a few animations and transitions on top and I doubt anyone could tell the difference.

by rkwz 2y ago

verdverm 2y ago

There eventually has to be JavaScript somewhere, and once you have to use that for any dynamic frontend, might as well use a proper JS/TS framework. Not being a frontend person first, I have learned to choose whatever they are using these days. It will be hard to hire, onboard, and maintain anything that strays too far for the normal patterns they use. Next has skyrocketed in popularity for a reason. It makes the React DX much better, losing a lot of the config hell from other framework/library amalgamations

rkwz 2y ago
> There eventually has to be JavaScript somewhere, and once you have to use that for any dynamic frontend, might as well use a proper JS/TS framework. Yes, totally understand it's hard to escape JS in Web frontend. Even writing a simple dropdown requires a little bit of JS. > Not being a frontend person first, I have learned to choose whatever they are using these days. It will be hard to hire, onboard, and maintain anything that strays too far for the normal patterns they use. Since this is for my hobby project, it's more fun to be a irrational ;) I use standard React at work. > Next has skyrocketed in popularity for a reason. It makes the React DX much better, losing a lot of the config hell from other framework/library amalgamations Need to check Next again, I tried it many years back and it was good.
- 8organicbits 2y ago
  If you really want, you can avoid JS for drop down menus too. I've seen the CSS hover [1] and the summary/details [2] approach before. My recent sites use Bulma for all the styling, so the only JavaScript I'm using is the toggle for the navbar burger icon on small screens [3]. [1] https://www.w3schools.com/Css/css_dropdowns.asp https://www.w3schools.com/Css/css_dropdowns.asp [2] https://codepen.io/Ajay-Anand/pen/OJoZjPd https://codepen.io/Ajay-Anand/pen/OJoZjPd [3] https://bulma.io/documentation/components/navbar/ https://bulma.io/documentation/components/navbar/
tomohawk 2y ago
"might as well" Those are the most expensive 3 words in the english language!
- verdverm 2y ago
  It's very natural for humans to avoid choice perplexity and deviating from the norm when an unknown ROI or LOI is involved for alternatives. Sticking with the tried and true certainty has value and can reduce unforeseen or secondary "costs"

be_erik 2y ago

HTMX + React style server rendered components would solve 80% of the use cases for a modern SPA. Keep going! This is a breath of fresh air for many simpler applications.

verdverm 2y ago
I haven't tried HTMX, can it fetch and load html fragments into an existing dom?
- dlisboa 2y ago
  That's pretty much all it does. It reacts to an event, fetches from an URL, swaps the result from that URL in some part of the DOM.
  - verdverm 2y ago
    Then does the server handling the requests needs to produce html fragments? If I request a page, how does it know to only serve / fetch / render the main content vs the full page? --- It seems like a lot of would be logic a real language has been moved to DSL and strings, i.e. https://htmx.org/docs/#swap-options https://htmx.org/docs/#swap-options `hx-on:htmx:config-request="event.detail.parameters.example = 'Hello Scripting!'"` Not a fan of this fad of moving programming to embedded strings, also seen in lots of Yaml based systems
    - dlisboa 2y ago
      Yes, the idea is to send HTML on the wire. HTMX sends some headers that help you identify the context, this way you can render just a portion of the HTML (e.g. just the partial of the "Todo" list in your "Todo App" homepage). You need some backend logic to handle that but still much less than a full blown JSON API would have. They also have extensions that can diff and merge the DOM so even a full page load would replace just what changed, this way your backend is pretty much unaffected (you just end up serving more MBs). There are other libs in this space by the way, like Unpoly and Hotwire, HTMX just got more mindshare. > Not a fan of this fad of moving programming to embedded strings, also seen in lots of Yaml based systems I absolutely agree. I had a comment thread with HTMX's creator about this, I feel like it's a bad idea to shove logic into that. He also created Hyperscript (https://hyperscript.org https://hyperscript.org) so it's something he doesn't think is an issue. In general I think it's pretty easy to rein that in. Just use HTMX to do most of the plumbing it's strong at (react, fetch, swap) and keep the logic server-side. In my experience that covers the vast majority of web apps. If I absolutely need more client-side logic I'd reach for a little JS code or create a Web Component.

dlisboa 2y ago

You can absolutely do it with HTMX. It'll feel SPA-smooth without all of the complexity. Some companies have rich and responsive UIs using plain HTML and an HTMX-like lib on top of it (like Hey.com). Pretty smooth and can be even reactive. This is a reaction video (sorry) because I couldn't find the original, but in it you see plenty of things associated with SPAs being done in HTMX, from a company that went from React to HTMX: https://www.youtube.com/watch?v=wIzwyyHolRs https://www.youtube.com/watch?v=wIzwyyHolRs Add a few animations and transitions on top and I doubt anyone could tell the difference.