9 ms·

I was disappointed to find that this post falls into the same pit a number of these defences of the modern web fall into - creating a false dichotomy between "l

I was disappointed to find that this post falls into the same pit a number of these defences of the modern web fall into - creating a false dichotomy between "literally no JavaScript whatsoever" and "a framework-authored site with client-side routing". None of the features mentioned in that particular paragraph - user interaction analytics, preloading data and content [on link hover], transitions, avoiding full page loads - need a site to be an SPA, nor are they "fiendishly difficult" to do for the [near-]static sites MacWright discusses in his blog post. I think it's a shame that frontend web developers have thrown themselves behind the SPA paradigm so hard that the notion of a JavaScript ecosystem that doesn't try to do pull _everything_ into its own domain is unimaginable. I'd love to see more mindshare go towards building libraries that are drop-in/"just add water" progressive enhancements for static sites. [edit: minor grammar correction]

basch 6y ago
Right? Are you thinking something like ShareDB? https://github.com/share/sharedb https://github.com/share/sharedb As a person who is browsing the web, I do want server rendered pages, correct history of navigation, urls to match pages, a lack of refreshes, live collaboration with other users. What I dont want is a manual refresh to lose anything or bring me to a different page. And I want the site to work, and progressively fail if I have javascript off. Most interactivity can still be server side. Look at google.com, as you type in a search query, and they return a static update with results matching what youve typed so far.
- filleduchaos 6y ago
  > Are you thinking something like ShareDB? https://github.com/share/sharedb https://github.com/share/sharedb Ah - I didn't have anything quite that powerful in mind, more like fairly simple, browser-local enhancements to make interacting with regular old HTML pages more pleasant. For example a drop-in library that would save the state of a form and restore it on a refresh, like the old formsaver jQuery plugin. I would like to see an ecosystem of libraries like that again
trashburger 6y ago
>I'd love to see more mindshare go towards building libraries that are drop-in/"just add water" progressive enhancements for static sites. Sounds like jQuery plugins. Seriously though, I wish for a similar thing without the baggage. Maybe there needs to be a common interface defined for such "just add water" libraries.
- filleduchaos 6y ago
  There was/is so much that was genuinely awesome about jQuery. I still remember fiddling around with my blog as a teenager and being blown away by the DataTables plugin.
  - jbergens 6y ago
    And large jquery apps often had so much spaghetti code that it took years to unravel.
    - filleduchaos 6y ago
      Interestingly enough, neither myself nor MacWright advocated returning to writing large jQuery apps so I truly fail to see how this comment is relevant.
gambler 6y ago
This. I've long ago abandoned spaghetti mega-scripts and SPAs in favor of targeted JS libraries that extend HTML capabilities. They're not web components, they don't require some framework to manage, and my HTML works fine without them, but if I load the library and add certain attributes or tags to my markup, I get extra capabilities. The libraries don't require crazy tooling to manage, don't have extensive dependencies and so they facilitate steady incremental development. I'm very happy with this approach and I'm reusing code I've written years ago for completely different projects.
- zeugmasyllepsis 6y ago
  > .. in favor of targeted JS libraries that extend HTML capabilities. Do you mean libraries like Turbolinks[1] and/or Intercooler[2] here? I'm interested in what libraries you use, and others like these which help "bridge the gap" between traditional and single-page sites. [1] https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks [2] https://intercoolerjs.org/ https://intercoolerjs.org/
  - bradstewart 6y ago
    Turbolinks and Stimulus are two tools I find quite useful. Yes, I like Rails and the way Rails does things.
  - gambler 6y ago
    Yes, those are some of the examples. You can roll your own as well. With modern JS and CSS selectors you can create useful, reusable libraries with just several dozen lines of straightforward code.
  - gunnarmorling 6y ago
    Unpoly [1] is another one in that camp. Made good experiences with to smoothen page transitions in a server-side rendered app [2]. I find this model much more approachable for backend devs than going all-in on SPA. It doesn't help of course with more fine-grained interactions like say in-place editing in a table. [1] https://unpoly.com/ https://unpoly.com/ [2] https://www.morling.dev/blog/quarkus-qute-test-ride/ https://www.morling.dev/blog/quarkus-qute-test-ride/
