Hacker News Reader

Comment by filleduchaos | Hacker News Reader

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]

View on HN

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.

> .. 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 [2] https://intercoolerjs.org/

Turbolinks and Stimulus are two tools I find quite useful. Yes, I like Rails and the way Rails does things.

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.

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/ [2] https://www.morling.dev/blog/quarkus-qute-test-ride/

As discussed on a recent thread (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 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.

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.

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.

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.

I have also thought about adding Turbolinks and Stimulus to a Django project. Can tell more about the changes to the middleware and webpack?

https://gitlab.com/danjac/localhub/-/blob/master/social_bfg/...

IIRC there were some old packages but these were unmaintained and didn't work with later versions of Turbolinks, so I ended up looking at Rails source and other examples. Basically making sure to handle redirects and headers correctly. You can see the webpack config in the same project, pretty much just standard setup with some tweaks for loading Stimulus controllers.

Another is: DerbyJS, Racer, and ShareDB who have been fighting for this future for what feels like forever, but meteorjs just torched it from a popularity perspective, in the the event-driven server-side rendering realm. Despite giving a much worse end user experience, it was more popular with developers. Is Lever really the only company using Derby?

https://github.com/derbyjs/derby

https://github.com/derbyjs/racer

https://github.com/share/sharedb

https://derbyjs.com/

makes me harken for the good old days of backbone.js. everything you need, nothing that you don't.

I think its kinda great that you can just use ShareDB with whatever else you use, or also use racer, or go full blown framework. The way its abstracted gives you the power to choose more or less.

LiveView may not be "the future", everyone loves their Javascript too much, but it is the future for me. AJAX with the server is what I feel I was promised back in the Web 2.0 days, not tons of Javascript running in the browser.

instant.page looks super cool. It seems so simple after-the-fact, but I never thought about it. Thanks for sharing!

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

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.

And large jquery apps often had so much spaghetti code that it took years to unravel.

Interestingly enough, neither myself nor MacWright advocated returning to writing large jQuery apps so I truly fail to see how this comment is relevant.

Right?

Are you thinking something like 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.

> Are you thinking something like 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

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.

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.

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.

> 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

The old way of doing things has always worked. Why bother with new technologies and paradigms? /s

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

These don't get you a job. I haven't been to interviews that care about these things.

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?

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

Why, exactly, does a static site need component-level hydration?

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

Reply on news.ycombinator.com