Comment by hahamrfunnyguy | Hacker News Reader

Comment by hahamrfunnyguy | Hacker News Reader

I've been doing web development for over twenty years now. Perl, PHP, ASP, Rails, .NET, Flash, Flex, Silverlight and various JavaScript and SPA frameworks.

I really like the MPA approach. To me it means building a bunch of mini SPAs. You can still stuff everything into a single SPA to deploy to a mobile app, but it gives you the advantage quicker first-time page loads and a lot of extra flexibility.

Compared to the Web 1.0 way of doing things where you POST and then reload the page, you're taking an API based approach so when a 3rd party needs to integrate with you - that part is probably done already.

A lot of sites use the MPA approach wrong though. They load the "apps", then proceed to make a whole bunch of asynch requests for data. In most cases, using a mechanism to inject in data when a page first loads makes everything feel a lot faster.

It's the best of both worlds: you get the speed of the old school web and the flexibility of modern practices.

I couldn't agree more. It is a spectrum.

<-- Fully MPA ... MPA with mini SPAs ... Fully SPA. -->

Many don't venture in the middle. Not sure why. Do not stay on either end. It will bite you!

People don't venture in the middle because it's complicated and scary for many people due to the skill requirements. It only starts to feel safe to play there when you have experience with development at both ends of the spectrum because you likely won't have the support of tools which are intended to run there.

Further, it's a compromise that is difficult to explain and justify to management. If they are risk averse then they won't want to move far from the safety of the frameworks at either end of the spectrum.

If you are a developer of frameworks, it also seems advantageous to go to one end of the spectrum because it's easier to reason about the problem space. When you target the middle there starts to be more variations in how to handle it best. It's really the only place to go though, if folks really want to innovate and provide better experiences for all.

Laravel encourages the middle ground. Sprinkle Vue.js. I've worked in both MPA and SPA. The middle ground is much faster.

You can pre-load objects in the page and then use AJAX to finalize loading. The user experience is snappier.

The bundle size also remains smaller. Divide and conquer.

Yes, it does require being comfortable navigating back and front end. Over time, a good developer will get there.

This trope of "if you were just skilled enough" needs to die. Things cost money. They cost money to maintain and evolve. If a solution requires exceptionally high skill that means it is very expensive and pushes employees to their limits. Meaning it is not a healthy technological solution.

It's funny how the article goes on about "If managers were just good enough". But the problem is managers face real world constraints. They can't just give us unlimited resources to live out our complex ego-driven tech fantasies.

>> This trope of "if you were just skilled enough" needs to die. Things cost money. They cost money to maintain and evolve.

I don't disagree terribly with the trope aspect, but people are hurting from the cost to evolve and maintain projects using approaches that sit at the extremes. There needs to be some understanding, and possible embrace, of elements of the middle ground in order to be truly maintainable in a lot of cases.

My call to action would be more for the innovators and framework developers to think more about this. Companies can try to solve it for themselves, but forces like staff turnover prevent meaningful progress for most.

If you have multiple pages each with their own javascript that allows them to behave like an application, is it still considered a SPA? Yes it behaves like an application, but javascript running AJAX is hardly different from what traditional webpages already do. To me the defining trait of a SPA is a site that does all its routing within a single html page (which I consider an antipattern).

Back-end routing is very solid. My experience is that front-end routing is complex and is hard to maintain. Multi SPA allows you to modularize your application into different concerns.

Most of the time, an SPA can be limited to one action or group of actions. For example one SPA to manage the user's preference, another for managing a list of objects, so on and so forth.

> Back-end routing is very solid. My experience is that front-end routing is complex and is hard to maintain.

There doesn't seem to be anything inherently more complex about routing on the front end vs the back end. Why does it turn out to be messy when the back end isn't? What's keeping you from using the same patterns?

If you implement it on the frontend you lose all the builtin navigation behavior that the browser gives you natively when loading pages. You instead get to build all that behavior yourself in places where you think it should exist using your best judgment (things like deciding when to push to browser history state, for example, may be perceived as breaking the back button to many users if you haven't thought through your app's navigation hierarchy very carefully).

You can cache templates in the user's browser and insert those into the user's page and show/hide parts of a single page.

For example, you can use mustache.js to load a cached "Preferences" template and just grab the data from the server to fill it in, or from the browser's IndexedDB if you've stored that data there.

Does this approach not qualify as a single SPA?

MPA + SPA is how most native Android and iOS apps are developed. I agree with the other commenter that a single html file is an anti pattern.

Reply on news.ycombinator.com