8 ms·

Second-Guessing the Modern Web (2020)

44 points by cdme 3y ago

GMoromisato 3y ago
I'm pushing GridWhale, which is a completely server-side platform, but the trick is that we remote the UI to the browser (think X-terminal but at the granularity of UI controls). The nice thing about this is that your program doesn't have to worry about the front-end/back-end split. You just write as if you had full control over the machine, and the platform takes care of remoting to the browser. Here's the reference manual for it: https://gridwhale.com/program.hexm?id=GCJ5TL7Z&file=GCJ5TL7Z_057MJVDS054052G051TJD050EENY056C.dat https://gridwhale.com/program.hexm?id=GCJ5TL7Z&file=GCJ5TL7Z... [Be gentle--this is implemented as a GridWhale program and everything is still a prototype.] And here's a post I wrote on the motivation: https://medium.com/@gridwhale/rise-of-the-hyperplatforms-d4a148e608de https://medium.com/@gridwhale/rise-of-the-hyperplatforms-d4a... EDIT: 15 minutes after this post, I've already had 20 clicks, and each click spawns a new server-side program. And it's just running on a little 4-core Xeon PC under my desk. I'll post again when it all falls over! EDIT2: Not as bad as I feared/secretly hoped. After an hour there are about 100 program instances, but obviously most are idle, so they don't take up too many resources. The compute process is only using 32 MB of working memory, so we have plenty of room for more. My guess is we could easily hit 1,000 program instances. Of course, this kind of traffic is trivial for a standard web server--we're talking something like 50 requests per minute. But you gotta start somewhere! EDIT3: Spoke too soon! Finally crashed. Although not from traffic but from a bug, so now I have something to debug.
- ReactiveJelly 3y ago
  > Era 2:62. Hm. Custom SemVer, custom language, custom GUI framework? It's a lot.
  - GMoromisato 3y ago
    Dude, I'm a software engineer. I like writing software.
    - TylerE 3y ago
      I think what he's trying to say, is that's a lot easier to convince someone that one thing is a good idea, rather than about 7 untested, unknown things all at the same time. Conventions are, well, conventional for a reason.
      - GMoromisato 3y ago
        Absolutely true! And that's one of the 1,000 reasons why GridWhale might fail. There are already lots of people working to simplify web development by fixing one thing at a time. But what if we could start from scratch and build an integrated platform in which all the pieces work together? Would that be better than piecemeal evolution? Take something like https://Bubble.io https://Bubble.io. That's an integrated system which has its own custom semantics for UI, storage, etc. But people build apps on it because it's really easy to build apps. My premise is that there are some people who are looking for an integrated development experience (like Delphi or like Visual Basic) who are not satisfied with either current complex tools or the more limited nocode systems like Bubble.io. Will there be enough of them to build a business? We'll see.
- zdragnar 3y ago
  Why is every clickable element implemented as a div? You lose out on a lot of native things, like changing mouse cursor on hover, keyboard navigation for users with special accessibility needs, etc.
  - GMoromisato 3y ago
    Good point! Yes, for lots of things I need to use <a> instead. Again, though, I want that to be handled by the platform, as much as possible, so that devs don’t have to.
    - robertoandred 3y ago
      <a> or <button>, depending on the function
      - GMoromisato 3y ago
        Agreed. And obviously we'd implement all the ARIA stuff.
notJim 3y ago
I think a big reason that old-school server-side rendering (i.e., templates) isn't popular anymore is that templating languages are horrible and stuck in 2005. An underrated pro of react [1] + typescript is that you get to write your UI logic in regular typescript, and you get real function signatures for all your UI components. This makes it way easier to write reusable components, because you can specify the arguments, and write regular unit tests against them, etc. With most templating languages, there is no defined function signature (with arguments and types specified), so you get to read through the template to figure out what data to pass in. This makes it very hard to make things reusable. And similarly, templating languages are often some bizarre, janky custom language with pipes and stuff. At a previous employer, we actually solved this problem. We implemented a pattern that gave us real typed interfaces for UI components rendered with templates on the server. We were doing this the same year that React came out, and clearly had some of the same thoughts as Dan Abramov did, although not in the browser. I recently started a side-project in javascript for the first time in years, and was surprised to discover that there is apparently no modern open-source library for rendering server side components, other than rendering react on the server of course. Your options are basically react or using some shitty templating language. I went with react. 1: When I say react, please understand it to mean any of the nice modern frontend libraries, like react, vue (is this still a thing?), svelte, etc.
- simonw 3y ago
  I find the popularity of JSX-style templating really surprising. <div> <h1>Conditional Display and Looping in JSX</h1> <ul> {this.state.items.map(item => ( item.show ? <li key={item.id}>{item.name}</li> : null ))} </ul> </div> That seems like such an unintuitive way of implementing loops and if statements! I helped design the Django template language, where the above would look like this instead: <div> <h1>Conditional Display and Looping in Django Template</h1> <ul> {% for item in items %} {% if item.show %} <li>{{ item.name }}</li> {% endif %} {% endfor %} </ul> </div> I do like the type signature aspect of it that you're talking about - I've found myself wanting that for Django templates in the past, to the point that I've started figuring out patterns for populating templates using typed Python dataclasses as opposed to anything-goes-dictionaries.
