You’ll hear this talk at Elm Europe in June 2017. Massive thanks to @chrisui, @stealthpig, @zsoobhan, @spryle, @dumbNickname and everyone else who helped shape this proposal. You guys are awesome!
Choosing the right technologies when starting a project is super important. It’s almost impossible to change the stack later on. Betting on Elm is therefore a bit risky. Right?
Not anymore! Now we can use frontend microservices to pick the right tool for every job!
Traditionally, single page apps are monoliths. Here’s a React app, that’s an Angular app and this one is in Vue.js. This way, early stack choices turn into a strong tie-in as the project grows. It’s pretty tricky to introduce Elm to a mature project running on a different technology.
In this talk, we’ll see how web components change the game. Finally, we can use the right tool for every job! We can introduce Elm bit by bit to any JavaScript app – or neatly embed JavaScript UI nuggets in an Elm app.
We’ll learn from the ups and downs of regular microservices, catch a glimpse of the culture that this approach has brought about at Lystable and leave with a strong toolset to make things happen.
speaker
Tomek Wiszniewski
Tomek created elm-live – a tool widely used and loved by the Elm community. As an engineer at Lystable, he crafts delightful user interfaces and helps shape an engineering culture which allows everyone to unleash their superpowers.
With a degree in Architecture (yeah, building houses), he’s been using Elm for a number of exciting University projects – and a mind-blowing app for makers coming to the market soon.
Hey. What you write in the beginning of your description is not exactly true. Most of front end codebases really do have a monolithic structure, but some companies (like Spotify named by you during your talk in Wroclaw) use some production proven solutions to divide their code bases. During the talk we mentioned the iframes, as an alternative to web components based "browser only" solution, but there are other possibilities like Server Side Includes or Edge Side Includes. For example Varnish implements ESI and retrieves page fragments exposed under separate URLs (so it does not care who and how delivers the HTML). Some companies use Varnish only for fragments caching purposes (you can set TTL values per fragment), but with appropriate project structure it also provides you a way to compose web applications. When you compose on the server, you will not see that in the browser so sometimes it is not that easy to spot such things. The guys from compoxture made a short summary of available options in their rationale at the end of the project readme. Maybe you would like to have a look at that and mention those other approaches during your presentation to solve the problem and show how and why the one proposed by you will be better/worse etc. Imho comparisons are always nice. I would also mention what are the downsides (at least currently) for proposed solutions (e.g. web components are not SEO friendly at the moment). Google crawlers will probably index such pages properly as those execute JS, but there are many more crawlers around the web :) There are also some topics still to be addressed (e.g. app state management). I hope you find any of those thoughts helpful :D