5 ms·

> I like to argue that some of the most productive days of the web were the PHP and JQuery spaghetti days I've wondered if going back to that paradigm would be

by pier25 2y ago

> I like to argue that some of the most productive days of the web were the PHP and JQuery spaghetti days 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?

the__alchemist 2y ago
I use this general approach in most cased.
WD-42 2y ago
I just finished migrating a fairly large legacy vue2 app to server side rendering and HTMX. Its thousands of lines less code and also hundreds if not thousands less dependencies. Most importantly I’m not worried about the tech stack becoming abandoned and un updatable in 5 years like vue2 was. 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.
- Jaygles 2y ago
  How much of that code and dependency reduction is due to having the entire app to use as a spec? How can you be so sure this new stack won't be "abandoned"? (Vue has received regular updates for 11 years)
  - WD-42 2y ago
    Vue 2.x is NOT receiving updates. Not even security updates. Its abandonware. 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.
    - pier25 2y ago
      > Vue 2.x is NOT receiving updates. Not even security updates. Its abandonware. 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 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.
      - WD-42 2y ago
        I think npm stats aren’t even the same thing as number of jquery downloads. I bet 99% of the downloads off npm are automated jobs like CI.
    - recursivedoubts 2y ago
      htmx will not be abandoned as long as I'm alive, and the API will not change significantly either i am hoping my oldest son gets interested in computer programming and can take over as the lead eventually
      - kelnos 2y ago
        I haven't done any real web development in over 20 years, but will soon have to build some sort of dynamic web site. I toyed with React 8 or 9 years ago (though never did anything with it, really), and found everything out there to be large and clunky and difficult to work with. 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!
      - WD-42 2y ago
        Hey! Whether your son takes over or not, the larger point I was trying to make is that worst case I can vendor htmx.js with my app and keep it going for a long, long time. Same can’t be said for the vue app and its 1500 dependencies + web pack build chain. At least not as easily.
      - 2y ago
  - ecshafer 2y ago
    Not OP, and this was Hotwire Rails with Stimulus but I also saw a similar reduction in moving a page from React to Hotwire. It was actually a new page, with significant changes so couldn't be trumped up to just a rewrite. But this was easily 1/10th if not more of a reduction in LOC than the similar React app it was replacing, with the more features, and a like a 90% increase in performance.
tobinfekkes 2y ago
Yes, this is 100% of my work.
RadiozRadioz 2y ago
I've found that to be the case for my personal projects. Not less for the fact that I don't have to spend any time googling anything. I can just write code. I've used web tech for so many years that I don't need to learn anything anymore if I'm not in a framework. Outside a framework, it's all just the same stuff that's always been there. 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.
gausswho 2y ago
Steam has largely abandoned it in favor of React in their big facelift a couple years ago.
- pier25 2y ago
  You mean the Steam client or the store? I was referring to the store. Just checked it and there's tons of jQuery and vanilla stuff (at least on the homepage).
  - tpxl 2y ago
    The steam client is a web browser displaying the web page, with a few additional things (like installing games and such).
educasean 2y ago
I think the old way works well for a smaller scale app that doesn't need to change often. Otherwise, I find the components-based code reuse to be a pretty valuable pattern, especially when working as a team.
- wild_egg 2y ago
  There's no reason at all why you can't also organise code into components under this model. Orthogonal concepts
- pier25 2y ago
  Most (if not all) backend frameworks provide components these days. See Laravel, Dotnet, Rails, etc.
