Comment by astockwell | Hacker News Reader

Comment by astockwell | Hacker News Reader

Parent Full thread

I'm the only person on my current team (an internally-focused engineering team) who has experience building websites/apps for external paying clients (e.g. people who will freak out if anything fails to load faster than they can blink, on their phone's 3G connection).

I was taken aback by how many times I had to argue with my team, our sister teams, our consultants/contractors, and even our (non-technical) leadership about NOT building a SPA when we came across 1 form in our large codebase that required some extra interactivity.

For some reason many developers seem to be fine turning a blind eye to the actual page-rendering time, maybe because it's hard to benchmark with tools? (although I'm skeptical of that). I find an overlap however in that those same developers seem to not understand why multiple database query roundtrips are worse than 1 query followed by some in-memory munging.

I'm sure I'm biased by my background, where we were profiling like mad, doing crazy things like purposely modifying images/hand-building sprites to pack better, minifying CSS before SASS/LESS existed, and every millisecond to finish rendering mattered. Good times.

Really depends on what is your product and how users use it.

If the user just visit a few pages every time, you probably don't need SPA.

However, if your website has hundreds of pages and users need to navigate around a lot, SPA would actually reduce load time by cutting down the amount of data being transferred over network every time users goes to a different page. It also makes the experience navigating between pages smoother.

browser cache solves this problem

Curious what's the strategy you use to invalidate browser cache for non-SPA? When deploying new changes.

SPA's tend to come with build systems, but that is just a side effect of their complexity. You can have a front-end build system independent of SPA/MPA architecture. In fact, you should, at least for minification and whatnot. That system can add a content hash or some other strategy to force invalidation at build time for deployed artifacts. Barring that, whatever is serving the asset should handle it's caching/TTL stuff correctly, but config of that can be hard (in complexity or domain knowledge.) Build hashes have been the most resilient approach that I've found so far. Mostly because it is easily automated in artifact generation.

Versioned URLs of everything except index.html should work just fine.

As others have mentioned: app.min.js?$hash-or-date-or-releasever$

versioned url

Sorry if it is not clear, I was referring to html files returned by servers when user visits old-fashioned server-rendered web pages (non-SPA pages) like `/page1` or `/page2`.

How do you version urls like those?

Something like `/page1?t=201811292359`? That seems ugly to the users.

rules i use:

- content under certain url should never change

- if it has to change then use ESI or/and smaller cache expiration times

- if it has to change very often/realtime, then use static html as skeleton and load only required information via javascript. f.e.: info about currently signed in user, eshop basket

What I find funny about this comment is that your experience of being a flabbergasted subject matter expert is basically the same for every SME in any domain on your team, your sister teams, etc. I've been there too.

It's rare to find developers who've deeply specialized in multiple different domains.

Reply on news.ycombinator.com