Composable without Compromise w/ Jonas Ulrich

[Music] foreign [Music] [Music] thank you hello everybody we are live and with us is Jonas and so um this is composable without compromise and composable can mean a whole bunch of different things and will likely see a slightly different direction that we have sometimes seen with what we think of compostable or maybe not this is why this is so much fun so Jonas would you mind telling us who you are where you work what you do all that fun stuff yeah for sure so I I try to keep it short but uh succinct so basically I've started working with HTML into the web in school so in I think 10th class in Germany it is so I'm based in Germany we had some first courses where you could opt to learn about stuff like that and I found that super interesting and pretty much been fixed to that since so I've moved to another city for my studies so I've studied computer science in Bonn the former capital of Germany where I've also met great people and I think pretty much after a year we already founded our first company with colleagues from the studies so wow that was the nucleus I'd say of everything we're doing today because we're pretty much in that lineage State between an agency for the longest time so I think until two or three years ago we were still working on an agency business doing PHP based development a whole lot of front-end development tool that was always part of our DNA to have really great quality front and in combination with those CMS and back-end systems so that was what we started with and then we've gradually realized that this is not really getting better for us nobody actually wants to pay for the kind of work we were doing when doing quality work because you want to have fast results you want to have efficient and most of all cheap results in our space at least for the longest time was our impression so we've thought hard about what could we do what is our real expertise where is our real passion and that's the front end always has been the front end and we've done some big projects for German clients building such systems for telecalls and stuff so it was natural to us to really have a look at our own component Library what we've called it back then a component library in Paton lab that we've repurposed in all our client projects and how we could make that more accessible for others too because building and design system is a huge upfront investment um yeah exactly not everybody can show that and not everybody has the specialist knowledge to do that so that's why we've switched to that model I think two years ago pretty much by building a product an open source data kit for Design Systems that you can use to build out your own design system and hopefully have those effects without investing those years of developing time and exact knowledge and finding the people and so on so I think that's the pretty gist of it and so Kickstart DS is essentially the company that you started to get this design system out there with all its components and stuff all right cool yeah it's I mean to be to be fair it's a brand of our agencies so we still have the agency in the back so we're still doing some consultancy work especially in that context of Design Systems we're helping people build our design systems based on Kickstart yes so all of that is still in the background there in that agency business but the brand Kickstarter s is really 100 focus on the design system part and the open source stuff on GitHub and so on so okay great and that actually works pretty well for this stream because you are actually still doing work for customers specific to how they want to work and also have you have this product that is basically a composable design system right and so um generally in those this stream where we do composable without compromise we have a bunch of the same questions and we want to see what different people in this space like you or someone else actually has to say on these questions in their context so I'm just going to shoot with the first one um so what is an unexpected or surprising outcome of transitioning from a monolithic to a composable architecture I think that's a really interesting question because I think you have to ask yourself why do I transition that should be the first thing because there's always a reason to transition you're not hopefully you're not doing it just because or says just because you've read about it online and you think it's the next big thing though so I should be part of it you should have a reason to transition and I mean those reasons often carry the the unexpected or surprising Parts like maybe you're changing your team structure for that going from a monolith to a more composable architecture you maybe have more teams that are working for themselves which is great for them because it really empowers them but it's harder to have a broader overview of your software or your services that you offer when you have those distinct teams and not the top-down view of a monolith that is one I mean it's hard to call it the positive because monitors have really big problems in my view but it is one positive that you can have the overview over everything even if you don't understand it you at least see where everything sits and behaves right and so when you were working with your agency and you onboarded people into this new way of thinking was there anything that surprised you either from what they had to say about it or what came out or what surprised you about yourself that you maybe even liked monolith sometimes do you have anything there I think the most surprising thing was how varied the reaction to all those ideas was and it totally depends on the Orcs process on the specific people you're talking to sometimes you have someone really opinionated that's totally set in how he does everything and you won't have a good time convincing him if it's for example a technical argument so that can be really surprising or maybe you think you're talking to the correct people but in the end you're talking to the marketing department and not to the real engineering department so everything you're doing is kind of in a vacuum so I think realizing those structures can be really important and it's often surprising that when you when you realize who the real Gatekeepers in an organization are when it comes to those types of decisions and how they are driven because they can be really political and you can have pushback because changing something often means taking something away from someone changing someone's responsibilities or his freedom of choice and that is always something which will have friction I think and that can be really surprising but it's not that easy just because it's a good idea you won't run into open doors necessarily exactly I always love how people like you and I that have been doing this with this kind of stuff for a long long time that we kind of just go in and say this speaks for itself right let's just do it and then you might be surprised by the pushback because it probably doesn't speak for itself it might not be as easy as we see it because we've just done it for a long time and I mean you just have to communicate with people it's not that it's not possible to win those people over you just have to speak to them on their eye levels so then you can really see what are the advantages that they see in their way of doing it why do they resist this and this can be really really helpful to understand your organization too and your processes exactly and so I know that we have our friend buba in the Stream and he also works as an agency and this is basically his daily life so that makes it really interesting to see if anyone that is watching here has some questions feel free to also add these and so with all this in mind right speaking to either other companies or people you work with like do you have um something you might want to say to people in that space that either work maybe at an agency or at a SAS company building this kind of stuff and maybe in your context even like people who are are in charge at a customer for example you know I mean one thing coming from our perspective which might be obvious is have a look at how it integrates with your front-end workflows how does all this composability work out for your needs when it comes to creating web pages apps and so on which capacities do you have in your developers can they do react a lot of companies don't have developers that can do for example reactive UJS or angular so they are pretty set in the current Technologies and they can't just change from one day to the other so I'd say have a real hard look at the Technologies involved at the stakeholders involved and see if it matches because when it matches it can be really deliberating and really unlock production and capacity and efficiency for you and your teams if you're using those specific advantages that the composite architecture brings to the table I think and so when you let's take a slight side track here because let's say you have a design system that's of course has all the rules about how things work design wise couldn't you just make those HTML Snippets that somehow people just could put in their ancient old-school systems would that also work yeah I mean and actually that is a way that we when we're talking about Kickstarter is totally support of the Box because everything in the end from our perspective still is just HTML and we've never changed that view of how the web works so react for us always was just a replacement for handlebars what we've used before so a functional templating layer it's not meant to do anything for us then giving us great templating capabilities to get that composability because I had to say it's really hard to compose Your Design system from different sources when you're talking about buying five components on that Marketplace then mixing them with your custom components and then just adding some open source components I don't think that will ever work when you're when you're concerned about consistency and performance and all of that stuff so you will have one design system at least that's our view so that's not a lot of composability between different systems in that sense but every good design system is composable in itself that's one of the main pillars of a design system to have composer with components that can be remixed for all your different needs that serve as a base for rapid prototyping for production stuff and so on so that should be super composable and in that sense it's also really compatible with composable architectures in the back because if you have that that divide between front and then back end you can really have an opinionated front and the Really structured front end without having some dependency on the back end or having to talk to people about this exactly and you can even make multiple front-end Channels with the same systems and then theme them up for example if you set it up correctly you should and that would be one thing I I also advise when you as an agency or even as an sas company look at this to have an open eye for the new stuff that's unlocked by those composable architectures it's not a one-to-one replacement you have different complexities different pros and cons but there are definite Pros that can enable great experiences when going that road we just built one such app for a client that enables him to build his own e-commerce Journeys completely from start to finish in different tenant designs you can white label it so it's really enabling a lot of different stakeholders for them because it's thought from the beginning to be composable to remix all those systems in that sector of industry and make it approachable in a low code fashion even a no code fashion the page builder Drag and Drop Like wave two stakeholders of their company because it's composable and it's super liberating for them so without noticing it you you just pitched uniform so thank you for that that project really really reminded me of uniform too I think I spoke with Hunter before and I've mentioned it to him too that I see a lot of similarities in that approach just that you have to solve it way more generally exactly we are very agnostic to whatever right our components are more data driven in that sense but you can still connect your design system to components in uniform and drag and drop with them and that still works so it's it this kind of stuff fits well and oh let's see there's a comment ah Uber agrees well that's nice to hear anyway so let's say um if you could wave a magic wand and change anything in our current space from front end to architectures to people working what would it be or maybe nothing because it's all fun I mean I think it is all fun but that doesn't mean you don't have stuff you want to change and if you have no change I don't think it will keep being fun so you should have new stuff so I think there's two things really I'm thinking about that I would like to change one more nerdy thing and one more generous thing I really care about because I think we need more standardization in the front-end space and more collaboration not that many silos where everything is redone every project so at least to me it's really tiring to see how much effort is put into front and to get the 200th version of an hero image that's not accessible that doesn't had the right checks when being developed because there's just no time to do it and it's just the last thing that's done in a project I think that's really something I'd like to see change and I think before it can change you have to have some way of standardization create stuff for the back end did really great stuff for the back end yeah in normalizing how you can work with the stuff in the neighbor it's a lot of stuff that you see in the composable Headless space today is I think enabled by apis I mean rest was before that and the neighbors much of the same stuff if you wanted to but graphql just makes it way easier to interface with those things and I think that's a bit lacking on the front end there's not much there yeah that's um a lovely one we haven't heard that one but that's awesome I'm not sure this will ever happen because front-end developers will never agree on anything I'm afraid you know what funnily enough in the end it all comes down to some you output HTML that looks a certain way and so you should somehow find some sort of standard but it is a challenge but you're right it's my magic nerdy pick would be just so that a tool that you can use to map arbitrary Json objects Maybe by a spec by a schema but that would enable a lot of that flexibility that you have in the graphql space already where you can just take your component you already have your component when you're doing your drop right you've thought about your component beforehand you know which information should be displayed which interactions there should be that is nothing that's related to your backend systems to your choice there so you should be opinionated from the start when at least following our way of doing it so you would be just mapping that and if you had a tool that just would allow you to have all those fields and just connect them into your component and I think that's something uniform please I know I know the component starter pack I think really goes into that direction and it's really interesting for us too because that enables that way of working with your design system with your components without losing all the possible benefits of using the design system the consistency the performance aspects the efficiency in getting features from from production to production I mean all this benefits from something like that and I think we did a prototype early on that's really similar to the components data back with you guys too which already showed how nice that could be so yeah because we are actually using stuff like Json schema to validate all the data that comes in and what we do in uniform now is where you can select all these different data sources and map whatever comes out of them each field that you want to a property of your component and so you're almost curating your own graphql API yeah that's great and it outputs is Json and that's a very interesting thing when you map that to a Json schema so it's always relatively clean and we're working on having being able to actually even type that and so then they get very strong I can quickly pitch Kickstart yes again here because that's just what we are doing too we're just using Json schema and I'd say if someone would ask me what's special about what we're doing I'd say there's nothing nothing special about it we're trying to not be special it should just be best practice we're just doing stuff like you should do it it shouldn't be surprising the surprising aspect might be that we always start by defining component structure and that's exactly done in Json schema to really have those thoughts beforehand before drawing something in figma you should talk to your editors what do you need exactly what do you actually need to display content on your website because if a designer thinks that up and then it goes through to a developer and he adds his own interpretation and then at the end just at the end when everything's too late it gets into the editor's hands he will not be happy when it's not enabling really enabling him cases how does that look like there's so much stuff there that you need to think about so this is actually a lovely bridge to our next question like have you seen any sort of bottlenecks in this whole composable architecture like it could even be it could be technical or it could be like process related or maybe people just don't get it like what have you seen as as a bottleneck in this whole new thing yeah I mean I think I fainted at it before I think Staffing and knowledge transfer inside your own organization are really huge bottlenecks because it's not that easy for developers to transition those roles necessarily some do it without problems others are really set into their ways of doing things and they don't want to change and moving to such an architecture almost certainly means changing stuff learning new stuff and you have to have fun with that if you don't have fun with that you'll have a really hard time I think so I think that's a really big bottleneck that you have to have the real talent in New York and it almost to me feels like doing composable either in your front end but also as architectures on a whole there the the how do you call this I'm losing my English words it's like you have to go over a line to actually get there so there's more upfront thinking ownership taking it more into the customers hands themselves that they own it more and so they have to learn more and then after they have learned all the things then it's smooth sailing but I mean that's one of our main pitches too that you have to enable the orc to do the work that's yes great value in having an agency that can do do parts of that but it has to be owned by the org especially when you're talking about Design Systems it's something we're never getting tired of mentioning you have to own it yourself you have to know what you want to do with this you have to know the action plan you have to know the arguments when people ask you why should we continue building this design system and this is really important I think so exactly and luckily I have recently seen maybe the last year in a bit that a lot of people that were at agencies that understand the stuff we're talking about are all moving to Brands and they're quite senior and they're taking ownership of the product at a brand on that level and they can help you with a team buy-in and I think when you talk about composable architectures from the front-end things so even the other stuff like how do CMS connect together with something like uniform it is a team buy yeah and everybody needs to be there and that that on its own could be a bottleneck if people have different agendas yeah and I mean often those are not the organizational structures you will find in those companies so you will have the people gatekeeping stuff and so on so it's really a challenge to get all the right people to the table which is just the start exactly and this is also why we love using agencies to help out with a sale because they also know what works and they can help with pitches and stuff and so what stuff that was there as a feature in like a super old attack would you like to bring back if any I think there's something to be said about some classic front-end engineering shops um stuff like naming stuff block element modifier as an example to approaching your semantics when creating markup vanilla JavaScript it's really impressive what you can do today with just JavaScript itself when you're using ecoscript 6 and so on um I think there is something lost inside the transition to single Page Apps and front-end Frame Works if it's react vue.js angular doesn't matter it's just a different beast and you're just a tad more removed from the real output in the end and I don't think it's always a good thing so for me personally I'm just not a big fan for example of CSS and JS I really like authoring my CSS for myself I like reusing thus for that and finding really purpose-fit abstractions for what I'm building because that should be really long lasting so it's worth the effort it's worth it to think about naming it to think about semantics it's not wasted time in my eyes you can really debate about this I think for hours at a time with people um I think we might be dating ourselves because I think exactly like you I come from the world where we didn't have a jQuery or something like that it all came later and we just had to know all the tricks and with that game good semantics and accessibility and um there was years where we just did everything with vanilla JavaScript and it worked pretty well but you have to understand everything and all the browser references so in my brain there's a lot of CSS hacks that worked in ie6 that I don't need anymore but they're still here yeah yeah right and so the only difference is like right now if you are younger and you're starting with your whole journey um you kind of don't have to know all the things and you still have success so like it's almost ambiguous now with with whatever framework you use from next to next to svelt kit performance is almost no longer an issue because they have such good defaults but if there's a bug and you haven't done that before you cannot find it you have to start diving into packages that you don't get so there's pros and cons here I guess uh one other thing I really miss are self-owned communities use our own communities I've Loved going through phbb forums through IRC servers way back when and I think there's something lost there too in those specialized communities those really growing communities there are some out there but I don't think it's the same you can go to Reddit but it's more sanitized I think and not that it lacks character I think do we still have characters out there does that still really exist I think that's specialist stuff yeah I know of my co-founder he's really into to watch his wrist watches and that's yeah I think one of those topics that's still mainly done in forums so oh really I think they are out there but I have not encountered them the last years and maybe it's just all in Discord now I don't like that either because it's also centralized and also pressed into that Discord format it's not yes I'm missing the self-expression you had on the web in the past I think there is a lot less self-expression today all right thank you for that um I love the the insights that you have that are so similar to mine actually doesn't always happen that's cool okay so this is the last question that we generally have in this round and let's see if there's other stuff we could talk about but sure how would you explain composable architectures to um normally ask to let's say your grandma but now I'm going to ask to a 15 year old that supposed to be kind of digitally native right they when they were born they used the mouse and a phone already so how would you explain composable architectures to them I think it's really hard because it's so complex that most analogies break down pretty early I think but I I probably try it with an allergy nonetheless so something like when you're thinking of classroom assignments or stuff like that and maybe you compare the teacher assigning you all the class one big task to create something and everybody has its own subtasks already defined so you're just working down a list and in the end everything comes together and you have a great presentation with your class that would be I'd say monolithic in approach so you have one person designing the thing coordinating the thing and a lot of people just working alongside that plan and I'd say composable is more like having some maybe self-organized subgroups and more of a general task and then you're self-organize so you have some small groups working on certain parts of it you have maybe some techie guys in your class that like to approach one thing that they can do really good job at for example you have maybe you have a show that you're starting and they can do the lighting they do a really great light show because they really get into the topic and this only gets enabled by having that composable structure by having those specialized teams and I'd say that would be maybe a way to get to the differences between something monolithic and something composable because in the composable part you're still also in your class would need someone to coordinate this so how does that work and I think that would get someone even if you're 15 years old to think about exactly the challenges that we've talked about in this before and the questions before I think yeah and I tend to explain it and that was one of our first guests that came up with that it's like remember when you bought a mobile phone like a Nokia or something it was just one OS you cannot you cannot really personalize it other than some colors maybe now when you have a phone like this it comes with something you know but you have all these if I open it you see all these little icons right and they're all the apps that I have chosen and you can just set it up the way you want to but these apps on their own are defined by people that are very smart and they just work yeah and so you can reuse apps in different places you can set it up yourself and so it's almost like the owner of the device gets to choose how to use it but the tools that they use the DNA building blocks are actually properly built and even there you have quite an ecosystem backing or that and making it possible and usable for you because you'd be quite dissatisfied if the share dialogue wouldn't work the same for all those apps or exactly intense the correct app wouldn't open so there's still some connective tissue behind that's yes making all that work and I think that's also just to get back to uh promoting uniform again but where you would see uniform positioned so you're pretty much the operating system behind such a thing making it possible to have composable stuff that works great in conjunction so and I think this is a lovely bridge to some other stuff that I want to talk to you about because you are relatively technical you know how these front-end components work and you also know that if you have these components you have to fill them up with data somehow and we're talking about this connectific disconnected tissue kind of thing right so you still have to do something and we almost like to say we're the bookshelf and you put the books on but somehow you need to know where to place one book and so what a lot of systems have if you don't have something like uniform you need to somehow code to write connections to other places you have to resolve URLs and all these things and then map that data so they fit to your components and so we like to call that glue code yeah right and so if you didn't know uniform how would you actually solve this glue code thing if you were now an agency and you had a project with six sources with different places and it all had to fit into your component Kickstart DS system how would you solve that I mean it's just manual labor to be honest when you have want to have a really purpose-fit solution you just do it all by hand right please resolve us get all those data stuff out of there probably use some something like next JS or another similar framework to have the base set up in place but in theory you would have to code everything yourself so you would write the components you connect up the data sources but it's everything is done by coder and that's in our experience also one of the big because we've talked about this before bottlenecks that you see is when everything has to go through one team or one deployment process or one QA equality Assurance phase then it gets really slow and it gets really hard for people to innovate and yeah I think that's one part where you can really make a difference with with those structures yeah because you can then ask the question let's say you have let's say you have a hero Banner with an image a title and a subtitle maybe a button if a Content editor says can I use that component with a different set of data in the in that case you actually have to make a ticket in for the developers that actually then say yeah but I don't have time to to add a new data source for you I mean I've talked about that project before I think with this composable e-commerce stuff um and there this was the reason for them to do that project because they had that bottleneck they couldn't deliver they have enough customers on their Solution on their white label solution but they weren't just quick enough to deliver features to those clients and those clients were not flexible enough inside their own systems when they wanted to be custom when they wanted to personalize something they were running into really hard edges so that was the whole reason to think about something more composable how to break all those barriers and rearrange everything so it gets gets to the stakeholder himself in the end yeah and what I like to see is to have a lot less of that code where you would actually move all that choosing which code or which data which content goes to which place that should actually happen in that connected connective tissue right and that's how in the end we came up with what we do with uniform is where you can literally just select any data resource to a composition or to a component and you just find whatever title you want you put it on the prop and you hit save and that comes out and that's the only thing and you don't actually have to query that at all yeah I mean I think that's super smart it's a good way a lot of people say yeah but then you duplicate content and you put stuff on servers and you have to do caching but in the end now that we have Edge rendering and all that stuff it's not that hard anymore it's actually very interesting to see where we use the CDN Edge to store that little bit of data that you have selected yourself that your own curation essentially and then you can for each of those data sources you can just set a TTL let's say 30 seconds 10 minutes whatever you want or you can set up a web hook so when somebody publishes that CMS item a web Hook is fired and uniforms removes that little chunk from The Edge and then when you re-render you don't have to do like aesthetically generated site anymore it can be actually Dynamic that is just cached for a certain amount of time and then looking at the CDN Edge and we've had demos where you had like 15 cms's and search engines and whatever 30 millisecond page load 50 milliseconds and it's a very interesting approach now that we have this whole Edge thing going on and so before this would have been a bottleneck because you would have to pay for servers to be up and do all the crazy stuff no longer needed and so that makes things much easier and you do still need that tiny tiny bit of code because this is how would you solve that like imagine you have a data source and you select a date a title and description but that date is formatted in American and you need to you need to have it in German so you still need to do some sort of coding bit that's the only that's the I mean you should ask me I'd say you probably if you're a business that cares about multi-time Zone stuff you'd probably want to have that built into your component itself so if you're displaying your date you probably want to have that responsibility relegated to the component to either have a switch where you can just set which format you will want to render or by having it choose automatically based on browser or something like that but in the end the data should be pure data so you have a timestamp behind that exactly so it wouldn't be a regional date that you're saving somewhere that you're entering somewhere but it would be the time zone not time bone specific what happens if that let's say is a little card component right from your design system and sometimes it's a date and sometimes it says get discount now then suddenly that doesn't fit anymore because you don't want to have date logic in your component I guess yeah and I I would say if you have something that's either get a discount or the date I don't think you've done a good job creating your component because oh here we go what things you should mix you should have two properties for that and yeah to to explain a bit our approach to creating components because it can be Illustrated for that because we did the starter kit for Design Systems and it could be paradoxical to have such a thing even because every page wants to be custom you want to have your solution and we Advocate that too so we just have some components for you with lots of properties already which you can choose from but you wouldn't ever use all those properties for example when building your Hero version of our visual component you only pick the three or four you actually need and you maybe even reduce the options we maybe have two variants you only need one variant so you just use that variant and in that process you find your own component definition your component API and that in turn defines which fields which slots your components have to connect to those back-end systems which is why I think this is a really natural fit if you're thinking about your design system in that way structuring your components by information displayed by interactions possibly and have a strong definition for that it gets really easy to convert that to different systems in other projects we use Gatsby for example because if asked how we would approach that and there you have resolvers you write so yeah yeah the source plugins essentially yeah we just wrote one big Kickstart DS schema and just resolve all those sources against our own schema which then matches our component apis automatically so to connect a new source you just add the source plugin transform to our Kickstart yes structure and have it ready to go in your page that's not what you're doing that is next level to give it into the hands of the real editor of the real estate project manager whoever it may be but it's already giving a lot more power to the single developer in our case yeah and that I think it's really good that you guys have all these extra props and this really specific language of what fits where because then developers still have ownership of how something looks and works and if you combine that then and put it in something like a dxc that is visual it doesn't matter anymore which sources you add into it they can still facially edit it with the language Your Design system has set so yeah it's um you have those types and you've talked about converting Json schema we're doing just that for example to create typescript types so you always know which properties you actually have you can always leverage that to connect into different systems and I think it's super powerful for in the combination especially this is great man thank you so much um we are nearing the end of our stream today do you have anything else that you might want to share to our lovely viewers today you may be wanna um you know Market something about yourself or otherwise where can people find you yeah I don't think I have something to specific to Market um if you're interested in Design Systems and that's already not everybody probably that's attending this here so if you're interested in that have a look at Kickstart yes maybe because it's really interesting I think and a powerful approach to doing a design system and it's always fast so there's no real investment there to be had to have a look at least um so I'd be really interested about that and if you have questions about Design Systems I think three four weeks ago we've launched this I know this one helper the design system concierge which you can actually ask questions to about Design Systems and get answers like you know from all those GPD plugins out there and what we've done there I think is interesting again because we're just not just generating an answer and having you live with that we actually cite the sources so we carefully select the sources inside a database we curate on our own and those get references context and Rewritten into a nice answer but you always get those sources linked below and it's the expectation that you go into these sources the one most fitting to you just go into there and really take a deep dive that's how it's meant to be that's why we called it the concierge it's not your specialist it's exactly at the front desk in the hotel he doesn't know everything but he's really helpful and he really wants to help you so yeah this one I I looked at this this is a super fun way of using AI but then have it not hallucinate too much yeah so that was that's awesome to see um thank you very much Jonas this is always fun um to have a chat and I think it's time for me to re-dive into Kickstart DS because it's been a while and just it's so much fun to do see how this composable stuff can work so um thank you very much everybody for watching and I'll see you next time cheers bye bye I never