bitnasty 2y ago
Not sure if this counts as “going back” but I have been managing a legacy project that is built like this for the past year or two. I hated it at first, but now I’m starting to appreciate it. My approach is to try to put as much as possible in php, but for parts of the page that are going to be manipulated by js/jquery, just have php pass the data as json and build that portion of the dom on the front end.
scrollaway 2y ago
It’s really not more 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.
- pier25 2y ago
  > a good react dev will run leagues around even an a exceptionally good jquery dev It probably depends on the use case, no? If you only need links, forms, and data tables what advantage does React have over SSR + jQuery?
  - morbicer 2y ago
    Non-spaghetti dynamic forms and their validation (yes you need to validate on server as well). 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.
    - pier25 2y ago
      Most modern backend frameworks provide components, types, and validation. Laravel, Dotnet, Rails, etc.
  - klysm 2y ago
    Composabilty and abstraction. I can bang out a react form in our app in minutes just by defining the shape of the fields. All the loading states are handled automatically. Mutations and refreshing data works out of the box. Navigating between pages is instant. Data is cached even when navigating between pages. Some pages that require many user inputs utilize optimistic updates to afford very low latency feedback. React makes all of that easy to compose. I tell it how to render my state, and I write code that updates state.
lelanthran 2y ago
It depends. 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 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?
- tacticus 2y ago
  IMO MPA apps that don't break the back page and support multiple tabs and windows are far easier to have the side by side comparison model than SPAs which get fun dom nonsense the moment you try and do something the dev didn't precisely expect.
  - lelanthran 2y ago
    Broadly, I'm in agreement. 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.
dacryn 2y ago
we more or less do for all the applications in my team, which don't follow the corporate standard. 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...
kukkeliskuu 2y ago
I am have several side projects, and they mostly follow this pattern. For one app, I developed around 100 views (plus the admin views) in Django in just a few months, I could have never done it if I was using a "modern" stack. In many applications most pages (login, registration, logout, entering data etc.) can be built using traditional server-side rendered HTML forms with a little Javascript sprinkled on top, and most of the JS can be handled by Alpine.js. For the pages that need more interactivity, I use HTMX and Alpine.js. It works really well.
wwweston 2y ago
I tacked that direction after my work with early Angular and React sites 2014-2016. It isn’t that I’d never work on an SPA or a site using front-end frameworks like that, it’s that it became very clear to me quickly that they weren’t necessary or particularly helpful for the majority of the sites they were used on (definitely including the sites I was working on, one of which was thrown away entirely months after we delivered it to the client), and how much adoption was resume driven. 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.
nicbou 2y ago
This is how I work. My website is content enhanced with calculators and other widgets. The widgets are individual Vue apps contained within bits of Jinja templates. The backend is an API for the contact forms and the feedback collection forms.

by pier25 2y ago

the__alchemist 2y ago

I use this general approach in most cased.

WD-42 2y ago

I just finished migrating a fairly large legacy vue2 app to server side rendering and HTMX. Its thousands of lines less code and also hundreds if not thousands less dependencies. Most importantly I’m not worried about the tech stack becoming abandoned and un updatable in 5 years like vue2 was. 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.

Jaygles 2y ago
How much of that code and dependency reduction is due to having the entire app to use as a spec? How can you be so sure this new stack won't be "abandoned"? (Vue has received regular updates for 11 years)
- WD-42 2y ago
  Vue 2.x is NOT receiving updates. Not even security updates. Its abandonware. 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.
  - pier25 2y ago
    > Vue 2.x is NOT receiving updates. Not even security updates. Its abandonware. 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 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.
    - WD-42 2y ago
      I think npm stats aren’t even the same thing as number of jquery downloads. I bet 99% of the downloads off npm are automated jobs like CI.
  - recursivedoubts 2y ago
    htmx will not be abandoned as long as I'm alive, and the API will not change significantly either i am hoping my oldest son gets interested in computer programming and can take over as the lead eventually
    - kelnos 2y ago
      I haven't done any real web development in over 20 years, but will soon have to build some sort of dynamic web site. I toyed with React 8 or 9 years ago (though never did anything with it, really), and found everything out there to be large and clunky and difficult to work with. 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!
    - WD-42 2y ago
      Hey! Whether your son takes over or not, the larger point I was trying to make is that worst case I can vendor htmx.js with my app and keep it going for a long, long time. Same can’t be said for the vue app and its 1500 dependencies + web pack build chain. At least not as easily.
    - 2y ago
- ecshafer 2y ago
  Not OP, and this was Hotwire Rails with Stimulus but I also saw a similar reduction in moving a page from React to Hotwire. It was actually a new page, with significant changes so couldn't be trumped up to just a rewrite. But this was easily 1/10th if not more of a reduction in LOC than the similar React app it was replacing, with the more features, and a like a 90% increase in performance.

