Full transcription below the show notes
We talked primarily about https://hyva.io/
Some other links we mentioned along the way:
Jisse: Hi, everyone. Thanks for tuning into the registry number four. Oh, and I made a little bit of mistake actually while starting because we were supposed to start in Dutch. So my accent is going to be very, very Dutchy.
Peter Jaap: Very Dutchy?
Jisse: Very Dutchy. And Peter Jaap?
Peter Jaap: Hello
Jisse: Hello. And Willem Wigman.
Peter Jaap: Willem Wigman.
Jisse: Yeah. So The Registry, the podcast number four. And I had to ask Peter Jaap before we started, because I simply lost track. It feels like we have been talking about nonsense for ages already.
Peter Jaap: It is only four? I thought it was 14.
Jisse: 42, yeah.
Peter Jaap: 42
Jisse: But yeah, so the format is a little bit different. Instead of boring all of the listeners with two Dutch guys talking, we thought we can do better. So there are three Dutch guys. One from the middle of the Netherlands, so that's me. One from the North, that's Peter Jaap, and one from the South, that's Willem. So hi, Willem.
Peter Jaap: The deep South.
Jisse: Yeah, that’s the accent.
Willem: Yeah. I come from the warm place in the Netherlands.
Peter Jaap: That's why you're the only one without a sweater. I get it now.
Jisse: Yeah. So in the South, it's about 0.01 degrees warmer. So indeed, it’s quite a difference.
Willem: Yeah, climate--
Jisse: So thank you, Willem, for joining us.
Willem: Thanks for having me.
Jisse: Yeah, we came to this conclusion that it might be nice actually, to have you talk a little bit about the new thing that you've created. And I think a lot of the listeners will know about it but yeah, there was actually almost no attention for it during ReactorCon, and nobody asked you to do any kind of podcast or interview ever since. So actually, from the community, it was just dead silence. And we felt it was time for a change, right?
Willem: Yeah, I would like some change as well. That's been kind of the headline of what we've been doing. Yeah, and certainly not enough attention.
Jisse: Yeah. And so the obvious start always is with what it's called. So the name is Hyfa, hoofa, hufter… So what is the real pronunciation? Here we go.
Jisse: And that's Swedish?
Willem: It’s Finnish.
Jisse: It’s Finnish.
Willem: Finnish, yeah.
Jisse: It’s finished.
Willem: It’s Finnish, yeah. People are going to have a hard time recognizing where it's sarcasm and where we're being serious. They're used to it from you but maybe from me, it's new. But to say the first serious thing here, Hyva is Finnish, and it means good, desirable, and trustworthy. So it has a lot of positive meanings and Finnish.
Jisse: Yeah. And I think in general, do we want to make sure that people get the memo? Could you maybe describe Hyva in a few sentences?
Willem: Yeah, sure. So as a lot of listeners might well be aware of Magento 2 front end has been kind of an issue since Magento 2.0. Arguably, before, a little bit as well, but especially since Magento 2.0. The whole knockouts require jazz front end has been a pain to work with. It has become a bigger and bigger problem to have it performant and score well in Google. And it's just as a developer, it's no fun at all to work with. Magento has decided that the solution for this is not to fix the front end but to replace it. That's PWA Studio and headless. So there's a lot of PWA solutions now that will replace the old Magento 2 front ends but none of those solutions really suited me and I guess I can say the agency Integer_net where I work.
Willem: Yeah, so we're trying to leverage the capabilities of modern browsers as much as possible. And a modern browser is perfectly capable of, as an example, to do form validation. We don't need 500 kilobytes of library to do form validations because your browser is perfectly capable of doing this. It's just a lot of developers don't really realize this because we've been depending on libraries for so long since jQuery was released years and years ago. We kind of went to the developer approach, where we use a library that serves multiple browsers and fills the gaps of capabilities that those browsers have. So we use a library because then it also works with Internet Explorer. That's how we used to do it. And now we're still used to using libraries for all the little features that we need. And in most of the cases, we don't need these libraries anymore.
Jisse: Well, I think on top of it, what you say is actually that with React and Vue, as soon as you deal with that single page application strategy, sooner or later, you need to make it SEO compatible as well. And then suddenly, you need to think about server-side rendering and then you're opening up the box of Pandora in the complexities of everything. So actually at the beginning of this year, I was at a Vue Amsterdam conference, and I kind of sneakily interviewed a lot of different attendees to see how many of those Vue developers played around with server-side rendering. And then actually, most of them didn't. And actually, those people that didn't never did something with e-commerce either. And actually, those people that had experience with server-side rendering dealt with e-commerce, but then were less enthusiastic about the same area as well. So maybe we've been looking at PWA for the wrong reasons as well. And that's why it's so refreshing that a Dutch guy stands up and says, “Hey, we can do it different.”
Willem: Yeah, so--
Peter Jaap: This is what happens when you use a tool that's built for a specific purpose and tried to force it into a general-purpose area, where you just put on layers and layers of exceptions. “Oh, yeah, it was originally built for this but now we also want it to do this. Or then we add this” and then complexity, complexity, complexity adds, and then you're stuck with this monster.
Willem: If Magento is famous for one thing, I guess it's choosing the wrong tools to do a job.
Peter Jaap: They initially thought that less is more, but it turns out Sass is more.
Willem: Sassy. Yeah, and that’s--
Jisse: To be honest, I would like to nuance that a little bit because if we're dealing with Composer, Composer is perfectly fine. If we’re dealing with the PSR standards, they push the code into the right direction.
Peter Jaap: Those aren’t really choices.
Willem: Okay, so let me then rephrase that. They are famously bad for making decisions in front end tools.
Peter Jaap: Let's dig a little bit deeper on the technical side. How did you actually strip it out and rebuild it?
Jisse: Maybe to jump in, so I think what has been putting off a lot of people to do the same thing in the past is because if you remove, if you reset everything in the XML layout to zero or zero plus containers, then you're stripping out all of the blocks, outputs all of the PHTML templates, and etc. which basically means that you have to redo so many things. Did you find it hard to rewrite everything? Or maybe another sneaky question, does Hyva at this moment support everything?
Willem: No, well, that's an ongoing process, and we are shifting priorities there. And we're selecting things that we really want to have, things that we kind of want to have, and things that we certainly don't want to have. And one of those don'ts is, for example, multiple address shipping. Not a single soul in the world--
Jisse: Who ever used that?
Willem: Yeah. And it's been classically implemented in the worst possible way and no one uses it. And I think even PWA Studio decided that this is one of the features that are not going to make it into the new format. And that's just a few features that we plan to do at a later point, which is, for example, compare products. And I think that's a feature that serves 1% of the market. There are certainly people that want to work with Hyva that will want to have compare products, but that's, I think, a minority, and we will serve them but not with the initial release. What we have right now, we're almost ready to release configurable products. We have samples, downloadables are mostly working, then we move on to grouped products, which won't take long. And then we have bundled products also scheduled to at least do before the end of the year.
Jisse: So you're mentioning a lot of different features, right?
Jisse: Then you're basically mentioning as well that grouped products doesn't need to take that long. So what is long? Is it two hours, 20 hours or 200 hours?
Willem: No, I'm not talking about roadmap release time. And I'm planning to do within hopefully two weeks, a release that contains those features, so different product types that won't include bundles yet, but those are coming after quite soon. We're wrapping up some things in the customer accounts area. We're wrapping up the wish list functionality in the account area.
Willem: Yeah, absolutely. So what took me the most time was just thinking things through. There has gone so many hours into just the process of figuring out what the best way would be, how different elements in the front end would work with each other, and how certain components would interact with each other, and how they would be easily replaceable. And in the foundation, I almost finished the configurable products and that wasn't a superlight task, because I didn't want to fully copy it over from the default Magento because the code is just too complex, in my opinion. So I really took time to simplify the way that works so that hopefully, if a developer reads that code, they actually understand what it's doing so it becomes much easier to expand on it or to modify things. And we're now at a point where a lot of things have settled. The things that are there are solid and won't move around anymore, and building new features goes very fast.
And we have the benefit that we're copying over a lot of stuff from core Magento. We're modifying it, we're improving it, we're making it less complex, but in the basis, we're not reinventing wheels. We're just reinventing simplicity and developer experience. So we're using better tools to redo what's already there. And that's so much easier than when you look at a headless framework where there’s no example how to do things yet, and there's no tight coupling with a back end. Only thing that you have is a GraphQL endpoint, so you have data. And from there, you need to do everything by yourself. And we can look up a lot of things like “How is data being managed? What actions are sent by which form?” and then rebuild that same data flow and those same actions, but prettier and nicer. And that's a very nice process and a very satisfying process. And at this point-- Yeah.
Peter Jaap: The development of Hyva itself is very quick compared to developing PWA Studio I’d imagine. Do you also have any real-life data on implementation times? Do you already have a project at Integer_net that is using Hyva?
Willem: Yeah, so within two weeks, we finish up the project that I demoed at ReactorCon, this is in this B2B shop. There’s a little bit of work there still for the checkout but except for that, that shop is done. Then we have one internal project that we're redoing that was being built with one of the bigger PWA solutions. We spent nearly nine months building that and we decided not to see it through.
Jisse: Could you comment on which kind of certain PWA solution this was? Feel free, come on.
Peter Jaap: Digging up the dirt.
Jisse: So that's VueStorefront. Okay.You convinced me.
Willem: I did not make any comment. So, we have some experience with that particular framework. One project we finished, no one really wanted to touch that project after it went live. So we're going to redo that project as well, that's actually started already. And then the other project we didn't finish, and that customer really wanted to have it finished before the end of the year. And we couldn't sell him data based on the PWA solution, but we could sell it based on Hyva. So we started about six weeks ago, redoing nine months of work with PWA, and we're past the functionalities that we had with the PWA solution. We already surpassed it. And I'm not completely up to date with the timeline but I think that's going to be finished this year as the client wanted.
Peter Jaap: So what's that a man hours? You already had a design, you already had a feature set, you “just” needed to rebuild it.
Willem: Yeah, again, I'm not fully on inside of-- I'm not running the company where I work. I'm not doing project management at the company where I work, so I don't have full insight on how many hours go into that project.
Peter Jaap: Right. You could share one.
Willem: I could look it up but--
Peter Jaap: We're as you already know, at our agency, we're already using Hyva. We’re one of the well, how'd you call it, pilot beta testers, launching partners? So we've implemented the first versions and upgraded ever since you came out with new releases. We also had one project that needed a redesign, that needed a rebuild, that was on SmartWay Portal. We inherited that project. We had never used those portal templates but it's now we know why. So we did a rebuild of that on Hyva with a new design. So this was a new design, some new features, and the rebuild. We're nearly done, and we clocked in around 90 hours on it, man-hours. So that's with two developers. It's within three weeks, we went from SmartWay Portal to Hyva based new design. So that's our using.
Willem: If you put that on a scale of complexity where you normally operate for webshops that you build, is this a low complexity or a high complexity, somewhere in between?
Peter Jaap: It's definitely a low complexity. The recent builds we did, we were based on Snowdog’s Alpaca theme using fractal. That was also a lot quicker than the system we used before. Hyva shares some features with that in the sense that it's still a Magento theme and it's component-based. But we used to move a design from Figma into fractal components or Alpaca components and then move them into a Magento theme, whereas we now skip the component part and then immediately implement them using Tailwind, so the iterative phase is much faster. It's a shorter feedback loop with Tailwind because you don't have to go through all the naming stuff. And we used BEM with Alpaca. Now, obviously, we moved to Tailwind, utility-based CSS. Not having to think up names in the meantime, and having to define the CSS elsewhere is also saving a lot of time. The pages reload a lot faster, so just the whole development flow is a lot nicer. My colleagues are doing this project, I'm taking on a different project where I'm doing a rebuild of React-based PWA solution we implemented a while ago.
Jisse: It shall remain unnamed?
Peter Jaap: Which shall remain unnamed.
Jisse: Are you talking about DEITY? That's DEITY.
Willem: Well, no, you should see that as a one-time fee why you buy the product. And it includes a year of updates, so security updates, Magento updates, so we keep it compatible. And then after a year, there will be a recurring fee to keep receiving updates. And that will include access to support, access to screencasts that we’ll do to explain how to build stuff. So it's not 1000 euros per year, but it's 1000 euros to get access to tools that save you many, many, many hours on each project that you do.
Jisse: Yeah, so maybe to comment on it because I always love the numbers. So let's say that you have a development theme somewhere in a lower wage country, for instance, India. And I'm not saying anything about the quality of that, but just a little bit of outsourcing to have lower development rates. And let's say that actually the developers there are costing 20 euro per hour, then we're actually talking about 50 hours of such a person to be hired, right? That's the expense that we're talking about yet both of you actually say something different as well. The project that you were working with, Willem, for nine months with a certain PWA solution, it took only six weeks to refactor that. So that's, I don't know my numbers, but that's at least a winning of two times as many hours. Well, it's basically exceeding that 50 euro right away. And I think that's the same story with Peter Jaap. So that's why I asked the question.
Peter Jaap: And now you're only taking in one part of the equation because the other part of the equation is the webshop will be a lot faster, will convert better and you'll earn more money. So just that part, if you're doing any serious business at all, a minimum increase in performance and decrease in time spent on their page being loaded, has a pretty big effect on conversion ratios. So if you’re doing any kind of relevant turnover, so let's say for the EU market a million plus, that thousand euros will be earned back in the first month. This amount of money shouldn't be a problem for agencies who reap the benefits or merchants who reap the benefits of a system like this. There will always be a place in the market for the SmartWay Portals and for the fully custom designs and for the PWA Studio, but I do think that for a lot of agencies doing mid-market, SMB e-commerce shops, especially in the EU with a yearly turnover of between or maybe even 500K and upwards up to 20, 40, 50 million, whatever you do on Magento 2. I think this is one of the most cost-effective solutions out there and 1000 euros is peanuts.
Jisse: Yeah. So basically anyone who starts to complain about the pricing needs to do the math. And unless we're dealing with somebody who's volunteering all of his or her time towards Magento and is not earning any money, then maybe that person has a point. But I think as soon as you run projects, as soon as you make money out of Magento, then actually this is just a smart investment.
Peter Jaap: Definitely. Any agency should be able to reap thousand euros of benefits using Hyva.
Jisse: Yeah, but I've got also a more technical question. And that's maybe leading into also one of my pain points with Hyva as well. So Hyva is based upon Tailwind and as soon as I started to read about Tailwind’s CSS usage, I learned about just adding all of those CSS classes to the HTML, and then automatically stuff starts happening. And then instead of just adding one CSS class to one HTML element, you're adding like 20 just for that thing to happen. Which made me wonder like, hey, wouldn't it be more efficient to move all of those CSS classes into a CSS file, and simply just create my own definition of CSS? For instance, a class name called cards, or product gallery, or main menu, and then just import all of those Tailwind utility classes as a mixin like I was used to with Sass or with Less. And I read about that it's possible. So then at that moment, it was my impression, basically, that Tailwind-- That's apply you say, Peter Jaap?
Peter Jaap: Yeah. Add apply.
Jisse: Add apply.
Willem: We're doing this.
Jisse: Oh, you are.
Willem: Yeah, we're doing this in the least amount that makes sense. And what that means is that as soon as we have a repeating pattern that we see that is part of the base of the themeing, something that, for example, a button, or the way that we style an input element, or these containers that we use, we call it card, C-A-R-D. That's used for block elements and product listings, and in many places throughout the theme. And that's the kind of thing that we extract from the HTML, we apply one class and we add that to our CSS in Tailwind, and then as Peter Jaap says, you can use apply. So it means you say the class cards. It uses these Tailwind classes. So you say apply, and then the padding and rounded corners and shadow. So you can use the Tailwind classes, compose them in CSS.
And the reason we're not doing that for just everything, the way we're used to doing it, is because you're setting things in stone in your CSS file, and it's decoupled from the actual HTML that you're writing. And your HTML is bound to change. Your CSS is not bound to change that often. So you remove an element from your HTML. So there was a header component, and you removed it, a button that was there, and you removed the button, but the CSS layer, so there will always be this header button class with the styles applied to that. And if you're very strict, and you pay attention to these things, maybe you clean it up in the CSS, but usually your CSS just keeps growing.
And besides that, Tailwind is built in a way that by its own definition, your CSS remains the smallest. So the final CSS file remains the smallest when you compose different utility classes. And when you compile your CSS with Tailwind, it looks at the HTML, it looks at the classes that you actually used, and reduces that to the smallest amount of CSS. So a Tailwind by itself, the whole library is almost two megabytes. And when we compile the CSS and only use the classes that we need, we end up with 35 kilobytes of CSS. As soon as you start extracting CSS and putting it into classes like you proposed, then immediately your CSS starts growing. You get repetition of certain--
Peter Jaap: Yeah, so the repetition part is important here. So Tailwind when gives out these classes, like border b2. So you have a border-bottom of 2 am. So that's one class. If that's used somewhere in your front end, then that class won't be purged. So it will be in your CSS file. So let's say you create a card class that contains a few of these Tailwind classes, and then you apply it to one element. In that case, you introduced extra code because you introduced this class, which again, copies the data from the individual Tailwind classes, and you apply it to one element. If you would have just applied the Tailwind classes immediately to that element, you would have less code than you would have now. But if you have two elements that use that, then you can extract that into one class that uses those composite Tailwind classes.
So what do you do like in a BEM situation? You name everything, and you create maybe one class for one element that's used in one place in your whole application. That introduces a lot more CSS code than the Tailwind way where you try to find the least common denominator between all classes using a certain component, put that into a Tailwind class, and so for example, the button, you define the width and the height and the border, etc., or a base color. And then if you have the same button somewhere else, but in a different color, you just use the Tailwind color class in your HTML, and you do not create a new class called “Button Red”, and then add the color red in there because that would, again, duplicate code. So it's a fine line but if you do it correctly, and if you really think about where you will split up your classes and use the least common denominator properly, then you'll end up with way less CSS than in the BEM structure.
Jisse: So I'm making that suggestion, actually, for two reasons. So first of all, I'm a CSS nitwit. So every time when I need to create a simple CSS definition, I need to look it up online like well, “What kind of properties do I have?”
Peter Jaap: Me too, but Tailwind is created for developers like us.
Jisse: I get that point. And theoretically, I also get the point about BEM being less efficient, especially when there's less code to be made reusable. And that's also where you came in Willem, that you simply mentioned that sometimes you’re using the identifier strings within the HTML to refer to CSS, where it's all about reusability. But sometimes you're just checking those utility classes of Tailwind in HTML to get the job done. And it's all still about performance so I get that first part, and that's clear to me.
Willem: Not only. There's an extra thing - interchangeability of components. And that means when you write a block of HTML with Tailwind, it contains all the styling by using Tailwind classes. That means that if I cut and paste something from another website, from a library, there are loads of Tailwind libraries where you can get all kinds of layouts and call to actions and a newsletter subscription. Think of it and it exists. And you can just simply copy that HTML, put it in a PHTML file, and then replace the static content with variables and recompile your CSS and it works. As soon as you start introducing project-specific or framework-specific classes to it, it becomes much harder to take something and extract it and reuse it. And we're planning on creating a library of different UI elements. We’re creating the third variation on the menu right now. So we have a static menu, just a few links on a line, then we have a drop-down menu now that's fully dynamic, and rebuilding at the moment, a mega menu. And it will be super simple to just swap the menu, take the PHTML file that contains the mega menu, replace it in your theme, recompile the CSS and it works. And if you would do that in a traditional way, you would need to have an extra CSS file that contains the CSS for your menu, and that’s just bloat everywhere.
Peter Jaap: Yeah, which brings me on third party extensions because when you just explained is exactly what third party extensions now do. They provide a PHTML file, maybe a .js file, some CSS, you put it in, the Magento system hooks into it, pulls it into your CSS file, merges it, minifies it, whatever, and then the functionality is there. How will you handle third party extensions?
Willem: With compatibility modules. And that means if I take an example, we have this GTM module from Yireo.
Jisse: Oh, who’s that?
Willem: But you're free to do that. You know what it is?
Jisse: That’s my question.
Willem: Yeah, so you have a base theme, which is our default Tailwind theme, and it contains 35 kilobytes of CSS. It can even become less if you decide to throw things out but that's your baseline. And I don't care if you add jQuery, pull in jQuery, and write a component that uses jQuery, it will come with a small penalty, it will pull down your page speed score. Same goes for whatever CSS framework that you would like to put on top of it as long as you make sure that they don't conflict, so you can add a prefix to your Tailwind or add a prefix to classes from whatever tool that you Bootstrap, and that will work perfectly. But I'm really just aiming at simplicity, reduced complexity, and performance. And we get the maximum performance by not including these third-party libraries. And so far, when I started building this, I fully expected to have to include more libraries. I thought the mini card, I'm going to have to build that with React because it will be more complex and Alpine.js won't be able to handle that. Alpine.js, I think could even do the full checkout. It's just at that point when it becomes so complex, React or Vue becomes the better tool to build something like that because you want to have--
Jisse: Could you still comment a little bit about the current state of the checkout as well?
Willem: Yeah. So we chose to go two paths here because not everyone that will use Hyva will be technically adept enough to use React to build a checkout. And using Alpine doesn't really make sense to rebuild a checkout. It will become so complex that you’ll also need to write a book for someone to understand how it works. So first of all, to have the shortest path to getting a production-ready website, we have a full back Luma checkout module. And that's for the person that wants to have a perfect website for 90%, and go live with that and have checkout that still relies on Luma. And that works perfectly. So if you have shipping extensions, payment extensions, they're all already compatible with Luma, so as soon as someone enters the checkout, they enter a page that actually renders the Luma theme. So if you want to go live fast, you can build your Hyva site in one or two months. Don't bother too much with the checkout, and perhaps hire someone who can customize the checkouts for you using React or Vue. But at least you don't need to have a lot of technical knowledge about how the checkout works.
Then the second half, the second option is that we open sourced a whole React checkout that's not fully functional yet, we're still building out features there, but we have a React checkout that works fully headless. It's built with React, only uses GraphQL. It's compatible with default Luma, you could use it on your old Luma site, you can use it with Hyva in our front end, but you could even use it in any headless Magento shop. I started building that in January, actually, and then put it on hold for a while. And then we had a project at Integer_net where we needed a React checkout, so I started implementing it for a B2B shop. So it currently has the billing address, it has a cart implementation where you can add and reduce items in the cart, it has the totals, we're finishing up checkout agreements, order comments, and then it's really not a big step to also include the shipping address, the selection of the payment type, and the selection of the shipping type.
That's on the roadmap. We’ll hundred percent finish that module so that all the base features will be in there. So if you're in a hurry, you could build your shop now and use the Luma, fallback checkout, and wait until we fully featured the React checkout. Or you choose to use the ShipperHQ React checkout or the Snowdog Vue checkout. Or I mean, there are many checkouts out there. And I tweeted this a few weeks ago, I tweeted “Hyva is a bring your own checkout concept”, which maybe confused some people that had thought that we're not bringing a checkout. But it's a bit more nuanced than that. In fact, we have the fallback checkout rebuilding the React checkout, but you have any choice to implement another checkout as well. There are options, there are plenty of them.
Willem: We asked them to.
Jisse: We asked them to, and they've created it for free as well. And we became dependent on it. So what really bugs me, what for me, the really most annoying thing is, is that actually from the very start of Magento 1, which is like ages ago, there was this tendency or intent that actually the community would step in and create an alternative front end, which was better, depending upon what kind of front end technologies came up. And only like 10 years later or a little longer, then this Dutch guy comes along, Willem Wigman, and he creates something like that. And I'm just really scared that actually, people start to embrace Hyva and not see the opportunity of them recreating a lot of stuff themselves, not seeing that opportunity to drop Tailwind and embrace Bootstrap if they want to. But basically, looking your direction for maintaining everything and then just blaming you if the progress is not fast enough. So how do you see that? Why didn't somebody else come up with this ID earlier?
Willem: I think the timing is just perfect with the tools that we have right now. And I think Laravel has played a very big role. I mean--
Peter Jaap: Tailwind
Willem: No, so Tailwind comes from the Laravel ecosystem. And that's a very happy PHP community. And the tooling there is great and moving super fast. And Tailwind and Alpine.js, are a result of a flourishing Laravel ecosystem. And well, there are probably other tools that are great as well, that we could have used, but in this case, it's the most performant and the most lightweight tool that you can use to build. So that's where I made the choice. One, developer happiness, I see the developer happiness in that ecosystem, and I wanted to tap into that. I didn't want to make the switch to Laravel development because I'm a Magento guy, but I wanted to recreate that happiness. And so far, if I look at the developers that are working with it right now, I'm succeeding in that. And that alone makes me very happy.
Why didn't it happen before? We're not fully done yet killing Internet Explorer but we're almost there. And I think that has been a great factor in holding people back. And then it's a scary thing to do, right? If you would have given me the task to rebuild a front end for Magento, I wouldn't have gotten started with it. But I had the perfect use case where I was just fiddling with my own little project, I was trying to build a webshop for my wife, and I was imagining, how could I do that in a way that I'm having fun? Because quite honestly, in my day job doing Magento 2 front end, it's not that much fun anymore. And that's kind of depressing, so on my side projects, I was trying to do something that would make me happy. And I just got started. And that way, it wasn't something dumb or something unreachable that I was trying to do because I wasn't trying to rebuild a Magento 2 front end. I was trying to do a simple shop for my wife with the least amount of code possible.
Peter Jaap: I guess it's a perfect storm of you running into that situation, having browser compatibility up to a point where stuff gets a lot easier, the existence of Tailwind, Magento being in a more competitive market than they were five to 10 years ago when they were pretty much the only player in the open source e-commerce environment, SaaS platforms getting better and better - the competition is on - and then PWA coming along as this sort of panacea, cure for everything, please use our PWA offering, it's great. And then it turns out it isn't great. So I think all of those combined culminated into what is now Hyva, and who knows, maybe there will be a Hyva competitor down the line. All the better; that will probably serve a different angle and serve a different market.
Jisse: Yeah, and I think that that's basically maybe also one of the points to learn from the story. Regardless of whether you're going to use Hyva, Willem is just pointing the community towards a very obvious point that if the current Magento for content is too complex, you might just work really, really hard into improving it. But you might as well just create something new, and that something new might be totally different but a lot better. And that's basically what Hyva is right? A better front end than Magento.
Willem: Yeah. And I think it's gone really fast, which is, I think a product of the fact that I did a lot of the things on my own. So I didn't have to argue, I didn't have to plan things, I didn't have to write things out. I lay awake for many, many hours thinking about how to do stuff. I would wake up in the morning at six o'clock work one and a half hour on Hyva, and then take care of my daughter and work. So it took a lot of dedication.
Wait, your daughter wakes up at 7:30
Peter Jaap: My God. You are one lucky person. I start work at five because my daughters wake up at six.
Willem: It depends, if it's a day she needs to go to school, it's a little bit earlier. But I had this period where even on a holiday my wife and daughter would sleep until nine and I had two full hours to just fully focus.
Peter Jaap: Wow. So basically, we have to thank your daughter for Hyva.
Willem: Yeah. I think--
Peter Jaap: Final comment.
Willem: Final comment. I'm excited. We're getting really close to bringing this to a lot more people. We've been holding back a bit, giving just a few people access so that we can check on the code quality and see if there are gaps that we still need to fill before we publish it. There's a list of people that I'm really thankful of that they're still waiting for me to give them access. And I'll be very happy to give that to them soon. Yeah.
Peter Jaap: Right. Sounds great, Willem. Thanks for being here, and I guess we'll see you in the future. Maybe we'll do a report back episode in half a year or so and see where you stand with Hyva at that point.
Willem: Yeah, we need to hear how your projects are.
Peter Jaap: I’ll probably blab about it here in one of the next episodes.
Jisse: Basically, in half-year time. That's the impression I get. You can both say that you've built like 20 different shops in two months’ time or so because the speed just comes up tremendously. Yeah. So Willem, thanks for joining us.
Willem: Thanks for having me.
Jisse: It was awesome, so thank you so much. And thank you everyone for listening, and we'll be back with another episode on… Peter Jaap?
Peter Jaap: I have no idea yet.
Jisse: No, I mean the topic was you. No, I’m just kidding.
Peter Jaap: All right! Yeah. Sorry CI/CD, pipelines stuff.
Jisse: Oh nice. Continuous integration, continuous deployment. Let's do that. So totally different topic but I think this one was really awesome. So thanks again to Willem.
Peter Jaap: Absolutely.
Willem: Thanks, guys.
Peter Jaap: See you guys. Bye-bye.