5 ms·

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. mea

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)

em-bee 1y ago
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. unless you have a high latency internet connection: https://news.ycombinator.com/item?id=44326816 https://news.ycombinator.com/item?id=44326816
- p0w3n3d 1y ago
  however when you have a high latency connection, the "thick client" json-filled webapp will only have its advantages if the most of the business logic happens on the browser. I.e. Google Docs - great and much better than it used to be in 2000s design style. Application that searches the apartments to rent? Not really I would say. -- edit -- by the way in 2005 I programmed using very funny PHP framework PRADO that was sending every change in the UI to the server. Boy it was slow and server heavy. This was the direction we should have never gone...
  - em-bee 1y ago
    Application that searches the apartments to rent? Not really I would say. not a good example. i can't find it now, but there was a story/comment about a realtor app that people used to sell houses. often when they were out with a potential buyer they had bad internet access and loading new data and pictures for houses was a pain. it wasn't until they switched to using a frontend framework to preload everything with the occasional updates that the app became usable. low latency affects any interaction with a site. even hackernews is a pain to read over low latency and would improve if new comments where loaded in the background. the problem creeps up on you faster than you think.
    - _heimdall 1y ago
      Prefetching pages doesn't require a frontend framework though. All it takes is a simple script to preload all or specific anchor links on the page, or you could get fancier with a service worker and a site manifest if you want to preload pages that may not be linked on the current page.
      - chriswarbo 1y ago
        It shouldn't need any scripts https://en.wikipedia.org/wiki/Link_prefetching https://en.wikipedia.org/wiki/Link_prefetching It can also be imposed by the client, e.g. via a https://en.wikipedia.org/wiki/Web_accelerator https://en.wikipedia.org/wiki/Web_accelerator
        _heimdall 1y ago
        Yep, that works as well. I'll reach for a script still if I want more logic around when to prefetch, like only prefetching on link hover or focus. A script is also needed for any links that you need to preload but aren't included on the current page.
  - catmanjan 1y ago
    Lol you'd hate to see what blazor is doing then
viraptor 1y ago
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.
- jonwinstanley 1y 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?
  - jbverschoor 1y ago
    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
    - JimDabell 1y ago
      > 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.
bob1029 1y ago
> 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 I've got a .NET/Kestrel/SQLite stack that can crank out SSR responses in no more than ~4 milliseconds. Average response time is measured in hundreds of microseconds when running release builds. This is with multiple queries per page, many using complex joins to compose view-specific response shapes. Getting the data in the right shape before interpolating HTML strings can really help with performance in some of those edges like building a table with 100k rows. LINQ is fast, but approaches like materializing a collection per row can get super expensive as the # of items grows. The closer together you can get the HTML templating engine and the database, the better things will go in my experience. At the end of the day, all of that fancy structured DOM is just a stream of bytes that needs to be fed to the client. Worrying about elaborate AST/parser approaches when you could just use StringBuilder and clever SQL queries has created an entire pointless, self-serving industry. The only arguments I've ever heard against using something approximating this boil down to arrogant security hall monitors who think developers cant be trusted to use the HTML escape function properly.
- chriswarbo 1y ago
  > arrogant security hall monitors who think developers cant be trusted to use the HTML escape function properly. Unfortunately, they're not actually wrong though :-( Still, there are ways to enforce escaping (like preventing "stringly typed" programming) which work perfectly well with streams of bytes, and don't impose any runtime overhead (e.g. equivalent to Haskell's `newtype`)
ozim 1y ago
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
- alerighi 1y ago
  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.
- alganet 1y ago
  > full page reloads grug remember ancestor used frames then UX shaman said frame bad all sour faced frame ugly they said, multiple scrollbar bad then 20 years later people use fancy js to emulate frames grug remember ancestor was right https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/frameset https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

em-bee 1y ago

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. unless you have a high latency internet connection: https://news.ycombinator.com/item?id=44326816 https://news.ycombinator.com/item?id=44326816

p0w3n3d 1y ago
however when you have a high latency connection, the "thick client" json-filled webapp will only have its advantages if the most of the business logic happens on the browser. I.e. Google Docs - great and much better than it used to be in 2000s design style. Application that searches the apartments to rent? Not really I would say. -- edit -- by the way in 2005 I programmed using very funny PHP framework PRADO that was sending every change in the UI to the server. Boy it was slow and server heavy. This was the direction we should have never gone...
- em-bee 1y ago
  Application that searches the apartments to rent? Not really I would say. not a good example. i can't find it now, but there was a story/comment about a realtor app that people used to sell houses. often when they were out with a potential buyer they had bad internet access and loading new data and pictures for houses was a pain. it wasn't until they switched to using a frontend framework to preload everything with the occasional updates that the app became usable. low latency affects any interaction with a site. even hackernews is a pain to read over low latency and would improve if new comments where loaded in the background. the problem creeps up on you faster than you think.
  - _heimdall 1y ago
    Prefetching pages doesn't require a frontend framework though. All it takes is a simple script to preload all or specific anchor links on the page, or you could get fancier with a service worker and a site manifest if you want to preload pages that may not be linked on the current page.
    - chriswarbo 1y ago
      It shouldn't need any scripts https://en.wikipedia.org/wiki/Link_prefetching https://en.wikipedia.org/wiki/Link_prefetching It can also be imposed by the client, e.g. via a https://en.wikipedia.org/wiki/Web_accelerator https://en.wikipedia.org/wiki/Web_accelerator
      - _heimdall 1y ago
        Yep, that works as well. I'll reach for a script still if I want more logic around when to prefetch, like only prefetching on link hover or focus. A script is also needed for any links that you need to preload but aren't included on the current page.
- catmanjan 1y ago
  Lol you'd hate to see what blazor is doing then

viraptor 1y ago

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.

jonwinstanley 1y 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?
- jbverschoor 1y ago
  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
  - JimDabell 1y ago
    > 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.

bob1029 1y ago

> 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 I've got a .NET/Kestrel/SQLite stack that can crank out SSR responses in no more than ~4 milliseconds. Average response time is measured in hundreds of microseconds when running release builds. This is with multiple queries per page, many using complex joins to compose view-specific response shapes. Getting the data in the right shape before interpolating HTML strings can really help with performance in some of those edges like building a table with 100k rows. LINQ is fast, but approaches like materializing a collection per row can get super expensive as the # of items grows. The closer together you can get the HTML templating engine and the database, the better things will go in my experience. At the end of the day, all of that fancy structured DOM is just a stream of bytes that needs to be fed to the client. Worrying about elaborate AST/parser approaches when you could just use StringBuilder and clever SQL queries has created an entire pointless, self-serving industry. The only arguments I've ever heard against using something approximating this boil down to arrogant security hall monitors who think developers cant be trusted to use the HTML escape function properly.

chriswarbo 1y ago
> arrogant security hall monitors who think developers cant be trusted to use the HTML escape function properly. Unfortunately, they're not actually wrong though :-( Still, there are ways to enforce escaping (like preventing "stringly typed" programming) which work perfectly well with streams of bytes, and don't impose any runtime overhead (e.g. equivalent to Haskell's `newtype`)

ozim 1y ago

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

alerighi 1y ago
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.
alganet 1y ago
> full page reloads grug remember ancestor used frames then UX shaman said frame bad all sour faced frame ugly they said, multiple scrollbar bad then 20 years later people use fancy js to emulate frames grug remember ancestor was right https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/frameset https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...