tobinfekkes 2y ago

Yes, this is 100% of my work.

RadiozRadioz 2y ago

I've found that to be the case for my personal projects. Not less for the fact that I don't have to spend any time googling anything. I can just write code. I've used web tech for so many years that I don't need to learn anything anymore if I'm not in a framework. Outside a framework, it's all just the same stuff that's always been there. 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.

gausswho 2y ago

Steam has largely abandoned it in favor of React in their big facelift a couple years ago.

pier25 2y ago
You mean the Steam client or the store? I was referring to the store. Just checked it and there's tons of jQuery and vanilla stuff (at least on the homepage).
- tpxl 2y ago
  The steam client is a web browser displaying the web page, with a few additional things (like installing games and such).

educasean 2y ago

I think the old way works well for a smaller scale app that doesn't need to change often. Otherwise, I find the components-based code reuse to be a pretty valuable pattern, especially when working as a team.

wild_egg 2y ago
There's no reason at all why you can't also organise code into components under this model. Orthogonal concepts
pier25 2y ago
Most (if not all) backend frameworks provide components these days. See Laravel, Dotnet, Rails, etc.

bitnasty 2y ago

Not sure if this counts as “going back” but I have been managing a legacy project that is built like this for the past year or two. I hated it at first, but now I’m starting to appreciate it. My approach is to try to put as much as possible in php, but for parts of the page that are going to be manipulated by js/jquery, just have php pass the data as json and build that portion of the dom on the front end.

scrollaway 2y ago

It’s really not more 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.

pier25 2y ago
> a good react dev will run leagues around even an a exceptionally good jquery dev It probably depends on the use case, no? If you only need links, forms, and data tables what advantage does React have over SSR + jQuery?
- morbicer 2y ago
  Non-spaghetti dynamic forms and their validation (yes you need to validate on server as well). 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.
  - pier25 2y ago
    Most modern backend frameworks provide components, types, and validation. Laravel, Dotnet, Rails, etc.
- klysm 2y ago
  Composabilty and abstraction. I can bang out a react form in our app in minutes just by defining the shape of the fields. All the loading states are handled automatically. Mutations and refreshing data works out of the box. Navigating between pages is instant. Data is cached even when navigating between pages. Some pages that require many user inputs utilize optimistic updates to afford very low latency feedback. React makes all of that easy to compose. I tell it how to render my state, and I write code that updates state.

lelanthran 2y ago

It depends. 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 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?

tacticus 2y ago
IMO MPA apps that don't break the back page and support multiple tabs and windows are far easier to have the side by side comparison model than SPAs which get fun dom nonsense the moment you try and do something the dev didn't precisely expect.
- lelanthran 2y ago
  Broadly, I'm in agreement. 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.

dacryn 2y ago

we more or less do for all the applications in my team, which don't follow the corporate standard. 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...

kukkeliskuu 2y ago

I am have several side projects, and they mostly follow this pattern. For one app, I developed around 100 views (plus the admin views) in Django in just a few months, I could have never done it if I was using a "modern" stack. In many applications most pages (login, registration, logout, entering data etc.) can be built using traditional server-side rendered HTML forms with a little Javascript sprinkled on top, and most of the JS can be handled by Alpine.js. For the pages that need more interactivity, I use HTMX and Alpine.js. It works really well.

wwweston 2y ago

I tacked that direction after my work with early Angular and React sites 2014-2016. It isn’t that I’d never work on an SPA or a site using front-end frameworks like that, it’s that it became very clear to me quickly that they weren’t necessary or particularly helpful for the majority of the sites they were used on (definitely including the sites I was working on, one of which was thrown away entirely months after we delivered it to the client), and how much adoption was resume driven. 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.

nicbou 2y ago

This is how I work. My website is content enhanced with calculators and other widgets. The widgets are individual Vue apps contained within bits of Jinja templates. The backend is an API for the contact forms and the feedback collection forms.