[HN Gopher] A Real World React - Htmx Port
___________________________________________________________________
A Real World React - Htmx Port
Author : mpweiher
Score : 65 points
Date : 2022-10-15 20:43 UTC (2 hours ago)
(HTM) web link (htmx.org)
(TXT) w3m dump (htmx.org)
| endisneigh wrote:
| serve side rendering is ideal, but at the end of the day what
| matters these days is developer productivity. a better question
| is how long it takes to make something like gmail with htmx vs.
| say react. you might say most apps are not gmail, and you'd be
| correct. so then you say, ok what about something like wikipedia?
| easy enough. then you start adding all of this javascript and it
| becomes a mess.
| pen2l wrote:
| One reason I prefer doing React is that retrofitting existing
| React stuff for React Native is better/easier than embarking on
| React Native from scratch.
| samwillis wrote:
| I would argue that most "apps" built with React Native don't
| need to be apps at all, they are better as websites.
|
| The majority of these apps are about placing the existing
| product into the App Store for discoverability, and encouraging
| users to be "locked" into the app at the expense of a worse
| customer experience.
|
| A web app, in a browser, automatically has support for opening
| multiple pages as multiple tabs, bookmarks, sharing pages. You
| can't do that with 99.9% of apps.
|
| I will also argue strongly that, again, react native is
| unnecessary even if you do want to package a native app.
| WebView based apps perform as well as a react native app, and
| most of the time with significantly less additional code. It
| also forces you to up your "mobile website" UX. In general the
| minuet you build a mobile "app" the mobile web experience gets
| neglected.
| recursivedoubts wrote:
| TLDR:
|
| - Took 2 months (21K LoC, mostly JavaScript)
|
| - No reduction in user experience
|
| - Reduced LoC by 67% (21,500 LoC to 7200 LoC)
|
| - They increased python by 140% (500 LoC to 1200 LoC), good if
| you prefer python to JS
|
| - Reduced JS dependencies by 96% (255 to 9)
|
| - Reduced web build time by 88% (40s to 5)
|
| - First load time-to-interactive was reduced by 50-60% (from 2-6
| seconds to 1-2 seconds)
|
| - Much larger data sets were possible than react could handle
|
| - Memory usage was reduced by 46% (75MB to 45MB)
|
| These are spectacular numbers that reflect that the application
| in question is highly amenable to the hypermedia approach.
|
| I wouldn't expect everyone to see this level of improvement, but
| at least some web apps would.
| [deleted]
| keizo wrote:
| Speed is the big one for me. 2-6+ seconds is insanity for
| anything.
| funstuff007 wrote:
| I hear you, but YouTube takes 6+ seconds for me to load and
| it does not seem to hold them back. For most, not all,
| optimizing page load time is time probably best spent
| elsewhere. This is is no way to impugn htmx, because with
| htmx you seem to kill many birds with one stone.
| recursivedoubts wrote:
| Speed is definitely a big one.
|
| I also am glad to see that everyone on the dev team became
| full stack developers, because I think the back-end/front-end
| split is often detrimental to development velocity. It's
| often better when a developer can fully realize an entire
| feature, with no front-end/back-end friction.
| keizo wrote:
| Oh for sure. For me programming is a hobby, so I can only
| get something made if I do it all.
| samwillis wrote:
| Love htmx and this talk is a brilliant run down of where it works
| well.
|
| But as always it's about choosing the right tool for the job.
| Server rendered pages/fragments solve so many issues around
| security and time to develop a product, however it only gets you
| so far.
|
| Ultimately I think the decision when choosing a stack comes down
| to how much state you need to managed in browser. The vast
| majority of sites needs very little client side state management,
| htmx and other tools such as Alpine.js are perfect for this. But
| eventually as you reach a more "app like" experience with
| multiple layers of state control on the front end you need to
| reach for a front end JS framework.
|
| Now that doesn't always mean going all in on a full SPA covering
| the whole of your product. It could just be a small fragment that
| requires that level of interaction.
|
| Point is, don't pick a tool because it's "in vogue", pick one
| because it lets you build the best possible product as
| efficiently as possible. For 80% of websites that could be htmx,
| and for the next 15% htmx probably works for 90% of their pages.
| It's the 5% where htmx is not one of the right choices at all.
| recursivedoubts wrote:
| I am in 100% agreement with you: pick the right tool for the
| job.
|
| My hope is that, with htmx, HTML/hypermedia is that right tool
| for more jobs.
| andy800 wrote:
| > as you reach a more "app like" experience with multiple
| layers of state control on the front end you need to reach for
| a front end JS framework
|
| I think that if you fully embrace HTMX's model, you can go far
| further than anticipated without a JS framework. Do you really
| need to be managing state on the client? Is it really faster to
| communicate via JSON, or protobuf, whatever, rather than atomic
| data and returning just small bits of replacement HTML --
| inserted seamlessly that it's a better UI than many client-side
| components? Why have HTML elements _react_ to changes in data
| or state, rather than just insert new HTML elements already
| updated with the new state?
|
| I think you're describing a, let's do React in HTMX mindset,
| rather than let's go all in on the HTMX model. And I might be
| giving HTMX too much credit, but it has totally changed how I
| go about building web applications.
| samwillis wrote:
| Oh, I completely agree with you. The vast VAST majority of
| sites don't need that level of client side state management.
|
| I'm currently working on a bio-informatics data modelling web
| app where htmx would not have been the right choice. But it's
| in that 1-5% where that is the case. That's kind of my point.
|
| Outside of that project, I'm all in on the the HTMX model of
| server side rendered fragments.
| dhucerbin wrote:
| Listing template dependencies as event names that can change
| underlying data seems very brittle (hx-trigger for favorite
| articles). You would need at least integration tests to get some
| confidence! Can't we infer used state in template and setup
| triggers for developer? LiveView gives better DX in this case.
| quickthrower2 wrote:
| It is a cliche but probably true: Second rewrite will be better
| by those sort of metrics even without a tech change. Lessons
| learned get applied. Domain is fully known.
|
| I definitely believe in fewer LOC with any not-react due to all
| the hooks, memo, etc. boilerplate though!
| recursivedoubts wrote:
| This wasn't a complete rewrite, it was a feature-for-feature
| rewrite of the front-end, moving from react to htmx, mainly as
| a proof of concept at first. Note that the amount of python
| actually increased, as logic was moved back to the server.
|
| While I'm sure there were a few places where better decisions
| were made, I think it's reasonable to assume that the majority
| of the reduction in code is due to the different approach to
| front end development.
| gardenhedge wrote:
| I consider this an alternative development approach neither
| better or worse than what it is trying to replace. The winner in
| recent approach, imo, is Remix Run.
| recursivedoubts wrote:
| Reducing a code base by 2/3rds isn't better than what it
| replaced?
|
| At least in some sense?
___________________________________________________________________
(page generated 2022-10-15 23:00 UTC)