tabtab 3y ago
HTML and DOM lack too many common and expected GUI idioms (see link). If our standards had those, then we wouldn't need to use clunky stuff like React to emulate them. We need a state-ful GUI markup language standard. https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_or_defective_gui_idioms_in_htmldom/ https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_...
- SrslyJosh 3y ago
  To be honest, a lot of that is stuff that I'm happier to not see on a webpage.
- jwells89 3y ago
  The hoops that need to be jumped to get a web version of a simple tableview/datagrid with sortable rearrangeable resizable columns and recycled rows like desktop UI toolkits have had since the dawn of time are a bit nuts.
- eschaton 3y ago
  HTML and DOM lack those because that’s not what they’re for. Stop trying to build desktop and mobile applications using a document markup language. If you’re building a client-side application, use the platforms’ native languages and technologies. It should be possible to port a modern browser engine to an average new PC from 1995 and use almost the entire web, over 33.6K dialup, with good performance—modulo high-res/quality images, audio, and video. That we’ve allowed the web to get away from this says way more about web development than technology.
  - jakelazaroff 3y ago
    > HTML and DOM lack those because that’s not what they’re for. Stop trying to build desktop and mobile applications using a document markup language. If you’re building a client-side application, use the platforms’ native languages and technologies. People love to say this here but I've never seen a good reason for it. Web technologies are far and away the best I've used for creating user interfaces. And there are significant advantages to building on the web. How else can someone jump into collaborating on a document or a picture with me — without installing anything — after receiving only a short text?
