Hacker News Reader

Comment by _ea1k | Hacker News Reader

This reads as "get off my lawn" with a lot more words, but only because of a couple of things. "built exclusively with popular and proven tools." You might as well say, "built exclusively by developers with vast industry experience". At some point, it becomes self-defeating, as tools don't spring into existence full of popularity and history.

"page reloads vs. single page applications" - I've worked with plenty of "page reloads" frameworks that were at least as complex as their SPA counterparts. I get that you don't like Javascript, but seriously, SPA is proven and popular at this point too.

View on HN

Despite their proliferation, SPAs are still nowhere near as popular as traditional page-reload websites. And they shouldn't be - much like micro services and NoSQL, they require additional justification. If my friend tells me he's using Postgres at work, I won't give it a 2nd thought. If he says he's using CouchDB, I'll say "Interesting. What made you choose that?"

The author has probably been burned by people who use shiny/new tech just because it's shiny/new. And I guess he thought we needed a manifesto for this situation. But I agree, the "get off my lawn" tone makes it not very effective IMO.

I think a huge part of the shiny tech proliferation comes from the pseudo-agile movement. Usually pseudo agile means one thing: no spec.

You get a team tell them "let's do this widget" with no detail, no edge case scenario, no perf requirement. So they choose last awesome tech which solution a problem they got last time and will look good on a resume. And only after a month or two of making things do the real hurdle of this tech start appearing. All the things you never see mentioned in those "let's get started" tutorials or shiny-techs online conference.

With some time spent thinking about the problem space and what happen when things go bad your team could have sensed that nothing is all sugar and rainbows. Take micro services: at first it looks elegant. But when you start thinking about how to manage transactions for some actions across multiple services or how to handle some of your server dying then coming back to life you suddenly have the urge to stop and check if you really need this kind of architecture at first.

It might as well have just said "get off my lawn" and nothing else.

It starts with a list of things that everybody obviously wants, goes on to give very specific examples with absolutely no backing or evidence, and finishes with some hand-waving "you get the idea".

Also, "nor will we defend our lack of knowledge of their hyped and volatile technologies" really comes off as complacent ignorance.

The best way to try and fight something is to first learn about it. You might even learn that the thing you're fighting has some useful lessons in it.

Yeah, pageload based frameworks and design strategies are a whole mess of complexity that SPAs actually avoid completely. That said, one has to be careful to do reasonable things with the URL bar, so bookmarking, etc works as users expect. This adds some of the complexity back, but not nearly as much as page-load based forms can. The SPA design pattern also creates a nice separation of concerns between the front-end and back-end services. It really is much simpler, conceptually and practically.

but pageload based frameworks abstract almost all of that mess away from the developer, where was an SPA has less of that mess, but a bunch of different messes.

I don't advocate for pageload-based frame works (asp.net webforms, cf, a bunch of roll your own phps, etc), and I believe a lot of the vendors of them have been kind of moving away from them toward a more bare-metal HTTP approach, but that doesn't mean they don't have a place.

In RAD and click and drag IDEs that large corporations prefer, you can hand a single Junior level developer a requirements document, and expect them to be able to build a back-office type application.

You've made a key point here that I continue to struggle with handling consistently: managing the address/history for an SPA. Is there any prescriptive guidance for doing so that is consistent within a given framework (e.g. Vue, React)?

I dunno about prescriptive, but in React the use of `react-router` and `history.push` certainly seem to tick the boxes in my use cases.

Honestly, if you're going to use browser JavaScript, I don't see why you wouldn't do an SPA.

Cookies and injection attacks vs Local storage

Fat server sessions vs fat client sessions

Forms and CSRF vs XHR JSON

Let's not pretend that web tech has somehow been Nirvana at any point in the past.

No but it's been automated very well, battle tested, and plays well with the browser.

While I still stumble upon SPA that can't even get navigation right.

But the main reason is still this:

I compared the serverless website (considered a state of the art SPA) with the hackernews website (considered a student level website) on an edge connection in the German country side:

Hacker news:

- first load: 6 seconds

- next loads: 3.5 seconds

Serverless:

- first load: 26 seconds

- next loads: 7.5 seconds

For a webpage displaying static text.

I agree with you as well, SPA are generally slower and the navigation always has issues as the application grows. I guess reimplementing the browser navigation is a bit complex.

I think a good SPA is a superior experience but a bad SPA is worse than a traditional page load approach.

> 26 seconds

It takes like 4s for me.

Though I think you're kidding yourself if you think HN is typical.

I can't see any reason why there should be anything but a very small difference on way or the other.

> It takes like 4s for me.

You are not on an edge connection then.

> Though I think you're kidding yourself if you think HN is typical.

No, but serverless and NH have the same purpose of mostly displaying text.

What's an "edge connection"?

http://edgeconnection.net/ ?

I think the idea is not to use experimental technology at work. Go ahead and use a new sexy programming language or library that may be entirely defunct in 2 years on your own time, but don't saddle a company with that and think you're good at your job.

