3 ms·

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), sho

by 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.

by WA 8y ago

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.