I've wondered if going back to that paradigm would be more productive or not than using React et al.
Plenty of big sites like Amazon or Steam still are made this way. Not exactly PHP + jQuery but rendering HTML on the server and sprinkling some JS on top of it.
Has anyone gone back to working like that?
There are some pages that require more local state. Alpine.js has been great. It’s like Vuejs that you can initialize on your page and doesn’t require a build step.
Even today's LLM-assisted programming doesn't give me that fluidity. If I use LLMs to assist me in writing a big framework, it'll autocomplete stuff I haven't learned yet, so I need to retroactively research it to understand it.
JS soup on a webpage is a mess, but it's all using the same tools that I know well, and that to me is productive.
Working with react has a higher barrier of entry (something which is becoming less true over time given that many templates etc exist for it), but if you want to be producing pages and functionality, a good react dev will run leagues around even an a exceptionally good jquery dev.
I’m solid at both and we are talking a dev cycle that is magnitudes faster once you are set up reasonably well. There’s a reason it’s popular. Typescript makes a lot of testing unnecessary and gives many guarantees on robustness. React makes it a breeze to create complex state full components. Nextjs makes it super easy to deploy all this to a web app and quickly create new pages.
A shopping site or similar, then sure - the "one thing at a time " workflow works.
For internal line of business apps? I'm not sure sure anymore. From a comment of mine a few days ago: https://news.ycombinator.com/item?id=42148627
> Which is a pity; I was watching a client do some crud work in a webapp.
> Web - 1 form per page:
> Click "back". Copy some text. Click forward. Paste it. Repeat for 3 different fields. Click submit.
> Native apps (VB/Delphi/etc) used to be:
> Open both forms. Copy and paste from one to the other. Open another one on the side to lookup some information, etc.
> Webapps, even moreso with MPA, force a wizard-style interface - you only go forward through the form. This is not how people used to work; they would frequently have multiple forms in the same app open at the same time.
> With SPA and html "windows" made out of movable divs you can probably support multiple forms open at the same time, but who does that?
The maintenance demands for using a heavy, evolving framework and a large graph of churning dependencies are tremendous and perpetual. While you can make meaningful wins on delivery time for a new feature, once "you are set up reasonably well", you've impliclty introduced new costs that don't apply to "vanilla" code that stays closer to established standards and only includes code it actually uses.
That's not to argue that vanilla is strictly better (both have a place), but just to acknowledge a latent but significant tradeoff that your comment seems to ignore.
Reusable components that can be tested in isolation. Type support. That leads to easier evolution and refactoring.
With good architecture you can go mobile with react-native.
They're all Django applications, and the limited dynamic elements are just simple jquery. We have some bootstrap stuff and elements like form elements in javascript, but that's about it.
We are extremely productive, especially compared to our official apps which follow the .NET/Angular stack, that run into all kinds of API versioning issues and errors, it's not even a faster user experience. The problem with such a stack is that you need a few highly skilled architects/system designers. We just have regular programmers piecing it all together, most of them learned these frameworks on the job and come from a regular app dev background, not web.
Granted, we only serve something like 20-30 concurrent users for each of tthe Django apps (as in, page requests/second), but still...
Absolutely. This the reason I'm moving on from JS in the backend. You're constantly stitching up dependencies which might be abandoned and/or become incompatible at any moment.
React makes all of that easy to compose. I tell it how to render my state, and I write code that updates state.
Counterpoint: If you replace a frontend framework with backend components, as has been suggested a few times in this thread, those frameworks are even larger, and a lot of the basic functionality provided by React (such as components) is often provided by third-party packages.
Sure, if you're using something like jQuery, then it's smaller and more stable, but the functionality is limited compared to both backend and frontend frameworks. Which of course might be 100% appropriate depending on the use case.
I had to ask myself if it was worth the hassle to update to 3.x and risk the same thing happening again. The answer was no.
The new stack is Django (which the backend was already written in). Will it stop receiving updates? Extremely unlikely, conserving they have been preserving upgrade paths for the last 20 years and has a solid foundation supporting it.
The supporting ui libraries like htmx and alpine could conceivably become abandoned. The big difference is that they can be vendored easily.
I checked the vue project and it has 1500 transitive dependencies. The new “stack” has a whopping total of 7.
On top of that there is no build step to maintain. Also it’s straight up way faster.
I algo got burned with Vue 2 at one point. Pretty amazing considering Vue is quite popular. Recently went over 1M daily downloads.
https://npm-stat.com/charts.html?package=vue
I don't think even jQuery had so many downloads back in its heyday but it has maintained its API and methodology after all these years.
i am hoping my oldest son gets interested in computer programming and can take over as the lead eventually
I came across htmx a while back and have kept it in the back of my mind as something to potentially use if I ever had to build something. I'm glad this article came up on HN, and your comment here... makes me really want to build something with htmx!
Same can’t be said for the vue app and its 1500 dependencies + web pack build chain. At least not as easily.
But the folks using the company's line-of-business apps mostly aren't even aware that the browser can open a particular part of the app in a new tab, and even when they are, they aren't aware that the tabs can be torn off into separate windows, and of those that do, there are still some who wouldn't figure out that both browser windows can be tiled side-by-side.
And even when you pass all those hurdles, it's still disruptive enough to the normal workflow that most people who can do that won't do it at all anyway.
I used to assume React solved genuine problems for FB but given ways in which the UX+performance has gotten worse, I’m not even sure about that.
Meanwhile html plus progressive enhancement works fine for the majority of projects I’ve been involved in. Componentization can still be a win but there’s other ways to do it.
The backend is an API for the contact forms and the feedback collection forms.
Sacrificing the first born as god intended.
Is putting in a couple of lines of JS that has no knowledge of the backend-managed good enough for small one-off pages? Maybe. But it's definitely not composable and abstractable, which was the original claim.
Or if the forms have to sync with the backend then there are other React-less options, for example:
Some forms are simple enough that you don't need composition and abstraction, yes, no-one's denying that.
> Or if the forms have to sync with the backend then there are other React-less options, for example:
> https://htmx.org/examples/value-select/
Ok, now try composing that. What happens when you want to nest one of those inside another (i.e. have 3 levels of selection)?
Here's the most dynamic form I can think of: https://www.globalgolf.com/golf-clubs/1064148-titleist-tsr2-...
Any input change triggers any/all other inputs to change.
Looks like they send the entire page each action, no React, yet the user experience is much better than the typical competitor site where they've overengineered the whole front end.
Their faceted search is nice too: https://www.globalgolf.com/golf-clubs/used/titleist/fairway-...
Notice how when you add a filter it updates the URL. Breath of fresh air.
And this is way beyond what I had in mind when I read links, forms, and data tables.
This stubbornly stupid mindset is why we have wars.
Edit: I checked the site myself and was able to reproduce the issue mentioned in GP. This is a terrible website.