3 ms·

> The best solution I’ve seen is the Single-SPA “meta framework” to combine multiple frameworks on the same page without refreshing the page (see this demo that

> The best solution I’ve seen is the Single-SPA “meta framework” to combine multiple frameworks on the same page without refreshing the page (see this demo that combines React, Vue, Angular 1, Angular 2, etc). I have very little front-end experience (most of the web dev work I've done was hand-written javascript). But having the overhead of a big, comprehensive framework such as React, Angualar already seems like an overkill to me. But having several such frameworks on the same page seems outrageous, it cannot be considered good engineering. Where are the engineering good practices of efficiency, craftsmanship etc?

cphoover 8y ago
The issue also becomes scope pollution. When you load multiple frameworks on the same page, you need something like iframes, or shadow dom to get isolation. Typically modern JS dependencies are pretty small compressed and gzipped. Especially if there is some mechanism for deduping the dependencies across (ui-microservices). I think when web-components/shadow dom is finally ready we will see this type of pattern a lot more. Right now because of scope conflicts this becomes a little difficult. It's like we want the isolation of iframes, where the content lives within the same document flow as the rest of the document. I work at an enterprise where we have several different applications. But we have a universal header and footer component. Right now it is a nasty mashup of jquery and other js libraries that just get's pasted into everyone's app without any isolation. It would be great if we could have a shadow dom node that isolates something like a small vue or react app from the rest of the application. Right now I think the only way for this to work is to coallesce around a single framework. When it comes to download size of the frameworks, if we had scope isolation as in with shadow dom/web components, then we could actually utilize CDN's more frequently. Think a CDN for web components, where chances are that slider element you add to your page has already been downloaded. To avoid downloading the wrong file, we have subresource integrity attributes in HTML now too https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres.... So if people started fetching resources from a cdn by default, it's possible 90% of resources have already been downloaded by the client before they even reach the site.
bunderbunder 8y ago
I'm even thinking about the human issues here. If you've got different teams using different technologies, over time you're going to end up with a tangled, poorly standardized codebase where the same problem is solved 6 different ways in 6 different places, and people are afraid to make changes because it's hard to predict their impact. I have had the pleasure of working at a microservices shop that had everything working very, very well. The system was a pleasure to work on, development was easy, the operations team was more in control than anywhere else. But I think they accomplished it by unilaterally banning a lot of the things that people think microservices will let them do. Only two programming languages were allowed (a low-level one for the most performance-critical stuff, and a high-level one for the rest), only one flavor of database was allowed, communication protocol changes and any new 3rd party libraries had to be approved by a Star Chamber tribunal that basically said no to everything, lines of communication were strictly controlled (viz., none of this "everyone talks to everyone else through Kafka"), etc. etc. It was glorious. It really was. Easiest codebase to work in ever. Did I get to use my favorite languages or libraries? Nope. Was that holding the company back? Double nope.

cphoover 8y ago

The issue also becomes scope pollution. When you load multiple frameworks on the same page, you need something like iframes, or shadow dom to get isolation. Typically modern JS dependencies are pretty small compressed and gzipped. Especially if there is some mechanism for deduping the dependencies across (ui-microservices). I think when web-components/shadow dom is finally ready we will see this type of pattern a lot more. Right now because of scope conflicts this becomes a little difficult. It's like we want the isolation of iframes, where the content lives within the same document flow as the rest of the document. I work at an enterprise where we have several different applications. But we have a universal header and footer component. Right now it is a nasty mashup of jquery and other js libraries that just get's pasted into everyone's app without any isolation. It would be great if we could have a shadow dom node that isolates something like a small vue or react app from the rest of the application. Right now I think the only way for this to work is to coallesce around a single framework. When it comes to download size of the frameworks, if we had scope isolation as in with shadow dom/web components, then we could actually utilize CDN's more frequently. Think a CDN for web components, where chances are that slider element you add to your page has already been downloaded. To avoid downloading the wrong file, we have subresource integrity attributes in HTML now too https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres.... So if people started fetching resources from a cdn by default, it's possible 90% of resources have already been downloaded by the client before they even reach the site.

bunderbunder 8y ago

I'm even thinking about the human issues here. If you've got different teams using different technologies, over time you're going to end up with a tangled, poorly standardized codebase where the same problem is solved 6 different ways in 6 different places, and people are afraid to make changes because it's hard to predict their impact. I have had the pleasure of working at a microservices shop that had everything working very, very well. The system was a pleasure to work on, development was easy, the operations team was more in control than anywhere else. But I think they accomplished it by unilaterally banning a lot of the things that people think microservices will let them do. Only two programming languages were allowed (a low-level one for the most performance-critical stuff, and a high-level one for the rest), only one flavor of database was allowed, communication protocol changes and any new 3rd party libraries had to be approved by a Star Chamber tribunal that basically said no to everything, lines of communication were strictly controlled (viz., none of this "everyone talks to everyone else through Kafka"), etc. etc. It was glorious. It really was. Easiest codebase to work in ever. Did I get to use my favorite languages or libraries? Nope. Was that holding the company back? Double nope.