Get the top HN stories in your inbox every day.
samwillis
andy800
> 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.
MatthiasPortzel
The slippery slope that scares me (as a React developer) about htmx (or Hotwire.dev, in particular is the one I was looking at), is that you start making the assumption that the client's internet is fast.
There was demo that showed it normally takes ~100ms to click a mouse, and if you attach to the on-mouse-down, then by the time the mouse has been released (100ms later), you can have already fetched an updated rendered component from the server.
And while that's very cool, my second reaction is "is it ever acceptable to round-trip to the server to re-render a component that could have been updated fully-client side?" What happens when my internet (or the server) is slow, and it takes more than 100ms to fetch that data? Suddenly that's a really bad user-experience. In the general case this is a subjective question. I personally would rather wait longer for the site to load, but have a more responsive site once it did.
There's not a perfect solution to this, because in a complex site there are times that both the server and the client need to update the UI state. But having the source of truth for the UI located in a server miles away from the user is not a general-purpose solution.
(I'm not advocating for the status quo, either. I just wanted to bring up one concern of mine.)
wwweston
> you start making the assumption that the client's internet is fast.
The most common trajectory for react and other SPA framework apps is to also make this assumption, waving away the weight of libraries and front-end business logic with talk of how build tools are stripping out unused code so it must be light, while frequently skipping affordances for outright network failure that the browser handles transparently, oh and hey don't forget to load it all up with the analytics calls.
But maybe more crucially: what's the real difference between the overhead of generating / delivering markup vs JSON? They're both essentially data structure -> string serialization processes. JSON is situationally more compact but by a rough factor that places most components on the same order of magnitude.
And rendered markup is tautologically about the data necessary to render. Meanwhile JSON payloads may or may not have been audited for size. Or if they have, frequently by people who can't conceive of any other solution than graphql front-end libraries.
Whether you push html or json or freakin' xml over the wire is a red herring.
Heck, "nativeness" might be a red herring given frequent shortcomings in native apps themselves -- so many of them can't operate offline in spite of the fact that should be their strength because native devs ALSO assume client's internet is fast/on.
mediumdeviation
For a real world example of this, GitHub uses server-side rendered fragments. Working with low latency and fast internet in the office, the experience is excellent. Trying to do the same outside with mobile internet, and even with a 5G connection, the increased latency makes the application frustrating to use. Every click is delayed, even for simple actions like opening menus on comments, filtering files or expanding collapsed code sections.
I'm actually worried about developers in developing countries where mobile internet is the dominant way to access the Internet and GitHub is now the de facto way to participate in open source, that this is creating an invisible barrier to access.
gspencley
As someone who has been writing code for 30 years and has been developing "web apps" since the late 90s, it's really funny to me how things come full circle.
You just described the entire point of client-side rendering as it was originally pitched. Computation on the server is expensive and mobile networks were slow and limited in terms of bandwidth (with oppressive overage charges) just a few years ago. Client-side rendering was a way to offload the rendering work to the users rather than doing it upfront for all users. It means slower render times for the user, in terms of browser performance, but fewer network calls and less work to do server-side.
In other words, we used to call them "Single Page Web Applications" because avoiding page refreshes was the point. Avoid network calls so as to not consume bandwidth and not make unnecessary demands of the server's limited computational resources.
Now things might be changing again. Mobile networks are fast and reliable. Most people I know have unlimited data now. And while computation is still one of the more expensive resources, it's come down in the sense that we can now pay for what we actually use. Before we were stuck on expensive bare metal servers and we could scale by adding a new one but we were likely overpaying because one wasn't enough and two was way overkill except for peak traffic bursts. So we really scrambled to do as much as we could with what we had. Today it might be starting to make sense to make more trips back to the server depending on your use case.
To address your concern about latency or outages, every application needs to be built according to its own requirements. When you say "there's not a perfect solution to this", I would say "there is no one size fits all solution." We are talking about a client / server model. If either the server or client fails then you have failed functionality. Even if you can get yourself out of doing a fetch, you're still not persisting anything during an outage. The measures that you take to try and mitigate that failure depend entirely on the application requirements. Some applications strive to work entirely offline as a core feature and they design themselves accordingly. Others can accept that if the user does not have access to the server then the application just can't work. Most fall somewhere in between, where you have limited functionality during a connection interruption.
nickjj
> There was demo that showed it normally takes ~100ms to click a mouse, and if you attach to the on-mouse-down, then by the time the mouse has been released (100ms later), you can have already fetched an updated rendered component from the server.
I think what you're describing is a form of preloading content but it's not limited to React.
For example:
The baseline is: You click a link, a 100ms round trip happens and you show the result when the data arrives.
In htmx, Hotwire or React you could execute the baseline as is and everyone notices the 100ms round trip latency.
In React you could fetch the content on either mouse-down or mouse-over so that by the time the user releases the mouse it insta-loads.
But what's stopping you from implementing the same workflow with htmx or Hotwire? htmx or Hotwire could implement a "prefetch" feature too. In fact htmx already has it with https://htmx.org/extensions/preload/. I haven't used it personally but it describes your scenario. The API looks friendly too, it's one of those things where it feels like zero effort to use it.
Hotwire looks like it's still fleshing out the APIs for that, it has https://turbo.hotwired.dev/handbook/drive#preload-links-into... for pre-loading entire pages. There's also https://turbo.hotwired.dev/reference/frames#eager-loaded-fra... and https://turbo.hotwired.dev/reference/frames#lazy-loaded-fram... which aren't quite the same thing but given there's functionality to load things on specific events it'll probably only be a matter of time before there's something for preloading tiny snippets of content in a general way.
Winsaucerer
> I personally would rather wait longer for the site to load, but have a more responsive site once it did.
If react sites delivered on that promise, that would be compelling. However, while my previous laptop was no slouch, I could very often tell when a site was an SPA just in virtue of how sluggish it ran. Maybe it's possible to build performant websites targeting such slower (but not slow!) machines, but it seemed that sluggish was quite often the norm in practice.
robertlagrant
I wouldn't assume a fragment is any bigger than the raw data when it's compressed.
{ "things": [
{ "id": 183,
"name": "The Thing",
"some date": "2016-01-01",
},
{ "id": 184,
"name": "The Other Thing",
"some date": "2021-04-19",
},
]}
<tbody>
<tr><td>183</td><td>The thing</td><td>2016-01-01</td></tr>
<tr><td>184</td><td>The other thing</td><td>2021-04-19</td></tr>
</tbody>
hermanradtke
We have a set up like this at my job. The servers are based in the Pacific Northwest. We have users in Europe and India.
You can guess how awful the user experience is.
diceduckmonk
It’s almost as if developers are treating latency as having a kind of Moore’s law as with memory or cpu.
samwillis
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.
nawgz
I think that if you’re building tools and you want to do anything nice like optimistic rendering it’s not possible in HTMX, so I always wonder what kind of user experience is actually delivered on an HTMX app
jbverschoor
Oh god please let’s not go back to JSF
jaytaylo
How was it worse than the current state of affairs of complexity with React? Bowser, npm, typescript, obfuscation, compressors, build pipelines.. it’s a lot. Life at the front-end today is so discombobulated, creating a bunch of backend APIs which will generally only be used and consumed by a single browser front-end.
I’m genuinely curious, because I never used JSF except for a single school exercise
ris58h
> Do you really need to be managing state on the client? Sometimes an "app" needs to work offline.
branko_d
I think the point of a SPA is not how to refresh the screen when you have to do the round-trip to the server. The point is that you can do more things without making the round-trip in the first place.
galaxyLogic
> Why have HTML elements react to changes in data or state, rather than just insert new HTML elements already updated with the new state?
But what's the big difference? Something somewhere must react to change. Either modify the DOM by client-side code, or modify/replace it by loading content-fragments from the server.
I would (perhaps naively) think that doing more on the client is faster than both re-rendering on the server and reloading from the server. Maybe it's just that React is too big and complicated and therefore slow.
ksec
Somewhere along the line the only accepted voice in the industry was everything has to be Javascript. I still have no idea why HTML5 hasn't evolved to include features purposed by HTMX.
> It’s the 5% where htmx is not one of the right choices at all.
I think even 5% is an over-statement. In my Top 100 site visit per month, the only three site that were SPA are Gmail, Feedly and Youtube. And I dont see how any of these three couldn't be done in HTMX. The Web Apps, if we call it that, that actually requires heavy JS usage are Google Work, Sheets, Google Map and Google Earth, and possibly some other productivity tools like Figma.
hsbauauvhabzb
What security issues does server rendering solve? I resent that every website needs to be an SPA, but from a security perspective I’ve concluded that the clearer line in the sand that SPA application architectures creates is better than the security challenges that can result from server side rendering.
Navigating the risks around the NPM supply chain is another story, but I suspect it will be solved by large / popular frameworks gradually pruning their own dependency trees resulting from downstream pressure in the form of pull requests.
Winsaucerer
Here's one I've experienced. Suppose you have a table of customers, and you want to show an extra column of data on that page showing total orders, if and only if the viewer of that table has the manager role.
With an SPA, you'll be building an API (perhaps a 'REST' one, or GraphQL) to expose all the data required, such as customer name, email, etc, as well as the extra 'total orders' field iff they have the manager role. Now you need to make sure that either (a) that endpoint properly excludes that 'total orders' field if they lack the permission, or (b) you have a separate endpoint for fetching those kind of stats and lock that behind the role, or (c) (I hope not) you just fetch all orders then count them up! Now, having properly secured your API so that all and only the right users can get that data, you have extra logic in your front end such as 'if has role manager then show this column too'.
With a server side rendered page, you don't have to do the API security bit. You can just fetch all the data you like (often via a single SQL query), and then replicate the same extra logic of 'if has role manager then show this column too'. You've skipped the whole "make sure the API is secure" step.
Now suppose you want to add a dashboard for every admin user, not just managers, showing total orders system wide. Did you include that in your API already? Now you're likely going to need a new endpoint that allows any such user to fetch total system orders, while managers are still the only ones who can fetch per customer order totals. Having found a place to add that to your API, you can render it. With the server side page, there's no extra work to keep this secure. The dashboard is already restricted to the users who can see it, so just add the extra query to fetch total orders and display it.
In short, there's a whole layer that an SPA needs to secure for which there is no analogue with a server side rendered site. In an SPA you secure the API and then have the logic for what to show to whom. For the server side rendered site, you just have the logic for what to show to whom and that gives you the security for free.
capn_duck
Yes yes yes. You're not going to get much appreciation of this from newer devs. They've only known one thing. I shudder at all the human-hours spent on duplicative tasks related to the artificial frontend/backend separation.
jcparkyn
As a slight counterpoint to that scenario, the front-end can often just get away with just checking whether the data exists in the response, rather than checking roles. This isn't quite as simple as the SSR alternative, but it at least removes most of the hassle with making sure the permissions match on server and client.
However, this doesn't help much when the restricted data is on a separate endpoint, since the app needs to decide whether to make the request in the first place.
solardev
Can't the backend decide which fields to send back in a JSON, the same way it would decide which HTML columns it would've rendered?
The front-end can pass a user role with every request and render whatever the backend sends it into a table.
wruza
manager role column
Tbh, I’d prefer a runtime which would be itself aware of such metadata, knew the role out of a request/session context and could build a ui table based on all-columns-ever template, from a query automatically built for this specific case, because querying and throwing away totals may be expensive. This manual “do here, do there” is a sign of a poor platform (not that we have a better one) and code-driven rather than data-driven access control in it. Painting walls and installing doors every time you want a meeting should not be a part of a business logic, regardless of which-end and its implications.
meekaaku
I do case (a) like this with SPA. Call to /orders (or any endpoint) will check roles/permissions and runs the proper query. A normal user will get [{name, email}], but a manager will get [{name, email, num_orders}]. A normal user call will not have the COUNT(*) from orders part anyway in SQL query (which is expensive). Only a manager's call will have that part. Most likely number of managers will be less than users, so the users get faster results. The results are returned to front end and if the {num_orders} column exists, it is rendered. Front end doesnt have to bother with any access control logic.
For the server-side rendered page, what seems to me is you are running same query for normal users and managers, which is fine too, but removing that num_orders column.
Ultimately in both cases, the access control logic happens on the server, and frontend don't have complicated access control logic anyway. My point is, with SPA also we can get the same server-side benefits, atleast in this case. Or am I missing something?
ec109685
If you have non-html native mobile applications, you’ll need to have that complexity regardless of the techniques used to construct web page.
spion
What do the tests look like for this? How do you check that you're not exposing the sensitive data?
0xCMP
I think anywhere you introduce more complexity, more ways for things to interact, it's inherently less secure without the additional work checking for both the App + the API being secure on their own.
stickfigure
There's no such thing as a secure "app". Only the API needs to be secure. That's more straightforward when your API looks like REST/RPC calls rather than "renders html templates to a string".
FpUser
>" think anywhere you introduce more complexity"
When your website is the actual complex application SPA makes very much sense and is actually less complex. And no you do not have to download all of it into a browser. Load parts replacing some inner html with the other and scripts on on need basis. Works like a charm. I am using couple of JS libs but no framework and there is no need to "build".
As for security - JS app talks to my own C++ backend using some JSON based RPC so I just have to validate the API only which is way less work as well.
recursivedoubts
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.
duxup
I’ve been exploring various alternatives and I’m certainly of the same mind as you.
It’s always trade offs and that’s fine.
What I find interesting/ frustrating is every framework or option likes to sell you on some numbers that are very nice but so specific they’re not the big picture. And/or talk about how they are different / better than another framework that I might not even be familiar with.
Technical pages now have their own confusing sort of developer marketing.
ChrisDevx
I have 2 problems with htmx (IMHO):
1. SoC: the server API needs to return only the data and meta data requested, and it should not be concerned with the display-layer (html), because many different clients i.e. mobile app, browser, Electron etc. might want to consume this API.
2. Logistics & scaling: Imagine a large application with 100s of html/htmx components and views, now you alter your database, you introduce new business rules etc... If you used React or Alpinejs etc. you could just go to the relevant stores or app code and make the change as opposed to sifting and refactoring tons of html.
Personally I'd rather just use Alpinejs from the start, knowing its lightweight, fast and easy to implement, and not end up painting myself into a corner over the application lifecycle.
recursivedoubts
1. https://htmx.org/essays/locality-of-behaviour/
2. many large applications use htmx (or related approaches like hotwire, unpoly, etc.) and scale fine. hypermedia is better at handling databaase/logic/API changes than fixed-format data APIs because your API is encoded within hypermedia responses: https://htmx.org/essays/hateoas/
ChrisDevx
LoB yeah, on small scale perhaps, I guarantee you will end up with a cluttered mess on large applications, unless you spend a ton of extra time/work to design for scale, maintenance and dev onboarding.
I do not agree with HATEOAS, so now you have an API which job is to produce html (SoC problem), and what if a Flutter app also needs to consume this API, do you build another HATEOS API just for Flutter?
Every few years its the same, devs adopting and defending the new shiny thing, though I have to admit, I love that this time its a way more simplified, sane alternative.
rmbyrro
I also like htmx and this kind of comparison is fruitless. The executive summary talks about LOC, build time, # of JS dependencies, etc. Nobody started using React because of these things, so it misses the point. It doesn't compare htmx to react on the matters that really matter to people who chose react...
danielvaughn
Some years ago, a bright guy created something called 7 GUIs. It’s a collection of seven problems that all UI systems must successfully implement, and it was intended to act as a guide for comparisons.
Unfortunately I think the author has passed away, but it would be interesting to see it rekindled and used for baseline comparisons like these.
edflsafoiewq
I don't think Htmx is a good fit for those. I wouldn't want a server roundtrip for any of them (except maybe part of CRUD).
tomhallett
Wow, this is very cool! I think this applies not only to gui frameworks (react vs htmx), but also to design systems (bootstrap, tailwind ui, etc).
undefined
parhamn
There are four main problems in the React SPA world:
- State management - hooks are awful for anything complex
- Packaging + Bundling - Webpack kitchen sink, JS/TS, browser vs node vs random runtimes, packaging vs bundling, etc
- Data/API binding - Adds distributed state to your data and the complexity that goes with that (cross dom reuse, caching, staleness, realtime updates, etc)
- SEO/Prehydrating - Mostly applies to landing/CRM/blog type things.
These 'old school' solutions help you avoid some of these issues in favor of relocating the complexity a bit (those templates in the talk are absolutely gnarly and I'm sure very bug prone) and reducing the experience. Also the API boundaries are blurred should you ever need one for non UI usage. Ignoring HackerNews taste for simpler websites, some complexity of UIs can and should only be captured with client sided javascript.
With that said, after a few years of things shifting around I'm really happy with the Typescript (lang) + Parcel (packaging) + MobX (state management) + Vercel (when server side rendering is needed). They've been really stable, no fuss, always work. Especially MobX for state, absolutely game changing for the dev experience.
As for the data binding problem, still sucks and my 4th attempt at solving it internally is still meh. This feels like it comes with the territory.
As much as I loved my working with Django/Jinja2/etc, I think theres a light at the end of this tunnel.
Humphrey
I've solved your data binding problem with: GraphQL (server) + UrQL (JS graph client with the graphcache plugin) + GraphQL Code Generator (creates TS types for your API).
The data syncs perfectly, keeps up-to-date. GraphQL subscriptions allow for real time updates. Oh, and React-Hook-Form for forms, which feeds quite nicely into my GraphQL mutations. It's a real neat solution.
As for server side, I've started using Python-Strawberry (was using Graphene but it stopped receiving updates) with Django.
It's super solid stack, with typings flowing all the way from server API through to my react components.
ksbrooksjr
Htmx is great for developers who need client side interactivity, but would rather not write any js. If you don't mind writing a bit of js however, you can't go wrong with Preact. Same api as React, but at a fraction of react-dom's bundle size. It looks like the minified source is even smaller than htmx (which is already very minimal) [1][2]. They've also packaged Preact in such a way that you don't need to add a build step to use it [3].
[1] https://unpkg.com/browse/htmx.org@1.8.2/dist/
[2] https://unpkg.com/browse/preact@10.11.2/dist/
[3] https://preactjs.com/guide/v10/getting-started#no-build-tool...
flexterra
The programming model is totally different when working with HTMX. The server returns HTML instead of a JSON API which is the usual solution when building apps with React/Preact and similar.
ksbrooksjr
Yea htmx definitely has a different programming model than an SPA style framework like React/Preact. I actually like the JSON api programming model where the backend is as simple as possible, and the frontend js/ts code is completely responsible for handling the UI, but I guess it's a matter of personal preference.
The linked article is referring to a team switching from React to htmx though, so for them I'd imagine it would've been a much easier transition if they'd just added a Webpack alias[1] that replaced React with preact/compat, rather than switching to a completely different UI paradigm.
[1] https://preactjs.com/guide/v10/getting-started#aliasing-in-w...
flexterra
The difference in programming model IS THE advantage of HTMX. Changing from react to preact is a perf optimization.
If you are doing the SPA thing correctly you must duplicate business logic (data validation). Also when your API just sends "dumb data" (JSON) to the client, you are forced to make changes to the backend and frontend in lockstep.
zarzavat
How do you implement, e.g. a sortable table if the server sends HTML rather than JSON? Have we gone full circle and gone back to jQuery?
flexterra
Here's the sortable example: https://htmx.org/examples/sortable/
IMHO something slightly more complex than this example (more client side stat) will require using something like React/Vue/Svelte. But there's no need to rewrite the whole FE. Just create a component that performs the rich client side interaction and use HTMX for the rest of your app. Win-Win.
password4321
> The server returns HTML
So back to ASP.NET WebForms update panels?
Void_
I was just picking technology for my new landing page and was looking into Preact first.
I wanted basic SSR and things like that. Preact has a library called preact-cli for this. The last commit is from Aug 17.
I ended up with SvelteKit. It just felt much more alive. I don't love learning a new technology just for a landing page, but that was kinda fun.
rrdharan
> The last commit is from Aug 17. I ended up with SvelteKit. It just felt much more alive.
I don’t understand - are you saying you think a project whose most recent commit was Aug 17, 2022 is not alive?
ipaddr
Was the worry Aug 17 less than two months ago a sign the project was abandoned? Daily changes would worry me more.
eyelidlessness
Especially given the team has been actively working on a major version for several months and released an impressive improvement to their state model in the last month. They’re active and thoughtful about what they ship.
ksbrooksjr
Svelte is another great option with a much smaller footprint than React. If you don't feel like setting up SSR by hand, you can also just use Next.js which works fine with Preact [1].
[1] https://github.com/vercel/next.js/tree/canary/examples/using...
nateberkopec
Preact is not a good comparison. If it "has the same API as React", then it's not solving any of the problems that the post talks about.
Bundle size is 1 problem of JS-heavy SPAs but the post goes into many other drawbacks not addressed by something like Preact.
ksbrooksjr
Preact would solve most (if not all) of the performance problems listed in the executive summary of the post (build time, time to interactive, memory usage, and maximum data set size). It doesn't seem like a terrible comparison to mention a framework with the exact same api as the one the team in the post was using for 2 years before adopting htmx.
It's a pretty short post, but a lot of it boils down to the fact that the team is using a single language throughout the whole stack (Python), which allows everyone on the team to be a full stack developer. Like I said, if you're against writing js then htmx is probably a better solution for your team.
criddell
If you want a non-JavaScript client, ditch the browser all together and build a native client.
lliamander
I think you have it backwards.
If you want to build a client using HTML, then targeting the browser is exactly the right choice.
Javascript-heavy SPAs are much closer to traditional native apps - and lose some of the benefits of running on the web/ in the browser as a result.
There's a lot more reason to consider native app if you are building an SPA than if you are building an MPA/SSR app.
criddell
I'm suggesting not using HTML for the client. Anything running in a browser is heavy and slow compared to well written native code.
xutopia
People forget that React can be used for just the complex components that require it. Your entire page need not be a React app just because you use it for one component.
To me it's bonkers that all web sites seem to be moving towards SPA when they don't benefit from it at all and require so much frontend work when a little bit of simple HTML and Javascript could do most of the work. It feels like the whole industry is Reactifying everything because they're scared that if they don't they won't look professional.
rchaud
React has a self perpetuating marketing machine. From boot camp courses to YouTube how-tos and frequency plof appearance in job description requirements, people end up hiring React developers who want to build the sites in React.
veidelis
What is your point exactly? Please explain why is that bad and how the whole problem can be solved better - which lib or approach etc?
generichuman
People think React or similar SPA libraries are the way to do frontend development, so all frontend development seems to be React at this point.
"When all you have is a hammer, everything looks like a nail" is the problem. Another new library / framework will not solve this.
Frontend dev should go for the bare minimum when designing web sites, only introduce libraries as they're needed -- and really think about whether they're really needed or not. They need to ask some questions like:
- Maybe you can roll your own specialized solution that'll be smaller and faster than a general solution? - Does the thing you're working on need to be an SPA or does a good old multi-page web site be enough for your use case? - If you need parts of your website to be interactive, can you only update that part (the "islands" approach) by hand instead of introducing a dependency to do that?
There is a lot of complexity going on in our field right now and not enough people seem to care about that. The complexity is needlessly inflating our application / web page sizes and reducing performance.
rchaud
The point is that React has become the IBM of web app frameworks, in the "nobody got fired for using IBM" sense.
Your CTO, PM, frontend dev and DevOps people likely all have React experience under their belt. So it isn't surprising if React ends up becoming the framework of choice, simply because it will likely be faster to start with.
larrymyers
This is an excellent point. It's a philosophy that I think Astro gets right.
https://docs.astro.build/en/concepts/islands/
Combined with Preact instead React I think it allows for server content first, and sprinkling in interactive components as needed without much extra page size.
At the end of the day a good component based js framework makes it a lot easier to implement a lot of things client side.
smrtinsert
Resourcing for frontend is basically hiring for the superset of frontend tech. Once you have that team in place of course they'll use the tool that has the most options. It's a safe bet even if its not the best performance, and it's important on the resume.
hunterb123
What's the issue with using Next/React to build static and SSR web pages?
React doesn't only work for SPA.
ec109685
If that requires full client side re-hydration in order for those SSR pages to become interactive, then the user receives a worse experience.
larrymyers
It's also a bit shocking how much javascript and json get loaded client side to facilitate this hydration for Next.js.
fareesh
I am fortunate to have gone 10 years without having to use react in production ever.
I've used rails+turbolinks and included Vue or Stimulus or even jQuery to get on page interactivity done.
The current state of the react / jam world strikes me as an HR led solution where you can get humans who only know JS to be more productive without having to worry about servers, databases or infrastructure.
have_faith
It’s not the most popular framework in the world for web apps because it pleases front end devs who are scared of the backend.
quickthrower2
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
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.
silver-arrow
We have experienced similar results moving to htmx and a hypermedia approach for building dynamic web apps. It simplifies development greatly and has resulted in better productivity.
Like the results cited here, we too are extremely pleased that the majority of our coding now falls into our preferred language - Clojure (using Hiccup). Very pleasant experience!
jakebasile
As an aside, the author of this project is also the author of grugbrain.dev, the most wonderful and accurate software development site I've ever encountered.
nikodunk
Wow!! This site made me laugh a few times while collecting these great lessons. Very well written!
temp20202020
I am in a remote village in India, Assam, Barpeta, Maranadir par. htmx or hotwire or pjax works great here on my 4g mobile network (Jio, Airtel) and surprisingly 3g BSNL (govt. supported isp). I think at least in India internet speed problem is a solved problem.
xwowsersx
Link to the talk mentioned if you were looking for it as I was: https://youtu.be/3GObi93tjZI
sergiomattei
A note I’ve internalized lately: there is a middle ground.
You can write excellent, lightweight React apps by simply writing semantic HTML and taking advantage of the platform (declarative form validations, a simple CSS pipeline, etc). It doesn’t have to be madness in the front-end.
NextJS, in particular, keeps the build pipeline quite simple.
chrisweekly
In the React ecosystem, Remix.run embraces a much simpler approach than Next.js.
Get the top HN stories in your inbox every day.
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.