Hacker News Reader

Comment by martin_drapeau | Hacker News Reader

I like the hybrid approach - sprinkle SPAs where page reloads should be avoided. Have many SPAs in your product. Just keep them small and assign each SPA a distinct use case or area.

Let's take a CMS as an example. The "Edit blog post/page" function can be its own SPA avoiding page reload when the post is modified. Managing the list of posts/pages can be another. A page reload in between steps is fine. Nowadays internet speed is fast and latency is pretty low. Browsers are also very efficient and vive caching. If you keep your SPAs small, the user won't see the lag going from one page to another.

Multiple SPAs also allows you to keep things modular. Different teams can own different parts.

Do not however bundle the entire CMS into a single SPA. It will most likely contain a lot of code and resources to load. That will kill performance and slow down development over time.

View on HN

I like what you've described but how different is that from just including jQuery to add some dynamicism to your page? Which, BTW, is what I think JS should really be used for.

Not GP, but I think the websites would be largely similar to the end user (multiple pages with dynamic bits). However, I think there is a notable architectural difference. Modern JS frameworks are much more focused on providing reusable components with clear methods of interop and communication. I think the codebase of a "multiple small SPAs" would be easier to reason about and develop than a jQuery tangle. But in terms of functionality, its probably not much different than sites from 10 years ago (I don't think this is a bad thing).

It's a spectrum and what's being advocated is using the right tool for the right job.

Rendering the marketing pages of the site -> HTML+CSS

Need to add the tiniest bit of interactivity -> jQuery

Have a "module" of functionality that -> SPA

Its no different. React/Vue are modern evolution of jQuery. They allow you to organize front-end code with strict conventions and best practices. You can achieve the same result with jQuery and Backbone for example. But you'll need to discipline yourself a lot and good luck hiring developers (they all want to work on React and Vue).

> React/Vue are modern evolution of jQuery.

I disagree. They are whole frameworks taking a completely different approach than jQuery, which is basically just a helper library.

jQuery is useful as a tool for operating within an externally organized application (or otherwise mostly static DOM tree). It simplifies low-level operations like DOM element manipulation.

Frameworks like React or Vue take a top-down, more declarative approach on how the DOM is built and updated. It's in many regards more powerful and more productive, but comes at a certain cost (setup complexity, total page size, certain aspects of performance).

So, which tool is best for your project really depends on the individual use case.

jQuery plugins are extremely powerful. Look at fullcalendar.io as great example. Web 2.0 was entirely built upon that. I hate to see people dismissing jQuery and its legacy as just a library. There is a huge community built around jQuery and thousands of plugins.

It ain't new and shiny but you can build anything with it. In fact, today jQuery is used on 97% of websites* while React and Vue are around 0.2%. I imagine that will change over time.

* Top 10M Alexa ranked: https://w3techs.com/technologies/overview/javascript_library...

Yeah, the minute you start reaching back to the server for a significant update to the client data model in order to support a view transition I think the benefits of SPA are lost.

Granted I've only deployed one SPA to prod and that was an Ember application but I'm not feeling the love based on that project.

jQuery is the old paradigm of micro managing the DOM with ES5 code.

The new paradigm is using data binding with the latest language features.

I get the gist, but in practice, how do you:

Share code between your SPAs, for example, utilities?

What if your SPAs have large dependencies (React, Vue), should every SPA come with their own?

Should every SPA have its own build tools?

What if there's an update to a library, should it be allowed that one SPA runs on an older library?

Not OP, but where I work, we have a hybrid approach for our system.

> Share code between your SPAs, for example, utilities?

We alias a common folder for our utils with webpack which allows all our code to use the same utilities. We actually have two. One for shared frontend and backend, and one for just shared frontend

> What if your SPAs have large dependencies (React, Vue), should every SPA come with their own?

Webpack code splitting is how we split our apps. We also build into multiple bundles to keep bundle size small. That does mean that React does get bundled with each, but if you split thing appropriately, you can potentially save off a few MB with caching each bundle from page to page.

> Should every SPA have its own build tools?

With webpack, you can build all your bundles with one config / command

> What if there's an update to a library, should it be allowed that one SPA runs on an older library?

We have a root package.json for all of our react apps. This means that we don't update a library unless we can update it across the board. It takes more time to test upgrades, but it also means smaller bundles, easier package management and easier maintenance in the long run.

They wouldn't be completely separate SPAs. They'd rather be SPA-like widgets embedded in HTML pages. Using the same Vue/Rect/etc and sharing libraries together.

I'm super excited to see WebComponents support. It'll be (and already is if you don't care about IE support) possible to implement this without any frameworks/libraries/etc :)

An SPA by definition implies one one HTML document or page load by the browser. Following requests are all AJAX or async. So yes, they would be separate SPAs using the same code.

More like widgets, since each of them wouldn't be yet another HTML document. And "multiple SPAs" sound like multiple isolated instances of React/Angular/etc. Which wouldn't be the case either.

"Web Components" is a great name IMO.

You should be sharing the front-end architecture you choose across all SPAs.

These are good questions, but I'd also be curious to hear of some more concrete examples. In the interest of continuing the discussion, OP might be referring to some hybrid approaches like Backbone/Knockout where they aren't trying to solve some of the more interesting problems (e.g. bundling, dependency management, etc.). Of course, this ignores those problems and you could argue that different SPAs could be reduced to different "controllers" or some other framework specific abstraction.

Reply on news.ycombinator.com