2e:null 2f:["$","title",null,{"children":"Adventures in Architecture | Jakub Hampl | Observable"}] 34:T469,notes.above` I wrote an article with a bunch of my research at the time, coming up with various ways to enhance our Elm stack to make it scale much better. In this blog post, I explored different ways to make or enhance the Elm architecture to make it easier for people to use. Currently, the Elm architecture design makes it easy for web developers to use, but our target audience is people who are not web developers. These are backend developers who may not have much experience with web development, as well as computational engineering teams who may have never done anything related to the web. After writing this blog post, I started putting various parts of that initial set of ideas into practice in detail. This talk explores some of those things that I did, how it went, and how I improved them. I'll go into a bit of detail about how this stuff works, but the plan is that if you find this kind of content interesting, I might do follow-ups. These follow-ups will be more technical deep dives on some of these topics. This talk is more meant to be an introduction to some more advanced Elm architectural patterns. `35:T7b2,notes.below` I wanted to create something similar to Elm UI, but I wanted to be more restricted because at that point, I had a talented team of designers who spent a while on the built-in design system. I wanted the Elm types to enforce the various invariants of the design system. For example, our design system is built on an eight-pixel grid, which means that every single thing should be at least eight pixels big. Margins, paddings, spacing, vertical rhythm, all of this is based on this eight-pixel grid. Therefore, I made things like padding only be able to accept things like small, medium, large, and extra-large. These would all translate into fixed padding sizes that were all multiples of this eight-pixel sizing. But in other places where you can specify actual widths of elements, those widths are accepted as an integer number of units. Each layout unit is exactly a pixel, and in normal resolution, they are compiled into rem to support accessible zooming. This approach enforces our design system, which has proven extremely successful for us. The same goes for colors. There's no way to express arbitrary colors. There are named colors for stuff, and there's a distinction between surfaces and elements, and all of that is built in. This has proven extremely successful for us, both from the fact that we've had people who have never done any sort of front-end engineering build quite nice-looking UIs just because we made it quite difficult to mess this up. As our arrivals started up and pivoted through various pivots, we've had to change the actual look and feel of the UI about three times at this point. Any other technology would have been an absolute nightmare, but here, some of the redesigns were really easy, and some took a while, but none of them were horror shows of broken apps. We've had very few bugs with complete redesigns. The intent was to create a system that was easy to use for our target audience, and it has been successful.`36:T5cc,notes.below`In Elm, the view function maps the model to HTML. Functions are immediately composable, allowing developers to extract new functions with ease, making it easy to move code around. However, in some cases, this composability does not quite work. For example, when web APIs require IDs such as \`\` or \`aria-labeledby\`, SVGs need IDs for text on path, gradients, patterns, etc, this doesn't compose well since IDs need to be globally unique and the developer must worry about this when attempting to reuse code. The two-pass rendering approach fixes this by turning views into functions that accept a unique string as an input. During the two-pass rendering, a unique ID is computed for each branch of the tree and passed down to the functions. This allows developers to freely and happily compose those functions. The other issue with rendering on screens is when it depends on the amount of space available. Responsive design is one aspect of this, but it is more important when rendering SVG diagrams. The solution is to keep a subscription for the resize event, which passes down the available width to the rendering pass. For each child, the available space gets allocated. There are other benefits of two-pass rendering. The context pattern can potentially pass in other global and cross-cutting concerns, such as the locale for localization or theme. We also use it to pass in msg types that are handled by the runtime, such as things like user tracking. `37:[{"id":"ded738e0ff9e50f8fda80b5b368d8522d428489fbec777841f18f408c5e9e60d61c58f598262339f9e6af589bdcafc34222be2d58b0a8212fda1e9806a21cf9a","href":"https://static.observableusercontent.com/files/ded738e0ff9e50f8fda80b5b368d8522d428489fbec777841f18f408c5e9e60d61c58f598262339f9e6af589bdcafc34222be2d58b0a8212fda1e9806a21cf9a","name":"Screenshot 2023-04-05 at 16.09.25.png","type":"image/png","lastModified":1680707419306.034,"size":299909},{"id":"1bcbd13925f74b40fd55599dba44945f20b602fb7857e680e6c1e1d8674c2f56f8d5ffa5c9eaa9533c815f7305b94a599d05b7d62046f5945dfd9fea9989d5e5","href":"https://static.observableusercontent.com/files/1bcbd13925f74b40fd55599dba44945f20b602fb7857e680e6c1e1d8674c2f56f8d5ffa5c9eaa9533c815f7305b94a599d05b7d62046f5945dfd9fea9989d5e5","name":"Screenshot 2023-04-05 at 16@1.09.25.png","type":"image/png","lastModified":1680708450224.786,"size":377278},{"id":"ba506ad979984f520d7b907336a0872dc1796d1a09c9733c47c0acdf7c8703678dcdde8ead57b3fe755fb04da32d51be65ebb9d0f4eae52b777943a5556f0ba1","href":"https://static.observableusercontent.com/files/ba506ad979984f520d7b907336a0872dc1796d1a09c9733c47c0acdf7c8703678dcdde8ead57b3fe755fb04da32d51be65ebb9d0f4eae52b777943a5556f0ba1","name":"Screenshot 2023-04-25 at 16.52.47.png","type":"image/png","lastModified":1682438002595.616,"size":160912},{"id":"c2035d7efdec7db388c87e6c8917466a306ba10d924ce837d6e4a8ef2a19fc8527ff534e0cb847a5370c1cbcd76862c472ae1f8322580b5aa2571e39cef66ce4","href":"https://static.observableusercontent.com/files/c2035d7efdec7db388c87e6c8917466a306ba10d924ce837d6e4a8ef2a19fc8527ff534e0cb847a5370c1cbcd76862c472ae1f8322580b5aa2571e39cef66ce4","name":"4f475c73-4421-40b3-9cd0-39b9be5bc19d-3840-1536-desktop-1-04d388eb-c30e-445b-b8f6-3c070ce26d32_24a0b362-cbbe-446a-a1a2-4719ea46c2d6_Frame_1_1.jpeg","type":"image/jpeg","lastModified":1680774038458.558,"size":560263}] 32:{"id":"c9513600ca0ef20b","slug":"adventures-in-architecture","title":"Adventures in Architecture","thumbnail":"2182556cfa50fc945ce563ef00c882f565a5fb5c7cf7c5f391c68fda17219536","access_level":"public","create_time":"$D2023-04-05T15:06:20.076Z","update_time":"$D2023-04-26T15:42:44.941Z","view_time":null,"first_public_time":"$D2023-04-05T15:06:20.076Z","has_unpublished_edits":null,"fork":false,"stars":0,"starred":false,"owner":{"type":"team","id":"a2f700b6ce27b844","login":"gampleman","name":"Jakub Hampl","avatar_url":"https://avatars-next.observableusercontent.com/6ee048ed02abfd79e76f2f9dd7c7e8658c47b116d846f2f9ca8814ecdde18ffc","tier":"starter_2024"},"version":361,"publish_version":null,"role":null,"authored":false,"authors":[{"type":"individual","id":"34d15c3b1cc754ed","login":"gampleman","name":"Jakub Hampl","avatar_url":"https://avatars-next.observableusercontent.com/6ee048ed02abfd79e76f2f9dd7c7e8658c47b116d846f2f9ca8814ecdde18ffc","tier":null}],"members":[{"type":"individual","id":"34d15c3b1cc754ed","login":"gampleman","name":"Jakub Hampl","avatar_url":"https://avatars-next.observableusercontent.com/6ee048ed02abfd79e76f2f9dd7c7e8658c47b116d846f2f9ca8814ecdde18ffc","tier":null,"role":"editor"}],"comments":[],"custom_thumbnail":false,"trashed":false,"lapsed":null,"subscribed":null,"forks":0,"collection":null,"type":"notebook","body":{"title":"Adventures in Architecture","cells":[{"id":9,"value":"slide`# Adventures in Architecture\n\nJakub Hampl \n@gampleman\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":15,"value":"slideshowControls","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":95,"value":"slide.img(\n FileAttachment(\n \"4f475c73-4421-40b3-9cd0-39b9be5bc19d-3840-1536-desktop-1-04d388eb-c30e-445b-b8f6-3c070ce26d32_24a0b362-cbbe-446a-a1a2-4719ea46c2d6_Frame_1_1.jpeg\"\n ),\n { scale: \"cover\" }\n)","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":78,"value":"notes.below`\nAbout 2 years ago I started working at a company called [Arrival](https://arrival.com), which is an EV company with a radical new way of manufacturing vehicles. We had a very strong Elm team and a very ambitious mission.\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":22,"value":"slide`\n## Goal: 50 apps a year\n\n- Everyone able to contribute\n- Super reliable\n- Large scale upgrades\n\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":84,"value":"notes.below`The team I was on needed to ship an amazing amount of internal tooling to support the incredibly complex process that is designing a new vehicle. Soon after I arrived, I realised that my boss had the vision of shipping and supporting 50 new apps a year.\n\nNow at the time, the team had about 5 front-end engineers. It was fairly clear that we'd need to invest in making stuff far more efficient. Thinking about it a bit more, I realized that we needed to radically expand the number of people who could create these apps, that these apps should be very reliable so time wouldn't be wasted on debugging and maintaining them and finally that the front-end team should have the abillity to ship large scale code changes without necessarily needing to understand any particular application. `","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":138,"value":"notes.above`\nSo I analyzed our current stack to find out what is working well and what isn't.\n\nThanfully the team had already chosen Elm by the time I joined, but some of the other parts of the stack weren't\nso good. Particularly CSS is not a friendly part of the web stack.\n`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":120,"value":"slide`\n| | Elm | PCSS | Html | TS CE\n|----------------------|-----|------|---- |-----\n| Everyone contributes | ✅ | ❌ | ✅ | 🟡\n| Super reliable | ✅ | ❌ | 🟡 | ❌ \n| Large scale upgrades | 🟡 | ❌ | ❌ | ❌ \n\n","pinned":false,"hidden":false,"mode":"html","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"}],"files":"$W37","stdlib":"1","titling":"auto"}} 33:"$32:body"