←back to thread

260 points gherkinnn | 1 comments | | HN request time: 0s | source
Show context
pier25 ◴[] No.42164501[source]
> 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?

replies(13): >>42164565 #>>42164636 #>>42164646 #>>42164666 #>>42164714 #>>42164722 #>>42164754 #>>42164840 #>>42164957 #>>42165180 #>>42166069 #>>42169495 #>>42169508 #
scrollaway ◴[] No.42164840[source]
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.

replies(2): >>42164893 #>>42164963 #
swatcoder ◴[] No.42164963[source]
For as much as you're right, your taking a very narrow short-term view of productivity.

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.

replies(3): >>42165266 #>>42166551 #>>42171907 #
1. whstl ◴[] No.42166551{3}[source]
> The maintenance demands for using a heavy, evolving framework and a large graph of churning dependencies are tremendous and perpetual

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.