Hyväaaaaalalalalalala
Play • 1 hr 4 min
Full transcription below the show notes

Show notes

We talked primarily about https://hyva.io/ 

Some other links we mentioned along the way: Full transcription

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.


Willem:
Hallo


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. 


Willem:
Hallo. 


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.


Willem:
Yeah.


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. 


Willem:
Huva. 


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. 


Also didn't feel at home with the new solutions that are currently being provided, and we don't really believe in the whole PWA heavy JavaScript framework solutions. And so what Hyva is, to just round it up, and then I'd be glad to take your criticism already. So Hyva is our attempt to fully replace the old Magento 2 front end, which is still PHP, HTML, CSS based. It's fully server-side rendered, and you could say it's the current Magento front end redone in a good way. So it's performant, it's less complex, and it's fun to work with. And speed in which you can develop things is much, much faster than what we've seen with the old front end and what we've seen that PWA currently offers.


Jisse:
Yeah. Well, and I think Peter Jaap and I, we both know a little bit more about Hyva as well. We've seen the ReactorCon presentation that you ran there. And in general, could you say also that the real innovation of Hyva is that you simply just dump all of the JavaScript and write it into as less JavaScript as possible?


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. 


And as soon as you look at this, React and Vue and all these PWA libraries or frameworks, they heavily rely on frameworks. And it will always come with at least hundreds of kilobytes of boilerplate JavaScript, while you then have nothing but a page that renders. Then on top of that, you need to write a lot of code to actually also render HTML. And your browser can both render HTML, you can render your code on the server already, and then your browser has to do very little to create an interactive page. So in my opinion, we kind of drifted away from the core principles of web development, and I wouldn't say that there's no room for app development in the web ecosystem. So if you look at the website of Twitter, or maybe an Adidas, or a Nike, or Amazon, they might benefit from an app like experience, and then it maybe makes sense to ship a lot more JavaScript code. But for the typical e-commerce project, a typical website, you don't need a full-fledged app for that. And besides that argument, the current web browser capabilities can do a lot of things already that don't rely on React or Vue. That's already baked into the browser.


Jisse:
Well so I think, to open up for the criticism, the main point that you're making is maybe that Vue and React is maybe too much when it comes to simpler logic, simply just to have a catalog of product pages and category pages to have CMS content out there and etc. But I think, of course, the real benefit of React and Vue is to have the functionality of a single page application. And as soon as you talk about a single page application, it's also about loading, maybe that abundance of JavaScript, but also the CSS only once, because once it's loaded, you can navigate to another page. While theoretically, in your case, if you're navigating from the product page to the category page, the checkout CSS has already been loaded into the browser as well. And of course, I can hear you say that that if you keep the CSS to a minimum anyway, who cares? But I think it's kind of harder to measure. And I think there's also an opportunity for Vue and an opportunity for React, but I think your main point is that if you're looking at e-commerce, and the requirements of having SEO in there, and product and category pages that are fast to navigate, we've been overlooking the fact that actually maybe PWA is slowing things down. And that's where the revolution that you bring in actually pays off.


Willem:
Yeah, so I personally think that a typical e-commerce website doesn't need a lot of state handling and data management, it's not data-heavy. It's a quite simple website that shows products, and you can add it to the cart. And then comes the complex part, it's checkouts. That's perhaps the most complicated part of an e-commerce site. And that, we don't build it with plain HTML and lightweight JavaScript, we chose to use React there because then we have a lot of state management and extra logic, and you actually have a UI that changes when you select a shipping method and a payment method. And then you need some extra tools to build an interactive interface there. But for the rest of the website, you don't need that much.


Peter Jaap:
I think that's where you hit the nail on its head. You have to use the tools which are built for a specific purpose only for that specific purpose. And where, for example, PWA Studio went, is where they use a reactive framework, like React, in an area of an app, or website or webshop, in this case, where it's not actually needed at all. So this introduces a huge layer of complexity in the form of JavaScript, which is then pushed on to a community of PHP developers. And that says, “Hey, work with this complex system to make a front end and to solve the problem we introduced years back with a new problem.” Instead of simplifying the solution, they actually made it again, more complex. So React shines in the places where you mentioned. 


We build a lot of product configurators in React, which, that's perfect for it. That's exactly the use case React was built for, or Vue or Angular for that matter. But it's overkill to force a webshop into a single page application where the product page or category page, which are, in essence, very simple pages, yeah, put a lot of JavaScript on top and then have all kinds of developers struggle with this massive new framework. And I think the great thing you did with Hyva, is simplifying what we already had, leveraging the good stuff, what developers already know, bring in Tailwind in this case, utility-based CSS framework, which brings back the amount of CSS that's being downloaded. And if we don't handle preloading stuff in a smart way, so that the checkout CSS is already loaded on the product page or the category page, then we can leverage all these modern browser tools and make a really fast webshop without having other JS complexity.


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. 


Jisse:
Yeah.


Willem:
And what I love about Magento is mostly the back end capabilities. And the core of the front-- So the most technical part of the front end, say blocks, Vue models, layout XML, those are really good. And that's exactly the parts that we're keeping because we love those parts, and they have their roots in Magento 1, and they've been ported over to Magento 2 in a pretty good way. Then what's on top of that, is just a pile of not such great things and that's what we've cut out. So the bloat of HTML and the complexity of the layout XML, and all the JavaScript had to go. And we replaced it with something that's better as proven tools that come from the Laravel ecosystem.