jakelazaroff 3y ago
Flagging because Tom has expressed that he doesn’t want Hacker News to link to his articles.
- GMoromisato 3y ago
  I'm curious: Why? Too much traffic? Does he have a beef with HN?
  - jakelazaroff 3y ago
    HN comments can be very negative, and he found himself adding a bunch of caveats and qualifiers to his writing to appease the critics, which he feels makes his writing worse.
    - GMoromisato 3y ago
      Yeah, that makes sense. Thank you! I'll just say that from my perspective, the only thing worse than having critics is not having critics.
      - jakelazaroff 3y ago
        Yeah, I personally feel lucky when an article of mine hits the front page (although maybe there's an inflection point of popularity at which the reverse is true). But regardless, we should respect his wishes.
s17n 3y ago
"Moderately interactive interfaces" describes most web applications - stuff like gmail, airbnb, facebook, youtube, reddit, etc. Even for things like Mapbox or Observable that require a high performance core, React is the best choice for building the surrounding chrome. Whether HTML/CSS/DOM was a good technology to use for building these types of applications is another question but we're stuck with it now either way.
- ducharmdev 3y ago
  Sometimes I wonder how many criticisms of JavaScript frameworks are driven by a nostalgia for an internet that no longer exists. Not this post per se, but many seem to forget why the industry landed on React in the first place.
  - timw4mail 3y ago
    Featuritis...the drive to add "features" because other sites do.
yawaramin 3y ago
(2020) Folks, this is exactly what htmx (and Phoenix LiveView and Laravel Livewire and Rails Hotwire) solves. OP was almost there but couldn't quite articulate this niche. Which is OK, we have the benefit of hindsight now. Try htmx. It will blow you away with its simplicity compared to (today's) React. My personal recommendation: try it with dream-html, a library I wrote for expressing HTML directly in the language: https://github.com/yawaramin/dream-html https://github.com/yawaramin/dream-html (or some similar library).
deleted 3y ago
[deleted]
jongjong 3y ago
With tech trends, over the past 15 years, I was always on the ball 100% of the time until React came along. I started coding Flash/ActionScript games around 2004 (which is based on ECMAScript spec just like JavaScript) and I was using ActionScript 3 with types which was very similar to TypeScript but was better (it was simpler with less room for unnecessary type gymnastics). I was a web developer before the term was broadly used, I was a front end developer before the term was broadly used, I was also a full stack dev before it was trendy. I was an early bird JavaScript single page app developer. Early bird Node.js adopter. Early bird NoSQL (e.g. MongoDB) adopter. I was always on the cutting edge, adopting new tech as soon as I heard of it but just before it became super popular. I was 100% on target until React came along and I've since been wrong about most trends and yet I'm becoming convinced that it's the trends that are wrong, not me. I say this because complexity has gone out of control and I can build apps faster and simpler using my own home-baked stack than other devs can with React, GraphQL or other trendy tools. Most of my tools/libraries are open source but they get limited exposure to the broader community (in spite of very positive feedback, I can't get past the chicken and egg problem) so I just use them for myself. If you saw how I write apps (with auth, modeling complex relationships between data, automatic real time update, can scale out of the box with sharding on Kubernetes etc...) with very little code, many devs would be impressed want want to use or build something similar from scratch, yet they may never learn of this tooling or this coding philosophy. These days, new tools simply cannot get the initial boost of users that is required to gain traction. It's like they cannot even enter the playing field; no surprise then that they cannot win the game. You can see how the discourse is completely suppressed; there is only one set of tools on the front end nowadays; React and TypeScript. VueJS and Svelte are struggling if you look at job adverts even though they are at least slightly better technically for most scenarios; it does not translate to jobs. I think the reason why there is a dissonance between getting very positive feedback for certain open source tools and there being limited adoption is because, at the end of the day, developers don't have a say regarding what tools they can use in production at the companies they work for; they are completely limited to well-known existing tools. It follows a more general problem we're facing in society now; there is a belief among elite circles that we've reached some kind of singularity; that everything has been figured out and is in its optimal state so no need to try anything else. "Trust the science"; imagine doctors saying that 100 years ago... It says something about how some people perceive this moment in history; they perceive today unlike any other moment before it; whereas in reality, things are very far from optimal for many reasons and we are still in a transition phase.
jongjong 3y ago
IMO, React's popularity has little to do with productivity in the context of what other tools are available (many of which we never even heard about). It's mostly about network effects. Popularity is the primary reason why companies use React as it suppresses developer salaries by making devs more interchangeable. It creates liquidity in the market for dev talent due to shared familiarity. Had the similar kinds of network effects existed around a different, better framework, all companies would be much more productive. And even then, I would say the benefits of network effects are greatly exaggerated. Also, it's important to note that many developers who are good at putting together functionality in React quickly aren't necessarily good developers in the more general sense (in the long run). This can cause problems later in terms of security, maintainability, performance, hiring (due to complexity of the software itself scaring off prospective hires; familiarity with the stack isn't everything) also there are concerns about operating costs, vendor lock-in and scalability.
jongjong 3y ago
I very much agree about the point about Server Side Rendering. I don't like it. There are some fundamental differences between front end and back end which should never be neglected. Critically, considerations related to authentication and access control but also relevant in terms of performance (e.g. caching and bundling as described in the article SSR is just a bad idea in practice; I've never seen a project make good use of it)...
dang 3y ago
Related: Second-guessing the modern web (2020) - https://news.ycombinator.com/item?id=27308982 https://news.ycombinator.com/item?id=27308982 - May 2021 (296 comments) Second-Guessing the Modern Web - https://news.ycombinator.com/item?id=23136688 https://news.ycombinator.com/item?id=23136688 - May 2020 (453 comments)
EGreg 3y ago
We have started our platform before React, but ran into similar issues. Luckily they are surmountable. Many of them can be solved by inlining the CSS and basic JS into the page when the session cookie is missing. Then install a service worker to cache each inlined file and show them next time they are requested. There are nuances like rewriting URLs in the CSS to be relative to the page, and then replacing them back in the service worker before caching the result. https://community.qbix.com/t/qbix-websites-loading-quickly/232/ https://community.qbix.com/t/qbix-websites-loading-quickly/2... But you don’t need static sites. You can use CDNs to cache your pages and make them effectively static. Use AJAX or ESI / SSI to include stuff that depends on the session cookie.

