5 ms·

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 dist

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.

WA 8y ago
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?
- mantas 8y ago
  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 :)
  - martin_drapeau 8y ago
    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.
    - mantas 8y ago
      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.
- jj12345 8y ago
  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.
- martin_drapeau 8y ago
  You should be sharing the front-end architecture you choose across all SPAs.
- Prefinem 8y ago
  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.
0x445442 8y ago
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.
- martin_drapeau 8y ago
  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).
  - blauditore 8y ago
    > 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.
    - martin_drapeau 8y ago
      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/all https://w3techs.com/technologies/overview/javascript_library...

WA 8y ago

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?

mantas 8y ago
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 :)
- martin_drapeau 8y ago
  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.
  - mantas 8y ago
    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.
jj12345 8y ago
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.
martin_drapeau 8y ago
You should be sharing the front-end architecture you choose across all SPAs.
Prefinem 8y ago
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.

0x445442 8y ago

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.

martin_drapeau 8y ago
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).
- blauditore 8y ago
  > 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.
  - martin_drapeau 8y ago
    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/all https://w3techs.com/technologies/overview/javascript_library...