snazz 6y ago
As discussed on a recent thread (https://news.ycombinator.com/item?id=23137324 https://news.ycombinator.com/item?id=23137324), there are a variety of nice frontend tricks to make a server-rendered site feel nicer (LiveView, TurboLinks, Livewire, instant.page). I'm a fan of these kinds of solutions. For my 100% static website, https://instant.page https://instant.page does make it feel instant. TurboLinks feels a little "heavier" and has a more complex interaction with other frontend code, but it works very well.
- filleduchaos 6y ago
  Yes - those were the exact technologies I had in mind when reading that paragraph. We've been pre-fetching/loading HTML in place for ages! If all you need is faster/less jarring transitions between static pages, it's incredible to me that anyone would immediately reach for an SPA.
  - hombre_fatal 6y ago
    Funnily enough, the TFA is on a Ruby on Rails blogging platform that uses these tricks to feel incredibly fast. Just look at your network log as you hover links.
- danjac 6y ago
  I recently used Turbolinks + Stimulus for a Django side project. While these projects originated in Rails, it was quite easy to add to Django with some middleware and webpack tweaking. Stimulus provides some good structure and constraints for adding JS "sprinkles" to the site and overall it's worked very well. It feels more like I'm building with the browser and HTML rather than against or around them. That said, I don't think this approach would fly at work and would probably be frowned upon as maybe inefficient or out of date compared to the pure SPA+API architecture.
  - sknzl 6y ago
    I have also thought about adding Turbolinks and Stimulus to a Django project. Can tell more about the changes to the middleware and webpack?
pier25 6y ago
> avoiding full page loads Sure, you can do this with AJAX, but so far there are no SSR + component-level hydration + AJAX frameworks that solve this out of the box. Facebook is working on something similar though as Dan Abramov has hinted at on Twitter.
- filleduchaos 6y ago
  Why, exactly, does a static site need component-level hydration?
  - pier25 6y ago
    If it's a totally static site it certainly doesn't need it. But if you have any amount of interactivity (forms, widgets, etc) SSR makes total sense. Specially with component-level hydration which means the duplication of content would be lower than traditional SSR. AFAIK Marko is the only framework that has this feature. See this article for more info on this topic: https://medium.com/@mlrawlings/maybe-you-dont-need-that-spa-f2c659bc7fec https://medium.com/@mlrawlings/maybe-you-dont-need-that-spa-...
snowoutside 6y ago
I recently started using Sapper for a personal site and have been enjoying it immensely. I find that the abstractions that Sapper/Svelte make in order to avoid full page loads, preload data, etc allow me to write the site in a component-oriented way while not shipping 5MB of JS to the browser. And, Sapper scales as the app gets bigger in a way that a raw static site just can't. Rich seems to be advocating for a JS middle-ground here, which I think is a great direction to go in for this kind of workflow.
- filleduchaos 6y ago
  I don't mean to sound rude, and I apologise if I come across that way, but this is the exact sort of "JavaScript über alles" tunnel blindness that I'm tired of. Sapper/Svelte is _far_ more complex (especially in terms of overhead/learning curve for the site creator) than a tool a user wants to use to create enhanced static sites has any right to be. Not everything is an app, and frankly I think we build a lot of non-apps as if they are apps because we enjoy the feeling that we've engineered something.
rephrase 6y ago
I rephrased what you were saying to take out the negative valence. This is similar to other articles I've seen that draw a distinction between two choices: zero javascript vs full SPA. I think this is a false dichotomoy because most features advertised for SPAs (analytics, data/content preloading, transitions, optimized page loading) can be implemented for static sites as well. It would be nice to see frameworks that were more modular and interoperable because this would allow/give engineers the choice to decide which parts they want to be static and which parts they want to be dynamic. I'm not sure if I agree with what you're saying though because you haven't provided examples of how the features of SPAs can be accomplished without JavaScript. Do you have references and examples?
deleted 6y ago
[deleted]
soperj 6y ago
Agreed. Don't know why we're abandoning all the things we get for free with links just to do it all again in a SPA.
- ardy42 6y ago
  > Agreed. Don't know why we're abandoning all the things we get for free with links just to do it all again in a SPA. SPAs are newer, so they must be better, right? /s
  - arvinsim 6y ago
    The old way of doing things has always worked. Why bother with new technologies and paradigms? /s
- kristopolous 6y ago
  Many people doing the coding haven't really thought that deeply about the systems. I'd like "web programming" to start with Vannevar Bush's As We May Think, then go to Licklider, Ted Nelson, then hypercard programming (hypertalk). Set up a BBS, a gopher site and then write HTML for NCSA Mosaic. Read the RFCs and W3C standards, learn about Netscape's SSJS failure before touching nodejs, you know, serious academic scholarship. Maybe look at the failed TCL browser support, which has example snippets in the HTML 4 standard, understand why it didn't work, etc. I think we'd get dramatically better results
  - arvinsim 6y ago
    These don't get you a job. I haven't been to interviews that care about these things.

basch 6y ago

Right? Are you thinking something like ShareDB? https://github.com/share/sharedb https://github.com/share/sharedb As a person who is browsing the web, I do want server rendered pages, correct history of navigation, urls to match pages, a lack of refreshes, live collaboration with other users. What I dont want is a manual refresh to lose anything or bring me to a different page. And I want the site to work, and progressively fail if I have javascript off. Most interactivity can still be server side. Look at google.com, as you type in a search query, and they return a static update with results matching what youve typed so far.

filleduchaos 6y ago
> Are you thinking something like ShareDB? https://github.com/share/sharedb https://github.com/share/sharedb Ah - I didn't have anything quite that powerful in mind, more like fairly simple, browser-local enhancements to make interacting with regular old HTML pages more pleasant. For example a drop-in library that would save the state of a form and restore it on a refresh, like the old formsaver jQuery plugin. I would like to see an ecosystem of libraries like that again

trashburger 6y ago

>I'd love to see more mindshare go towards building libraries that are drop-in/"just add water" progressive enhancements for static sites. Sounds like jQuery plugins. Seriously though, I wish for a similar thing without the baggage. Maybe there needs to be a common interface defined for such "just add water" libraries.

filleduchaos 6y ago
There was/is so much that was genuinely awesome about jQuery. I still remember fiddling around with my blog as a teenager and being blown away by the DataTables plugin.
- jbergens 6y ago
  And large jquery apps often had so much spaghetti code that it took years to unravel.
  - filleduchaos 6y ago
    Interestingly enough, neither myself nor MacWright advocated returning to writing large jQuery apps so I truly fail to see how this comment is relevant.

gambler 6y ago

This. I've long ago abandoned spaghetti mega-scripts and SPAs in favor of targeted JS libraries that extend HTML capabilities. They're not web components, they don't require some framework to manage, and my HTML works fine without them, but if I load the library and add certain attributes or tags to my markup, I get extra capabilities. The libraries don't require crazy tooling to manage, don't have extensive dependencies and so they facilitate steady incremental development. I'm very happy with this approach and I'm reusing code I've written years ago for completely different projects.

zeugmasyllepsis 6y ago
> .. in favor of targeted JS libraries that extend HTML capabilities. Do you mean libraries like Turbolinks[1] and/or Intercooler[2] here? I'm interested in what libraries you use, and others like these which help "bridge the gap" between traditional and single-page sites. [1] https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks [2] https://intercoolerjs.org/ https://intercoolerjs.org/
- bradstewart 6y ago
  Turbolinks and Stimulus are two tools I find quite useful. Yes, I like Rails and the way Rails does things.
- gambler 6y ago
  Yes, those are some of the examples. You can roll your own as well. With modern JS and CSS selectors you can create useful, reusable libraries with just several dozen lines of straightforward code.
- gunnarmorling 6y ago
  Unpoly [1] is another one in that camp. Made good experiences with to smoothen page transitions in a server-side rendered app [2]. I find this model much more approachable for backend devs than going all-in on SPA. It doesn't help of course with more fine-grained interactions like say in-place editing in a table. [1] https://unpoly.com/ https://unpoly.com/ [2] https://www.morling.dev/blog/quarkus-qute-test-ride/ https://www.morling.dev/blog/quarkus-qute-test-ride/

snazz 6y ago

As discussed on a recent thread (https://news.ycombinator.com/item?id=23137324 https://news.ycombinator.com/item?id=23137324), there are a variety of nice frontend tricks to make a server-rendered site feel nicer (LiveView, TurboLinks, Livewire, instant.page). I'm a fan of these kinds of solutions. For my 100% static website, https://instant.page https://instant.page does make it feel instant. TurboLinks feels a little "heavier" and has a more complex interaction with other frontend code, but it works very well.

filleduchaos 6y ago
Yes - those were the exact technologies I had in mind when reading that paragraph. We've been pre-fetching/loading HTML in place for ages! If all you need is faster/less jarring transitions between static pages, it's incredible to me that anyone would immediately reach for an SPA.
- hombre_fatal 6y ago
  Funnily enough, the TFA is on a Ruby on Rails blogging platform that uses these tricks to feel incredibly fast. Just look at your network log as you hover links.
danjac 6y ago
I recently used Turbolinks + Stimulus for a Django side project. While these projects originated in Rails, it was quite easy to add to Django with some middleware and webpack tweaking. Stimulus provides some good structure and constraints for adding JS "sprinkles" to the site and overall it's worked very well. It feels more like I'm building with the browser and HTML rather than against or around them. That said, I don't think this approach would fly at work and would probably be frowned upon as maybe inefficient or out of date compared to the pure SPA+API architecture.
- sknzl 6y ago
  I have also thought about adding Turbolinks and Stimulus to a Django project. Can tell more about the changes to the middleware and webpack?

pier25 6y ago

> avoiding full page loads Sure, you can do this with AJAX, but so far there are no SSR + component-level hydration + AJAX frameworks that solve this out of the box. Facebook is working on something similar though as Dan Abramov has hinted at on Twitter.

filleduchaos 6y ago
Why, exactly, does a static site need component-level hydration?
- pier25 6y ago
  If it's a totally static site it certainly doesn't need it. But if you have any amount of interactivity (forms, widgets, etc) SSR makes total sense. Specially with component-level hydration which means the duplication of content would be lower than traditional SSR. AFAIK Marko is the only framework that has this feature. See this article for more info on this topic: https://medium.com/@mlrawlings/maybe-you-dont-need-that-spa-f2c659bc7fec https://medium.com/@mlrawlings/maybe-you-dont-need-that-spa-...

snowoutside 6y ago

I recently started using Sapper for a personal site and have been enjoying it immensely. I find that the abstractions that Sapper/Svelte make in order to avoid full page loads, preload data, etc allow me to write the site in a component-oriented way while not shipping 5MB of JS to the browser. And, Sapper scales as the app gets bigger in a way that a raw static site just can't. Rich seems to be advocating for a JS middle-ground here, which I think is a great direction to go in for this kind of workflow.

filleduchaos 6y ago
I don't mean to sound rude, and I apologise if I come across that way, but this is the exact sort of "JavaScript über alles" tunnel blindness that I'm tired of. Sapper/Svelte is _far_ more complex (especially in terms of overhead/learning curve for the site creator) than a tool a user wants to use to create enhanced static sites has any right to be. Not everything is an app, and frankly I think we build a lot of non-apps as if they are apps because we enjoy the feeling that we've engineered something.

rephrase 6y ago

I rephrased what you were saying to take out the negative valence. This is similar to other articles I've seen that draw a distinction between two choices: zero javascript vs full SPA. I think this is a false dichotomoy because most features advertised for SPAs (analytics, data/content preloading, transitions, optimized page loading) can be implemented for static sites as well. It would be nice to see frameworks that were more modular and interoperable because this would allow/give engineers the choice to decide which parts they want to be static and which parts they want to be dynamic. I'm not sure if I agree with what you're saying though because you haven't provided examples of how the features of SPAs can be accomplished without JavaScript. Do you have references and examples?

deleted 6y ago

[deleted]

soperj 6y ago

Agreed. Don't know why we're abandoning all the things we get for free with links just to do it all again in a SPA.

ardy42 6y ago
> Agreed. Don't know why we're abandoning all the things we get for free with links just to do it all again in a SPA. SPAs are newer, so they must be better, right? /s
- arvinsim 6y ago
  The old way of doing things has always worked. Why bother with new technologies and paradigms? /s
kristopolous 6y ago
Many people doing the coding haven't really thought that deeply about the systems. I'd like "web programming" to start with Vannevar Bush's As We May Think, then go to Licklider, Ted Nelson, then hypercard programming (hypertalk). Set up a BBS, a gopher site and then write HTML for NCSA Mosaic. Read the RFCs and W3C standards, learn about Netscape's SSJS failure before touching nodejs, you know, serious academic scholarship. Maybe look at the failed TCL browser support, which has example snippets in the HTML 4 standard, understand why it didn't work, etc. I think we'd get dramatically better results
- arvinsim 6y ago
  These don't get you a job. I haven't been to interviews that care about these things.