5 ms·

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

by 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/...
- kbolino 1y ago
  Classic frames were quite bad. Every frame on a page was a separate, independent, coequal instance of the browser engine. This is almost never what you actually want. The header/footer/sidebar frames are subordinate and should not navigate freely. Bookmarks should return me to the frameset state as I left it, not the default for that URL. History should contain the frameset state I saw, not separate entries for each individual frame. Even with these problems, classic frames might have been salvageable, but nobody bothered to fix them.
  - bmacho 1y ago
    > Every frame on a page was a separate, independent, coequal instance of the browser engine. This is almost never what you actually want. Most frames are used for menu, navigation, frame for data, frame for additional information of data. And they are great for that. I don't think that frames are different instances of the browser engine(?) but that doesn't matter the slightest(?). They are fast and lightweight. > The header/footer/sidebar frames are subordinate and should not navigate freely. They have the ability to navigate freely but obviously they don't do that, they navigate different frames.
    - kbolino 1y ago
      With a frameset page: History doesn't work right Bookmarks don't work right -- this applies to link sharing and incoming links too Back button doesn't work right The concept is good. The implementation is bad.
      - bmacho 1y ago
        Yup, they are not enough for an SPA, not without javascript. And if you have javascript to handle history, URL, bookmarks and all that, you can just use divs without frames.
        kbolino 1y ago
        This has nothing to do with SPAs. Take the POSIX specs linked in a sibling comment. Or take the classic Javadocs. I am currently looking at the docs for java.util.ArrayList. Here's a link to it from my browser's URL bar: https://docs.oracle.com/javase/8/docs/api/ https://docs.oracle.com/javase/8/docs/api/ But you didn't go to the docs for java.util.ArrayList, you went to the starting page. Ok, fine, I'll link you directly to the ArrayList docs, for which I had to "view frame source" and grab the URL: https://docs.oracle.com/javase/8/docs/api/java/util/ArrayList.html https://docs.oracle.com/javase/8/docs/api/java/util/ArrayLis... Ok, but now you don't see any of the other frames, do you? And I had one of those frames pointing at the java.util class. So none of these links show you what I saw. And if I look in my history, there is no entry that corresponds to what I actually saw. There are separate entries for each frame, but none of them load the frameset page with the correct state. These are strongly hyperlinked reference documents. Classic use of HTML. No JavaScript or even CSS needed.

by ozim 1y ago

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

kbolino 1y ago
Classic frames were quite bad. Every frame on a page was a separate, independent, coequal instance of the browser engine. This is almost never what you actually want. The header/footer/sidebar frames are subordinate and should not navigate freely. Bookmarks should return me to the frameset state as I left it, not the default for that URL. History should contain the frameset state I saw, not separate entries for each individual frame. Even with these problems, classic frames might have been salvageable, but nobody bothered to fix them.
- bmacho 1y ago
  > Every frame on a page was a separate, independent, coequal instance of the browser engine. This is almost never what you actually want. Most frames are used for menu, navigation, frame for data, frame for additional information of data. And they are great for that. I don't think that frames are different instances of the browser engine(?) but that doesn't matter the slightest(?). They are fast and lightweight. > The header/footer/sidebar frames are subordinate and should not navigate freely. They have the ability to navigate freely but obviously they don't do that, they navigate different frames.
  - kbolino 1y ago
    With a frameset page: History doesn't work right Bookmarks don't work right -- this applies to link sharing and incoming links too Back button doesn't work right The concept is good. The implementation is bad.
    - bmacho 1y ago
      Yup, they are not enough for an SPA, not without javascript. And if you have javascript to handle history, URL, bookmarks and all that, you can just use divs without frames.
      - kbolino 1y ago
        This has nothing to do with SPAs. Take the POSIX specs linked in a sibling comment. Or take the classic Javadocs. I am currently looking at the docs for java.util.ArrayList. Here's a link to it from my browser's URL bar: https://docs.oracle.com/javase/8/docs/api/ https://docs.oracle.com/javase/8/docs/api/ But you didn't go to the docs for java.util.ArrayList, you went to the starting page. Ok, fine, I'll link you directly to the ArrayList docs, for which I had to "view frame source" and grab the URL: https://docs.oracle.com/javase/8/docs/api/java/util/ArrayList.html https://docs.oracle.com/javase/8/docs/api/java/util/ArrayLis... Ok, but now you don't see any of the other frames, do you? And I had one of those frames pointing at the java.util class. So none of these links show you what I saw. And if I look in my history, there is no entry that corresponds to what I actually saw. There are separate entries for each frame, but none of them load the frameset page with the correct state. These are strongly hyperlinked reference documents. Classic use of HTML. No JavaScript or even CSS needed.