44 points by cdme 3y ago

I'm pushing GridWhale, which is a completely server-side platform, but the trick is that we remote the UI to the browser (think X-terminal but at the granularity of UI controls). The nice thing about this is that your program doesn't have to worry about the front-end/back-end split. You just write as if you had full control over the machine, and the platform takes care of remoting to the browser. Here's the reference manual for it: https://gridwhale.com/program.hexm?id=GCJ5TL7Z&file=GCJ5TL7Z_057MJVDS054052G051TJD050EENY056C.dat https://gridwhale.com/program.hexm?id=GCJ5TL7Z&file=GCJ5TL7Z... [Be gentle--this is implemented as a GridWhale program and everything is still a prototype.] And here's a post I wrote on the motivation: https://medium.com/@gridwhale/rise-of-the-hyperplatforms-d4a148e608de https://medium.com/@gridwhale/rise-of-the-hyperplatforms-d4a... EDIT: 15 minutes after this post, I've already had 20 clicks, and each click spawns a new server-side program. And it's just running on a little 4-core Xeon PC under my desk. I'll post again when it all falls over! EDIT2: Not as bad as I feared/secretly hoped. After an hour there are about 100 program instances, but obviously most are idle, so they don't take up too many resources. The compute process is only using 32 MB of working memory, so we have plenty of room for more. My guess is we could easily hit 1,000 program instances. Of course, this kind of traffic is trivial for a standard web server--we're talking something like 50 requests per minute. But you gotta start somewhere! EDIT3: Spoke too soon! Finally crashed. Although not from traffic but from a bug, so now I have something to debug.

ReactiveJelly 3y ago
> Era 2:62. Hm. Custom SemVer, custom language, custom GUI framework? It's a lot.
- GMoromisato 3y ago
  Dude, I'm a software engineer. I like writing software.
  - TylerE 3y ago
    I think what he's trying to say, is that's a lot easier to convince someone that one thing is a good idea, rather than about 7 untested, unknown things all at the same time. Conventions are, well, conventional for a reason.
    - GMoromisato 3y ago
      Absolutely true! And that's one of the 1,000 reasons why GridWhale might fail. There are already lots of people working to simplify web development by fixing one thing at a time. But what if we could start from scratch and build an integrated platform in which all the pieces work together? Would that be better than piecemeal evolution? Take something like https://Bubble.io https://Bubble.io. That's an integrated system which has its own custom semantics for UI, storage, etc. But people build apps on it because it's really easy to build apps. My premise is that there are some people who are looking for an integrated development experience (like Delphi or like Visual Basic) who are not satisfied with either current complex tools or the more limited nocode systems like Bubble.io. Will there be enough of them to build a business? We'll see.
zdragnar 3y ago
Why is every clickable element implemented as a div? You lose out on a lot of native things, like changing mouse cursor on hover, keyboard navigation for users with special accessibility needs, etc.
- GMoromisato 3y ago
  Good point! Yes, for lots of things I need to use <a> instead. Again, though, I want that to be handled by the platform, as much as possible, so that devs don’t have to.
  - robertoandred 3y ago
    <a> or <button>, depending on the function
    - GMoromisato 3y ago
      Agreed. And obviously we'd implement all the ARIA stuff.

notJim 3y ago

I think a big reason that old-school server-side rendering (i.e., templates) isn't popular anymore is that templating languages are horrible and stuck in 2005. An underrated pro of react [1] + typescript is that you get to write your UI logic in regular typescript, and you get real function signatures for all your UI components. This makes it way easier to write reusable components, because you can specify the arguments, and write regular unit tests against them, etc. With most templating languages, there is no defined function signature (with arguments and types specified), so you get to read through the template to figure out what data to pass in. This makes it very hard to make things reusable. And similarly, templating languages are often some bizarre, janky custom language with pipes and stuff. At a previous employer, we actually solved this problem. We implemented a pattern that gave us real typed interfaces for UI components rendered with templates on the server. We were doing this the same year that React came out, and clearly had some of the same thoughts as Dan Abramov did, although not in the browser. I recently started a side-project in javascript for the first time in years, and was surprised to discover that there is apparently no modern open-source library for rendering server side components, other than rendering react on the server of course. Your options are basically react or using some shitty templating language. I went with react. 1: When I say react, please understand it to mean any of the nice modern frontend libraries, like react, vue (is this still a thing?), svelte, etc.

