4 ms·

You put "improve" in quotes as if instant page navigation without flickering is somehow worse than the alternative. Browse around this [1] website and tell me i

You put "improve" in quotes as if instant page navigation without flickering is somehow worse than the alternative. Browse around this [1] website and tell me it is not a better experience than your bog-standard html + vanilla js concoction. Also every time this is brought up the developer/content editor experience is entirely neglected, when in reality it is a big consideration when creating something other than your own dev-blog that you update once a year. [1] https://reactjs.org https://reactjs.org

TeMPOraL 7y ago
> You put "improve" in quotes as if instant page navigation without flickering is somehow worse than the alternative. Yes, instant page navigation without flickering is better than the alternative - instant being what you get from reloading a static HTML page, alternative being React. Seriously, fetching, parsing and displaying a tiny bit of HTML is fast. As fast or faster than the React virtual DOM shenanigans, once you account for the computational load the framework adds on top of your simple page.
- Dockson 7y ago
  Real life is not code golf. We do not build things entirely for ourselves. We build things for our employers, for our co-workers, for our family members and for our friends. We build to create value for someone and value is not a one-to-one correlation with the weight of a site in KB. If I can make it easier for me and anyone working with my site in the future by sacrificing 50-150 KB then I will take that deal any day of the week. That is what abstractions are for. That is why we do not work in byte-code. We pay for convenience in clock-cycles and disk space.
  - TeMPOraL 7y ago
    Arguably, using React where a static HTML with maybe a little bit of vanilla JS would do, is code golf. HTML and CSS are not bytecode. They're high-level abstractions, hiding a very complex renderer underneath. Sometimes you need to build another tower of abstractions when this doesn't suffice - like when you're trying to build an application with complex GUI in the browser and you need an adapter between DOM and a more suitable GUI pattern. But displaying text and images communicating a message is not one of those cases.
    - Dockson 7y ago
      We do not rebuild the tower of abstractions for every site that uses them. I do not personally implement React from scratch when I use it for any of my sites. I get all of the benefits for none of the effort. You do not seem to acknowledge factors other than straight up performance, as is evident by what you are picking and choosing from my comments, so obviously it is not attractive to you.
antisemiotic 7y ago
It seems to work fine under umatrix set to "kill everything but first-party images and css".
- Dockson 7y ago
  Perfect! So we can have the DX of React with no downside for you. Win-win, right?
  - antisemiotic 7y ago
    Wouldn't it be easier to just use a static site generator for a simple site like this, though?
    - Dockson 7y ago
      It is built on a static site generator based on React, it's called GatsbyJS.
      - antisemiotic 7y ago
        Sorry then, I guess I have no idea what this discussion was about in the first place. Why would anyone care about the build tools of someone else's site if it doesn't affect the user?
        Dockson 7y ago
        They shouldn't, but they do.
csande17 7y ago
I tried the site you linked on my phone. It is not a better experience than a standard HTML site: 1. The Back button had a noticable half-second lag. 2. When I temporarily lost connection and a link I clicked was taking a long time to load, I wasn't given the option to stop loading it like I am when I click a normal link. I tried disabling JavaScript like a sibling comment suggested, and the website was indeed faster and still flicker-free. (Where do front-end devs get this idea that you need tons of JavaScript to do flicker-free page navigation? Have they never used Hacker News?) But then I wasn't able to see the interactive code examples on the homepage, because those genuinely needed JS to work. This is because disabling JavaScript is an all-or-nothing proposition. There's no "throw out bathwater but not baby" button or "allow JavaScript only for things it should actually be used for, and not clumsily reimplementing browser features while forgetting half the edge-cases" toggle-switch.

TeMPOraL 7y ago

> You put "improve" in quotes as if instant page navigation without flickering is somehow worse than the alternative. Yes, instant page navigation without flickering is better than the alternative - instant being what you get from reloading a static HTML page, alternative being React. Seriously, fetching, parsing and displaying a tiny bit of HTML is fast. As fast or faster than the React virtual DOM shenanigans, once you account for the computational load the framework adds on top of your simple page.

Dockson 7y ago
Real life is not code golf. We do not build things entirely for ourselves. We build things for our employers, for our co-workers, for our family members and for our friends. We build to create value for someone and value is not a one-to-one correlation with the weight of a site in KB. If I can make it easier for me and anyone working with my site in the future by sacrificing 50-150 KB then I will take that deal any day of the week. That is what abstractions are for. That is why we do not work in byte-code. We pay for convenience in clock-cycles and disk space.
- TeMPOraL 7y ago
  Arguably, using React where a static HTML with maybe a little bit of vanilla JS would do, is code golf. HTML and CSS are not bytecode. They're high-level abstractions, hiding a very complex renderer underneath. Sometimes you need to build another tower of abstractions when this doesn't suffice - like when you're trying to build an application with complex GUI in the browser and you need an adapter between DOM and a more suitable GUI pattern. But displaying text and images communicating a message is not one of those cases.
  - Dockson 7y ago
    We do not rebuild the tower of abstractions for every site that uses them. I do not personally implement React from scratch when I use it for any of my sites. I get all of the benefits for none of the effort. You do not seem to acknowledge factors other than straight up performance, as is evident by what you are picking and choosing from my comments, so obviously it is not attractive to you.

antisemiotic 7y ago

It seems to work fine under umatrix set to "kill everything but first-party images and css".

Dockson 7y ago
Perfect! So we can have the DX of React with no downside for you. Win-win, right?
- antisemiotic 7y ago
  Wouldn't it be easier to just use a static site generator for a simple site like this, though?
  - Dockson 7y ago
    It is built on a static site generator based on React, it's called GatsbyJS.
    - antisemiotic 7y ago
      Sorry then, I guess I have no idea what this discussion was about in the first place. Why would anyone care about the build tools of someone else's site if it doesn't affect the user?
      - Dockson 7y ago
        They shouldn't, but they do.

csande17 7y ago

I tried the site you linked on my phone. It is not a better experience than a standard HTML site: 1. The Back button had a noticable half-second lag. 2. When I temporarily lost connection and a link I clicked was taking a long time to load, I wasn't given the option to stop loading it like I am when I click a normal link. I tried disabling JavaScript like a sibling comment suggested, and the website was indeed faster and still flicker-free. (Where do front-end devs get this idea that you need tons of JavaScript to do flicker-free page navigation? Have they never used Hacker News?) But then I wasn't able to see the interactive code examples on the homepage, because those genuinely needed JS to work. This is because disabling JavaScript is an all-or-nothing proposition. There's no "throw out bathwater but not baby" button or "allow JavaScript only for things it should actually be used for, and not clumsily reimplementing browser features while forgetting half the edge-cases" toggle-switch.