Hacker News Reader

Comment by austincheney | Hacker News Reader

The most common reasons for building a SPA:

* That is the design pattern dictated by your large framework.

* Maintaining state is absurdly simple, but it requires original code if not using a big framework.

* The browser provides a simple standard API for interacting with HTML, but your framework provides abstractions you didn’t know you could live without.

That’s it. Developers twist themselves in knots trying to qualify their opinions as anything more valid than what sounds like incompetence, but with any level of informed discussion it’s clearly about competence (or insecurity).

View on HN

I'll offer up another reason, which I feel is a little more accurate:

* Your web app requires heavily interactive bits, such as smart forms, smart tables, previews, content editing, etc. To deliver such functionality in a maintainable way, you use a framework. (As a side note, yes it is possible to deliver this functionality in vanilla JS, but to make it maintainable one must essentially build an ad hoc framework.) Because most frameworks push users towards a SPA, you end up following the path of least resistance and developing a SPA.

I would argue most websites never require any of those. When any of those are required they don’t need a giant framework to achieve maintainability. All that’s needed to achieve maintainability is a competent developer who values both simplicity and written documentation.

This sentiment frustrates me. The majority of web developers today are application developers. I've spent the past 5 years delivering business applications via the web as a platform. The web has a lot of advantage as a platform: no install, cross platform, networked by default. But the web was not designed as an application platform, so making it into one is complex. Business applications have inherent complexity as well, and managing all that complexity is a non trivial task.

Posts like this frustrate me because you seem to be suggesting complexity in the web domain is largely incidental.

I would qualify this: The web is simple when one uses it as intended. (hyperlinked documents that may or may not have interactivity beyond the hyperlinking and embedded media or animations etc.) The web is complex when one attempts to do "GUI by RPC". If one is OK with page reloads, this asynch remote folder browser hypercard thingy is fine. If one seeks to replicate the event-loop desktop "window"-based application one will have the use-case for large frameworks as one will literally be re-inventing all the wheels, which they tend to do, as this is not the default behavior of the application we call a web browser.

Complexity in web products is largely the result of developers who don’t care because they need to ship a product only if that product is written in an extremely familiar way. That’s a product of people who don’t know what they are doing opposed to inherent technological impediments.

I form this opinion as a professional web developer with 20 years experience.

I respect your experience, but that does not match up with what I've seen, and what I've seen by proxy networking with other developers in my area. I do personally think simplicity is a virtue. I always try to collaborate with our business team to deliver only what is needed, in the most straightforward way. But if the customer needs a 20 field form, with logical dependencies and validation between fields, as well as an interface for searching/filtering/editing entries, there is only so much that can be simplified. And yes I know all of that can be done with vanilla JS, but I've done it both ways and I prefer the framework.

Just to chime in here. To be clear, I think dropping a vdom implementation into a page is a good middle ground between full blown “framework” and “roll your own js”. I’m not familiar with vue, but I’ve used React (a library!) to great effect on pages that require that extra bump of behavior.

It’s such a shame that many of these tools are pushed as large SPA solutions when they can just as easily be included ad-hoc over a CDN when necessary.

* And I agree that it’s just madness to wire up your own components once the use case becomes anything more than the most trivial behaviors.

I doubt your customer specified dependencies as a business requirement.

I always enjoy a good faith discussion, but if you aren't going to respond to what I actually wrote there's no need to continue this. I _know_ the functionality I mentioned can be shipped without a framework. I _have_ shipped web apps without a framework. I've personally found the overhead of designing and enforcing an ad hoc framework to be not worth the effort.

...almost... i'll accept "an SPA on one server-side route for that one complicated page that's full of bells and whistles."

and then I'm still going to say "yeah, i'm roughly equally verbose and spaghetti-like in even the best most prescient framework from the gods themselves" and merely wish for the means of modularization: breaking my server- rendered page that my javascript "unfolds from" into further little bits that can each have their own smaller less-spaghetti like world without having to try to dynamically load and include javascript on the client. Break it up. Divide et impera...

Another big reason is that developers want to deliver a specific user experience that is simply not possible with the default page loading functionality of most browsers.

You mean the specific experience when back buttons aren't working? Or when urls don't make sense? Or when you can't just share the content by copying the url because it no longer identifies the conten? Or when you can't say if something is loading, missing, or broken?

This is my user experience with SPAs regarding navigation.

Use better SPAs.

Agree. There are a lot of bad SPAs out there, but that's a testament to how easy they are to get started with and their popularity.

That doesn't mean good SPAs don't exist - many do!

If an spa is behaving like that, the coders have failed at their job.

"PHP is fine, it's just poor developers making bad sites".

And then people stopped using PHP.

People stopped using PHP in which planet?

Exactly.

> And then people stopped using PHP.

Evidence?

In my experience, PHP seems to be more in use now than ever.

A quick HN search shows PHP’s unpopularity. Check the Stack Overflow survey if you need a second opinion.

Conversely, I’m gonna need evidence that PHP is more popular than ever because that absolutely is an extraordinary claim.

PHP wasn't good, fine maybe, though I understand it's better now.

it was kind of slow, and all the functions were inconsistent, and had a lot of foot-guns. It was easier to write more robust code and model-view-controller code in other languages. (not that it was impossible in php)

It’s hard to make the claim that PHP is a bad language and also claim that very similar complaints don’t also apply to Javascript. They’re both languages defined by their popularity in spite of how poor the language actually is.

javascript is a dumpster fire.

unfortunately it's the only actually viable language in the browser.

That’s arguably the best reason to develop an SPA. But I don’t think the linked article is arguing against that as much as arguing against using “SPA think” in places where the user experience really doesn’t require it. There are web sites which are basically magazines/blogs whose reading functionality relies on JavaScript. Building a web site like it’s an app may give some advantages to the developers, but it’s almost always a slower, and sometimes more fragile, experience compared to just delivering HTML.

What's a big framework to you? is React one?

Reply on news.ycombinator.com