←back to thread

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

(github.com)
392 points _kush | 2 comments | 27 Jun 25 05:00 UTC | HN request time: 0s | 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 #
viraptor ◴[27 Jun 25 07:53 UTC] No.44394696[source]▶
That timeline doesn't sound right to me. JS was rarely used to standardise behaviour - we had lots of user agent detection and relying on quirks ordering to force the right layout. JS really was for the interactivity at the beginning - DHTML and later AJAX. I don't think it even had easy access to layout related things? (I may be mistaken though) CSS didn't really make things more consistent either - once it became capable it was still a mess. Sure, CSS garden was great and everyone was so impressed with semantic markup while coding tables everywhere. It took ages for anything to actually pass first two ACIDs. I'm not sure frameworks ever really impacted the "consistent looks" side of things - by the time we grew out of jQuery, CSS was the looks thing.

Then again, it was a long time. Maybe it's me misremembering.

replies(2): >>44394769 #>>44395233 #
jonwinstanley ◴[27 Jun 25 08:03 UTC] No.44394769[source]▶
For me, JQuery was the thing that fixed the browser inconsistencies. If you used JQuery for everything, your code worked in all the browsers.

This was maybe 2008?

replies(5): >>44394819 #>>44394973 #>>44394982 #>>44395232 #>>44395621 #
1. benediktwerner ◴[27 Jun 25 08:36 UTC] No.44394982[source]▶
Wasn't it more about inconsistencies in JS though? For stuff which didn't need JS at all, there also shouldn't be much need for JQuery.
replies(1): >>44395297 #
2. dspillett ◴[27 Jun 25 09:35 UTC] No.44395297[source]▶
jQuery, along with a number of similar attempts and more single-item-focused polyfills¹ was as much about DOM inconsistencies as JS ones. It was also about making dealing with the DOM more convenient² even where it was already consistent between commonly used browsers.

DOM manipulation of that sort is JS dependent, of course, but I think considering language features and the environment, like the DOM, to be separate-but-related concerns is valid. There were less kitchen-sink-y libraries that only concentrated on language features or specific DOM features. Some may even consider a few parts in a third section: the standard library, though that feature set might be rather small (not much more than the XMLHTTPRequest replacement/wrappers?) to consider its own thing.

> For stuff which didn't need JS at all, there also shouldn't be much need for JQuery.

That much is mostly true, as it by default didn't do anything to change non-scripted pages. Some polyfills for static HTML (for features that were inconsistent, or missing entirely in, usually, old-IE) were implemented as jQuery plugins though.

--------

[1] Though I don't think they were called that back then, the term coming later IIRC.

[2] Method chaining³, better built-in searching and filtering functions⁴, and so forth.

[3] This divides opinions a bit though was generally popular, some other libraries did the same, others tried different approaches.

[4] Which we ended up coding repeatedly in slightly different ways when needed otherwise.