Comment by jonwinstanley
10 hours ago
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?
10 hours ago
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?
Before jQuery there was Prototype.js, part of early AJAX support in RoR, which fixed inconsistencies in how browsers could fetch data, especially in the era between IE 5 and 7 (native JS `XMLHttpRequest` was only available from IE 7 onwards, before that it was some ActiveX thing. The other browsers supported it from the get go). My memory is vague, but it also added stuff like selectors, and on top of that was script.aculo.us which added animations and other such fanciness.
jQuery took over very quickly though for all of those.
> native JS `XMLHttpRequest` was only available from IE 7 onwards, before that it was some ActiveX thing.
Almost sure it was available on IE6. But even if not, you could emulate it using hidden iframes to call pages which embedded some javascript interacting with the main page. I still have fond memories of using mootools for lightweight nice animations and less fond ones of dojo.
Internet Explorer 5–6 was the ActiveX control. Then other browsers implemented XMLHTTPRequest based on how that ActiveX control worked, then Internet Explorer 7 implemented it without ActiveX the same way as the other browsers, and then WHATWG standardised it.
Kuro5hin had a dynamic commenting system based on iframes like you describe.
jQuery in ~2008 was when it kinda took off, but jQuery was itself an outgrowth of work done before it on browser compatibility with JavaScript. In particular, events.
Internet Explorer didn’t support DOM events, so addEventListener wasn’t cross-browser compatible. A lot of people put work in to come up with an addEvent that worked consistently cross-browser.
The DOMContentLoaded event didn’t exist, only the load event. The load event wasn’t really suitable for setting up things like event handlers because it would wait until all external resources like images had been loaded too, which was a significant delay during which time the user could be interacting with the page. Getting JavaScript to run consistently after the DOM was available, but without waiting for images was a bit tricky.
These kinds of things were iterated on in a series of blog posts from several different web developers. One blogger would publish one solution, people would find shortcomings with it, then another blogger would publish a version that fixed some things, and so on.
This is an example of the kind of thing that was happening, and you’ll note that it refers to work on this going back to 2001:
https://robertnyman.com/2006/08/30/event-handling-in-javascr...
When jQuery came along, it was really trying to achieve two things: firstly, incorporating things like this to help browser compatibility; and second, to provide a “fluent” API where you could chain API calls together.
I wasn't clear, jQuery was definitely used for browser inconsistencies, but in behaviour, but layout. It had just a small overlap with CSS functionality (at first, until it all got exposed to JS)
Probably 2005.
2002, I was using “JSRS”, and returning http 204/no content, which causes the browser to NOT refresh/load the page.
Just for small interactive things, like a start/pause button for scheduled tasks. The progress bar etc.
But yeah, in my opinion we lost about 15 years of proper progress.
The network is the computer came true
The SUN/JEE model is great.
It’s just that monopolies stifle progress and better standards.
Standards are pretty much dead, and everything is at the application layer.
That said.. I think XSLT sucks, although I haven’t touched it in almost 20 years. The projects I was on, there was this designer/xslt guru. He could do anything with it.
XPath is quite nice though
> But yeah, in my opinion we lost about 15 years of proper progress.
Internet Explorer 6 was released in 2001 and didn’t drop below 3% worldwide until 2015. So that’s a solid 14 years of paralysis in browser compatibility.
Time flies when you’re having fun
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.
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.