4 ms·

A company I know has been replacing some pre-Cambrian "Individual PHP-built HTML pages with the occasional JavaScript enhancement" pages with a React-based app.

by hakfoo 7y ago

A company I know has been replacing some pre-Cambrian "Individual PHP-built HTML pages with the occasional JavaScript enhancement" pages with a React-based app. There is a case for updating the site-- it predates responsive design and several corporate rebrandings-- but I'm not sure new-era web tech is actually doing them any good. It moved a lot of complexities from the server side to the client side-- management of state and orchestration of data, turning a single request for a finished page into a whole streak of API hits to populate out a template. They went for an API-based approach with the thought they could expose it directly for external power users, but the API ends up not even serving their INTERNAL needs well (the information you want for this report is scattered across 12 different tables, but combining them together violates the REST spirit) I'm not sure it will be faster or more stable than the old code even once they finish optimization. The only user-facing benefit appears to be that they replaced the 200-millisecond flash of white as it loads each page with a 5-second spinning beachball in the template as it collects the data a piece at a time. I strongly suspect a lot of the motivation was the devs wanting to put some trendier technologies on their resumes.

folkhack 7y ago
Thanks for taking the time to share this - because it's exactly what I feel is happening to webdev as a whole. We're adding unnecessary complexity trying to put everything on the user's browser vs. rendering a sane and functional blob of HTML that just gets the job done + sprinkling in the JS when needed for more interactive needs! > I'm not sure it will be faster or more stable than the old code even once they finish optimization. The only user-facing benefit appears to be that they replaced the 200-millisecond flash of white as it loads each page with a 5-second spinning beachball in the template as it collects the data a piece at a time. If it's a ton of individual web requests there's very little chance that it will optimize anything because it sounds like a lot of HTTP overhead. I've seen this same anti-pattern 1000 times in my career and frankly would rather take the processing onto a very fast webserver that's optimized to crank through stuff like that with some SQL/joins/etc. (ie: doing a few joins on the server side vs. and sending a "view" of the data is WAY more appropriate than putting the responsibility of lots of web requests on your client and increasing your HTTP overhead)... > I strongly suspect a lot of the motivation was the devs wanting to put some trendier technologies on their resumes. Yep - and often if that's the case they end up creating a mess of an application that has all sorts of crazy constraints that never needed to be introduced. --- That being said, new-era anything can be good. Heck - I needed to do the "shotgun a whole bunch of HTTP requests" approach for a GIS mapping solution that would load chunks of data in at a time based on the map's viewport. It just needs to be justified, and most of the time I feel like people just wanna do what they're comfortable with vs. what's a best-fit for the problem.
charrondev 7y ago
Too be honest that’s just poor development practice. We run a React SPA, and our backend for initial page load & API is in PHP. Frontend devs work with backend devs to ensure the critical path of the page can we gathered in 1 request. This usually means having some expand query params on the get request. We also preload critical API responses in the initial page load to prevent this initial loading indicator.
- folkhack 7y ago
  ^^ Also agree on this. I have seen the whole "it has to be RESTful" thing that the parent comment was discussing as a way to justify huge amounts of HTTP overhead too many times however.
manigandham 7y ago
Turning every site into a major SPA is the single biggest problem with webdev today. They should only be used for truly complex webapps that need real-time updates and interactivity. Otherwise, like you said, it's just rebuilding everything that a capable server-side framework gives you to then run it in the browser with worse UX. I've consistently proven to my team that a server-rendered page with some optional JS on top (Vue is great for this) is 1000x better for users than a giant JS payload just to make API calls and render some HTML.

by hakfoo 7y ago

folkhack 7y ago

Thanks for taking the time to share this - because it's exactly what I feel is happening to webdev as a whole. We're adding unnecessary complexity trying to put everything on the user's browser vs. rendering a sane and functional blob of HTML that just gets the job done + sprinkling in the JS when needed for more interactive needs! > I'm not sure it will be faster or more stable than the old code even once they finish optimization. The only user-facing benefit appears to be that they replaced the 200-millisecond flash of white as it loads each page with a 5-second spinning beachball in the template as it collects the data a piece at a time. If it's a ton of individual web requests there's very little chance that it will optimize anything because it sounds like a lot of HTTP overhead. I've seen this same anti-pattern 1000 times in my career and frankly would rather take the processing onto a very fast webserver that's optimized to crank through stuff like that with some SQL/joins/etc. (ie: doing a few joins on the server side vs. and sending a "view" of the data is WAY more appropriate than putting the responsibility of lots of web requests on your client and increasing your HTTP overhead)... > I strongly suspect a lot of the motivation was the devs wanting to put some trendier technologies on their resumes. Yep - and often if that's the case they end up creating a mess of an application that has all sorts of crazy constraints that never needed to be introduced. --- That being said, new-era anything can be good. Heck - I needed to do the "shotgun a whole bunch of HTTP requests" approach for a GIS mapping solution that would load chunks of data in at a time based on the map's viewport. It just needs to be justified, and most of the time I feel like people just wanna do what they're comfortable with vs. what's a best-fit for the problem.

charrondev 7y ago

Too be honest that’s just poor development practice. We run a React SPA, and our backend for initial page load & API is in PHP. Frontend devs work with backend devs to ensure the critical path of the page can we gathered in 1 request. This usually means having some expand query params on the get request. We also preload critical API responses in the initial page load to prevent this initial loading indicator.

folkhack 7y ago
^^ Also agree on this. I have seen the whole "it has to be RESTful" thing that the parent comment was discussing as a way to justify huge amounts of HTTP overhead too many times however.

manigandham 7y ago

Turning every site into a major SPA is the single biggest problem with webdev today. They should only be used for truly complex webapps that need real-time updates and interactivity. Otherwise, like you said, it's just rebuilding everything that a capable server-side framework gives you to then run it in the browser with worse UX. I've consistently proven to my team that a server-rendered page with some optional JS on top (Vue is great for this) is 1000x better for users than a giant JS payload just to make API calls and render some HTML.