The dude is handwringing about NoSQL in 2018. Something like Cassandra is no longer "experimental technology." It is a well-understood technology with well-understood requirements (and they are high, that's why you do a business analysis to make sure they make sense) that happens to be non-relational.

He is handwringing about single-page applications. SPAs have been kicking around for, what, a decade? Let's be real--in this article the single-page application complaint is a proxy for "I don't like JavaScript" and he's entitled to that opinion but it is certainly not "experimental"; JavaScript is not going anywhere, it is well-understood both in browser and on the server, and the libraries and ecosystem are not going anywhere either--if Facebook died tomorrow there would still be React jobs in 2023.

There are parts of current software development that really, really suck. The author does not capture them; this is "new things are scary" complaining and very little more.

> SPAs have been kicking around for, what, a decade?

Only with big players: facebook, gmail, etc.

Small crew SPA usually suck big time precisely because there is not django/ror/etc equivalent for SPA. So people write it by hand. And they don't all have the talent pool and money the GAFAs have.

Small crew web apps usually suck, too. I have yet to see React (not to exclude Vue etc., React is what I use) make a nontrivial one worse than it otherwise would be, if only because it forces some semblance of separation of concerns upon the developer.

(And, speaking personally, my now-standard stack of TypeScript/Express/TypeORM/tsoa provides a level of architectural enforcement I've only really gotten previously on the JVM, but with significantly less mucking around with my runtime.)

It would be pretty hard to mess up a hackernews clone.

A HN clone SPA though...

First, let's see if they can get code splitting right to not make it loads 3mo/page.

Then if they can choose a stack that doesn't kill navigation.

Also, let's see how long it takes both team to come up with the same result.

My money is on the static stack. Just the registration without a good framework is plenty of fun.

Not that you can't make a SPA with an old school framework. But for some reason, SPA lovers will often go full nodejs as well, which is basically 1000 of libs you have to hand picks and fuse together.

I work on more and more SPA every day. It's always the same deal: the cost is higher, and it needs smarter devs.

Bottom line: do one when it has a good added value for your users.

It's actually worse than you're saying.

NoSQL databases have been around since the 60s [1], and the term was created in 1998. Two decades ago. Is the author of this manifesto saying that they'll only work with tech from the 50s? Or is the 80s good enough? The 90s clearly isn't.

In fact, Ajax has _also_ been around for two decades; 1998 was a big year for the web, apparently. The Outlook Web App (a major milestone in SPAs) was created in 2000, 18 years ago.

This "manifesto" is nothing more than "I choose to bury my head in the sand and use outdated tech and ignore the state of the art!"

[1] https://en.wikipedia.org/wiki/NoSQL

I'm aware on both counts--I was more looking at it from the standpoint of common acceptance. Cassandra was first released in 2008 and became pretty manageable not too long after that. OWA was 1998 and GMail was 2004, but the tools were pretty grungy and hard to get into for awhile. I'd say that they didn't become really legitimately decent until Backbone (late 2010), but there were workable ones for a couple years before that.

Just saying that both SPAs and NoSQL have had _more_ than enough time to mature. It's not like they both were invented a decade ago; they were a decade _mature_ a decade ago.

Full disclosure: I work on a language that is almost by definition niche, and benefit from its adoption.

I think workplaces really, really should be using newer/"sexier" programming languages and libraries, but not as a blanket approach. People should be allowed to experiment and try new things, especially for projects or parts of projects that are new and exciting. This shouldn't be in lieu of existing and well-known technology.

They seem to have left it intentionally pretty vague in order for people to fill in these sorts of gaps. If they meant "don't use experimental technology at work" then they should say that.

If they are trying to imply it by giving examples of technologies that are hardly new or experimental, then that's even more cause for being explicit.

They say they're sick of "hyped and volatile technologies" which I think is the same thing as experimental technologies.

Perhaps they could have picked more black-and-white examples like blockchain, so many dead javascript libraries, so many rebuilds of existing technologies. But I happen to agree with their examples largely.

Unless you're explicitly looking to experiment with a specific technology or framework, I think its a good practice to start your implementation reasoning from a boring perspective. What this means for you personally will vary based on your skillset. However, if you can pull something off in an "engineering-easy" way, you can be wildly productive.

With that said, you have to be smart and know when boring is not enough. 3-tier apps are great until complexity pushes them into gnarly monolithic messes that resist change. And with some sensible UX thinking adopting SPAs can push your user experience forward. NoSQL databases might not be the best choice as your primary datastore but might be a better alternative than materialized views (Graph databases are often utilized by some organizations as part of their secret sauce)

Really well done SPA by small players are very rare though. So no, I wouldn't say it's proven.

Anybody can code a HN clone. An SPA HN clone that is not a total disgrace though ?

I think it would be quite easy to do using a framework like next.js[1]. For more complex applications it can be challenging to get an SPA to work right, but for things that behave more like websites than web applications (primarily just as linked documents) there are frameworks that make it trivial.

[1] https://nextjs.org/

If you make a web site, don't make a SPA. The a in spa stands for application.

I was working on a SPA 12 years ago, and even then it couldn't be considered "groundbreaking" - NetVibes and a few others had blazed that ground at least a couple of years before that.

The date I use for SPAs entering the mainstream is 2004-04-01 when gmail was released.

> I've worked with plenty of "page reloads" frameworks that were at least as complex as their SPA counterparts. I get that you don't like Javascript, but seriously, SPA is proven and popular at this point too.

It's certainly popular. I wonder if sites like github would be simpler for users, developers, and devops if they just embraced SPA - judging by your comment, maybe?

Reply on news.ycombinator.com