Peter Jaap:
Let's dig a little bit deeper on the technical side. How did you actually strip it out and rebuild it?


Willem:
Yeah, so because I knew I wanted to keep a tight coupling between back end and front end, I knew I wanted to keep layout XML as the core technology. So I wanted to still leverage the flexibility of composing your front end with layout XML, but I needed to get rid of all of the default PHTML and JavaScript that's being inserted by XML. So we have this reset theme. And we don't inherit on any theme, we have a reset theme. And that's basically it only contains layout files that do nothing but they overwrite layout XML files and they empty them. The only thing that remains there is containers, and all the blocks are being thrown out. And from that point, so that was my starting point, I built this reset theme. And then I created a chlid theme that just presented me an empty HTML file. So if you rendered the front end, you would just have a head and a body tag and except for that, nothing. That was my base point to get started and reintroduce HTML and see whatever JavaScript I would need to make it interactive again, and I really started from 0.0, blank page. Yeah,


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? 


Willem:
Yeah.


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.


Jisse:
Maybe to rephrase my question before this just becomes a long, long feature list and the roadmap. So I think it's fair to say that that you started it, and instead of just finishing it from the start, which is totally impossible with the ever-growing feature sets of Magento itself, it's simply fair to say that there's always a little bit of work that you need to put on top of it. And you're being open about it, and the roadmap is there. And there's progress being shown as well, if you say also that a certain feature is going to pop up in weeks, not months, not years, but just weeks. So that's a benefit. But basically, it shows also maybe that to add new features, it's not that bad. So the impression I get, I think a lot of people would get from Hyva is if you remove all of the JavaScript, if you remove all of the CSS, and then on top of it, you also remove all of the HTML, you're left with nothing so that actually you need to go through so much work to get a single feature in there. But my feeling is, that's not true. So could you lament a little bit on that?


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. 


Peter Jaap:
This is also one of those projects that nobody in the company wants to touch because it's just so JavaScript involved and that’s just there.


Jisse:
One of the difficulties with having this conversation is maybe also the licensing scheme. So I've been hearing actually a lot of positive feedback in the community about Hyva, so that's wonderful. And I think also that my feeling as soon as I heard about Hyva, basically, that was also based upon the stories that Willem was telling is basically that the developer experience goes up. But it's not only the pleasure to work with something more bare-bones, but it's also actually that the efficiency goes up as well. So instead of just wasting hours on building something with SmartWay Portal which seems simple, but then you need to tune things, then you need to troubleshoot the JavaScript errors, and then you're still stuck at the lowest lighthouse rating ever. I think that proves a lot. However, then it's still hearsay because I think a lot of people hear these stories and then they look at the pricing page of Hyva at this moment, and then they see that it is costing “heavy”, and I'm putting that between quotes because that's where the discussion is. A heavy sum of 1000 euro per year. 


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:
And we made that compatible with Hyva. And what that entails is, we take the module that Yireo or Jisse created, we put it in with Composer, and then we put in an extra compatibility module that we created that only contains the PHTML file and the JavaScript that we changed to make it compatible. So there's one module that sits in between, and that overrides the output. And in this case, for this module, it took less than two hours to rewrite it to work with Hyva. 


Jisse:
Okay. This is maybe also where I would like to make a point. So the thing I was trying to get to earlier was actually that if the amount of work to strip away all of the nonsense JavaScript and the nonsense CSS and the nonsense HTML that is shipping with this average third party extension, if removing all of that is peanuts because there's a reset, but additionally, to rewrite such an extension to behave in your own way, then I get that if you're fond of Tailwind, and you've thought out this modular system on your own already, then it's kind of cool. However, what I still see is-- So I'm still a CSS nitwit, right. And I think Tailwind is cool, but I still think Bootstrap is cool as well, and I think foundation is cool. And I think any kind of tool that makes your life easier so that you don't need to write CSS from scratch, I think that's cool. I think on top of it, writing CSS from scratch is cool as well. So my main point is--


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.


Jisse:
So maybe the problem is choice. So to me, there's still one really annoying thing in this whole story. And that's ever since Magento 1 came out and as soon as Magento 1 came out with an XML layout, somewhere in those days I met up with Yoav Kutner. And Yoav explained to me, hey, the reason behind this XML layout is actually for people to create their own front end to have the liberty to build whatever they wanted to build. Because the front end is always going to be moving faster than the Magento back ends. He had that vision. And then actually Magento 1 happened and it became popular also with maybe lower end merchants or less capable developers. I'm not trying to be rude but maybe that's what happened. And everybody got stuck to prototype and Scriptaculous and they believed they were stuck. And nobody ever came up with this ID to create a second front end based upon jQuery because that was hot. And then Magento 2 came out and Magento 2 just continued with not necessarily something that is really bad because they needed to choose between maybe creating their own JavaScript stack like before with Magento 1, or they would have gone the Angular way or they chose actually for knockouts thinking back then it was a good ID. And then they maybe learned their lessons, but they created a legacy. And I often say that we shouldn't blame Magento for creating all of that stuff because on top of--


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…
Search
Clear search
Close search
Google apps
Main menu