←back to thread

XSLT – Native, zero-config build system for the Web

(github.com)
392 points _kush | 1 comments | 27 Jun 25 05:00 UTC | HN request time: 0.294s | source
Show context
p0w3n3d ◴[27 Jun 25 07:12 UTC] No.44394429[source]▶
Ok, so it might be a long shot, but I would say that

1. the browsers were inconsistent in 1990-2000 so we started using JS to make them behave the same

2. meanwhile the only thing we needed were good CSS styles which were not yet present and consistent behaviour

3. over the years the browsers started behaving the same (mainly because Highlander rules - there can be only one, but Firefox is also coping well)

4. but we already got used to having frameworks that would make the pages look the same on all browsers. Also the paradigm was switched to have json data rendered

5. at the current technology we could cope with server generated old-school web pages because they would have low footprint, work faster and require less memory.

Why do I say that? Recently we started working on a migration from a legacy system. Looks like 2000s standard page per HTTP request. Every action like add remove etc. requires a http refresh. However it works much faster than our react system. Because:

1. Nowadays the internet is much faster

2. Phones have a lot of memory which is wasted by js frameworks

3. in the backend all's almost same old story - CRUD CRUD and CRUD (+ pagination, + transactions)

replies(4): >>44394607 #>>44394696 #>>44395199 #>>44395273 #
ozim ◴[27 Jun 25 09:30 UTC] No.44395273[source]▶
AJAX and updating DOM wasn't there just to "make things faster" it was implemented there to change paradigm of "web sites" or "web documents" — because web was for displaying documents. Full page reload makes sense if you are working in a document paradigm.

It works well here on HN for example as it is quite simple.

There are a lot of other examples where people most likely should do a simple website instead of using JS framework.

But "we could all go back to full page reloads" is not true, as there really are proper "web applications" out there for which full page reloads would be a terrible UX.

To summarize there are:

"websites", "web documents", "web forms" that mostly could get away with full page reloads

"web applications" that need complex stuff presented and manipulated while full page reload would not be a good solution

replies(2): >>44395947 #>>44396791 #
1. alerighi ◴[27 Jun 25 11:34 UTC] No.44395947[source]▶
Yes, of course for web applications you can't do full page reload (you weren't either back in the days, where web applications existed in form of java applets or flash content).

Let's face it, most uses of JS frameworks are for blogs or things that with full page reload you not even notice: nowadays browsers are advanced and only redraw the screen when finished loading the content, meaning that they would out of the box mostly do what React does (only render DOM elements who are changes), meaning that a page reload with a page that only changes one button at UI level does not result in a flicker or loading of the whole page.

BTW, even React now is suggesting people to run the code server-side if it is possible (it's the default of Next.JS), since it makes the project easier to maintain, debug, test, as well as get better score in SEO from search engines.

I'm still a fan of the "old" MVC models of classical frameworks such as Laravel, Django, Rails, etc. to me make overall projects that are easier to maintain for the fact that all code runs in the backend (except maybe some jQuery animation client side), model is well separated from the view, there is no API to maintain, etc.