←back to thread

392 points _kush | 3 comments | | HN request time: 0.001s | source
Show context
p0w3n3d ◴[] 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 ◴[] 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 ◴[] 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. Cthulhu_ ◴[] No.44395232[source]
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.

replies(1): >>44395318 #
2. arkh ◴[] No.44395318[source]
> 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.

replies(1): >>44395830 #
3. JimDabell ◴[] No.44395830[source]
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.