simonw 3y ago
I find the popularity of JSX-style templating really surprising. <div> <h1>Conditional Display and Looping in JSX</h1> <ul> {this.state.items.map(item => ( item.show ? <li key={item.id}>{item.name}</li> : null ))} </ul> </div> That seems like such an unintuitive way of implementing loops and if statements! I helped design the Django template language, where the above would look like this instead: <div> <h1>Conditional Display and Looping in Django Template</h1> <ul> {% for item in items %} {% if item.show %} <li>{{ item.name }}</li> {% endif %} {% endfor %} </ul> </div> I do like the type signature aspect of it that you're talking about - I've found myself wanting that for Django templates in the past, to the point that I've started figuring out patterns for populating templates using typed Python dataclasses as opposed to anything-goes-dictionaries.

tabtab 3y ago

HTML and DOM lack too many common and expected GUI idioms (see link). If our standards had those, then we wouldn't need to use clunky stuff like React to emulate them. We need a state-ful GUI markup language standard. https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_or_defective_gui_idioms_in_htmldom/ https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_...

SrslyJosh 3y ago
To be honest, a lot of that is stuff that I'm happier to not see on a webpage.
jwells89 3y ago
The hoops that need to be jumped to get a web version of a simple tableview/datagrid with sortable rearrangeable resizable columns and recycled rows like desktop UI toolkits have had since the dawn of time are a bit nuts.
eschaton 3y ago
HTML and DOM lack those because that’s not what they’re for. Stop trying to build desktop and mobile applications using a document markup language. If you’re building a client-side application, use the platforms’ native languages and technologies. It should be possible to port a modern browser engine to an average new PC from 1995 and use almost the entire web, over 33.6K dialup, with good performance—modulo high-res/quality images, audio, and video. That we’ve allowed the web to get away from this says way more about web development than technology.
- jakelazaroff 3y ago
  > HTML and DOM lack those because that’s not what they’re for. Stop trying to build desktop and mobile applications using a document markup language. If you’re building a client-side application, use the platforms’ native languages and technologies. People love to say this here but I've never seen a good reason for it. Web technologies are far and away the best I've used for creating user interfaces. And there are significant advantages to building on the web. How else can someone jump into collaborating on a document or a picture with me — without installing anything — after receiving only a short text?

jakelazaroff 3y ago

Flagging because Tom has expressed that he doesn’t want Hacker News to link to his articles.

GMoromisato 3y ago
I'm curious: Why? Too much traffic? Does he have a beef with HN?
- jakelazaroff 3y ago
  HN comments can be very negative, and he found himself adding a bunch of caveats and qualifiers to his writing to appease the critics, which he feels makes his writing worse.
  - GMoromisato 3y ago
    Yeah, that makes sense. Thank you! I'll just say that from my perspective, the only thing worse than having critics is not having critics.
    - jakelazaroff 3y ago
      Yeah, I personally feel lucky when an article of mine hits the front page (although maybe there's an inflection point of popularity at which the reverse is true). But regardless, we should respect his wishes.

s17n 3y ago

"Moderately interactive interfaces" describes most web applications - stuff like gmail, airbnb, facebook, youtube, reddit, etc. Even for things like Mapbox or Observable that require a high performance core, React is the best choice for building the surrounding chrome. Whether HTML/CSS/DOM was a good technology to use for building these types of applications is another question but we're stuck with it now either way.

ducharmdev 3y ago
Sometimes I wonder how many criticisms of JavaScript frameworks are driven by a nostalgia for an internet that no longer exists. Not this post per se, but many seem to forget why the industry landed on React in the first place.
- timw4mail 3y ago
  Featuritis...the drive to add "features" because other sites do.

yawaramin 3y ago

(2020) Folks, this is exactly what htmx (and Phoenix LiveView and Laravel Livewire and Rails Hotwire) solves. OP was almost there but couldn't quite articulate this niche. Which is OK, we have the benefit of hindsight now. Try htmx. It will blow you away with its simplicity compared to (today's) React. My personal recommendation: try it with dream-html, a library I wrote for expressing HTML directly in the language: https://github.com/yawaramin/dream-html https://github.com/yawaramin/dream-html (or some similar library).

deleted 3y ago

[deleted]

jongjong 3y ago

With tech trends, over the past 15 years, I was always on the ball 100% of the time until React came along. I started coding Flash/ActionScript games around 2004 (which is based on ECMAScript spec just like JavaScript) and I was using ActionScript 3 with types which was very similar to TypeScript but was better (it was simpler with less room for unnecessary type gymnastics). I was a web developer before the term was broadly used, I was a front end developer before the term was broadly used, I was also a full stack dev before it was trendy. I was an early bird JavaScript single page app developer. Early bird Node.js adopter. Early bird NoSQL (e.g. MongoDB) adopter. I was always on the cutting edge, adopting new tech as soon as I heard of it but just before it became super popular. I was 100% on target until React came along and I've since been wrong about most trends and yet I'm becoming convinced that it's the trends that are wrong, not me. I say this because complexity has gone out of control and I can build apps faster and simpler using my own home-baked stack than other devs can with React, GraphQL or other trendy tools. Most of my tools/libraries are open source but they get limited exposure to the broader community (in spite of very positive feedback, I can't get past the chicken and egg problem) so I just use them for myself. If you saw how I write apps (with auth, modeling complex relationships between data, automatic real time update, can scale out of the box with sharding on Kubernetes etc...) with very little code, many devs would be impressed want want to use or build something similar from scratch, yet they may never learn of this tooling or this coding philosophy. These days, new tools simply cannot get the initial boost of users that is required to gain traction. It's like they cannot even enter the playing field; no surprise then that they cannot win the game. You can see how the discourse is completely suppressed; there is only one set of tools on the front end nowadays; React and TypeScript. VueJS and Svelte are struggling if you look at job adverts even though they are at least slightly better technically for most scenarios; it does not translate to jobs. I think the reason why there is a dissonance between getting very positive feedback for certain open source tools and there being limited adoption is because, at the end of the day, developers don't have a say regarding what tools they can use in production at the companies they work for; they are completely limited to well-known existing tools. It follows a more general problem we're facing in society now; there is a belief among elite circles that we've reached some kind of singularity; that everything has been figured out and is in its optimal state so no need to try anything else. "Trust the science"; imagine doctors saying that 100 years ago... It says something about how some people perceive this moment in history; they perceive today unlike any other moment before it; whereas in reality, things are very far from optimal for many reasons and we are still in a transition phase.

jongjong 3y ago

IMO, React's popularity has little to do with productivity in the context of what other tools are available (many of which we never even heard about). It's mostly about network effects. Popularity is the primary reason why companies use React as it suppresses developer salaries by making devs more interchangeable. It creates liquidity in the market for dev talent due to shared familiarity. Had the similar kinds of network effects existed around a different, better framework, all companies would be much more productive. And even then, I would say the benefits of network effects are greatly exaggerated. Also, it's important to note that many developers who are good at putting together functionality in React quickly aren't necessarily good developers in the more general sense (in the long run). This can cause problems later in terms of security, maintainability, performance, hiring (due to complexity of the software itself scaring off prospective hires; familiarity with the stack isn't everything) also there are concerns about operating costs, vendor lock-in and scalability.

jongjong 3y ago

I very much agree about the point about Server Side Rendering. I don't like it. There are some fundamental differences between front end and back end which should never be neglected. Critically, considerations related to authentication and access control but also relevant in terms of performance (e.g. caching and bundling as described in the article SSR is just a bad idea in practice; I've never seen a project make good use of it)...

dang 3y ago

Related: Second-guessing the modern web (2020) - https://news.ycombinator.com/item?id=27308982 https://news.ycombinator.com/item?id=27308982 - May 2021 (296 comments) Second-Guessing the Modern Web - https://news.ycombinator.com/item?id=23136688 https://news.ycombinator.com/item?id=23136688 - May 2020 (453 comments)

EGreg 3y ago

We have started our platform before React, but ran into similar issues. Luckily they are surmountable. Many of them can be solved by inlining the CSS and basic JS into the page when the session cookie is missing. Then install a service worker to cache each inlined file and show them next time they are requested. There are nuances like rewriting URLs in the CSS to be relative to the page, and then replacing them back in the service worker before caching the result. https://community.qbix.com/t/qbix-websites-loading-quickly/232/ https://community.qbix.com/t/qbix-websites-loading-quickly/2... But you don’t need static sites. You can use CDNs to cache your pages and make them effectively static. Use AJAX or ESI / SSI to include stuff that depends on the session cookie.