Commerce

MDOQ, Automations and SaaS with Arron Moss

We interview Arron Moss of Zero-1 and MDOQ this week on helping developers automate their Magento CI pipeline and how this saves big money for merchants

Brent and Aaron talk about MDOQ

MDOQ automation and SaaS

Brent: All right. So you haven’t seen last week’s episode, but last week I did start with some music, and it went, dih dih dih dih did do. Oh, you saw the preview. Yeah. So 

Aaron: [00:00:18] Deryck, yeah. Deryck, was it? That was it. 

Brent: [00:00:21] Yeah. So it hasn’t been published, but we do some music now. And, and so if you wanted to do the intro music, that would be great.

So go ahead. 

Aaron: [00:00:28] What’s it? To tap a tune? 

Brent: [00:00:30] Yeah. We’re just looking for some really good intro music. So if you could do maybe a 15-second song as an intro, that’d be fantastic. 

Aaron: [00:00:42] God, on the spot. Did do do do style?

Brent: [00:00:45] Any style you want, this is open mic. This part…we’ll edit this. So don’t worry. I’m not going to put anything embarrassing. 

Aaron: [00:00:54] It Probably got to be about five or six seconds. Did something that Springs to mind actually [00:01:00] did it du, du, du, du, du, du, du, du, du, du OU, which is from a well-known that UK TV program?

Brent: [00:01:07] I used to have UK TV anywhere before it got shut off by the BBC.

Okay. 

Aaron: [00:01:14] Yeah. 

Brent: [00:01:18] All right. That’s good. Do, do, do, do, do. Perfect. All right, Aaron, why don’t you introduce yourself? Introduce your business and tell us what you’re, what you’re doing nowadays. 

Aaron: [00:01:33] Okay. Yeah. So my name’s Aaron Moss.  I’m a CEO and founder of a little-known company in the Central UK in a spot town called Boxton. The agency’s called Zero One. We’ve been an Ecommerce agency formed in 1999, and we’ve been a devoted Magento-only SI since around 2009. I believe we first looked at Magento at 1.3. And, as a business predominantly working with open source and probably OScommerce at the time, gradually as many others did, got bitten by the book, of making the platform work well for, then smaller businesses and startups. And we’ve really grown with the platform over that time now. And probably right in saying that maybe we are still one of a somewhat diminishing proportion that is still solely working with Magento. I certainly know many agencies are perhaps looking at more than one platform at a time.

I don’t know if that’s a strategy that I’ve [00:03:00] consciously and made the decision over. It’s just pure British stubbornness, to be fair. But I think the devotion to a single platform in my mind will certainly pay dividends to us, I hope. And the way that we’ve I think, capitalized on that, that focus.

And that’s it. And we stand here today, really like that business, but in two forms, I. I an SI in a more traditional sense. And like the holders of a product that is about to extract itself from our traditional business.

So we sit here twofold in a sense. 

Brent: [00:03:54] Yeah, that’s great. And I think you know, just to get down to the nuts and bolts, what I wanted to talk about is, [00:04:00] is the product you’re doing MDOQ, right? Where you’re helping developers and essentially then merchants streamline the CI process.

Would that be an excellent way to look at it or a development process inside of Magento? And I don’t want to get into it. 

Aaron: [00:04:20] That’s a great start. And actually, not getting into the technicalities of it is an amazing help for me as we take the product forward because this is the most challenging aspect of bringing the product to market.

We could describe it in many ways, in simplistic terms. It’s a tool belt. For the Magento application in one sense. Yes. It includes key components such as pipeline, deployment pipeline. But there are a whole host of other [00:05:00] areas of the application. All founded around automation.

And I’m going to steal. I’m going to steal an analogy that I tripped across courtesy of Mr. Marks last week. MDOC is the glue in between this freedom of open source and the constraints of SaaS, which, as he perfectly put it, the guard rails, these, the doors are locked. The guardrails are up, and open source, as with Magento, has been both its greatest strength and greatest weakness over the years of that sheer openness to the platform. There’s protection in the middle, as, using the metaphor of guard rails, we believe MDOC is giving that unique kind of central [00:06:00] position to the benefits of both. You can protect the platform with automation and shielding, or most so, you can have the power of open source without necessarily locking the door and closing and throwing away the key. That’s a work in progress analogy. So we’ll see, we’ll see how that one gets received. And I might work on that. 

Brent: [00:06:29] I think just to educate any merchants, the idea of how you would traditionally run a website is that you or your developer would log on with FTP or SFTP or something and modify the code directly on the server.

And hopefully, it works. And sometimes it doesn’t. Sometimes you break things, and then you scramble to figure out what you want to do. Along came version control. And then we [00:07:00] we would publish things to version control and then publish things maybe to FTP.

But again we’re talking directly to the server. Certainly, this was a habit of many developers. And then along came, and you can help me here, but along came compilation that would add a little bit more complexity to the build or let’s just call it the complexity of the actual running website.

The compilation has nothing new to say .net or some of these other technologies. But Magento2 would then compile itself. And allow for a faster runtime on production, but it also meant that logging in with FTP and just modifying a file which again was never good practice, ended up being even worse practice in this case.

[00:08:00] So the traditional route for some developer now, or has been for a long time, would be to work on your local machine. Publish that to a development server, or sorry, publish it to your repository, which then would get deployed or published to a development server, staging server, production server, or wherever you’d like to publish it to.

So. I think this is where you’re going to come in. What we’ve seen is the complexity around those builds on your local machine, especially with some of the new technologies that have been introduced into Magento, are making that even more difficult. And I think MDOC now comes in and helps us, helps any developer get onto a project quickly.

And I know we spoke before that the time for a local setup has [00:09:00] grown and agencies have to start looking at how much time each of their developers is taking to make that local setup work, just to get started or get their development going because they have to get that running on their local machine.

Aaron: [00:09:18] Yeah. I mean, you’ve explained, I think, the key challenges of us as a business. And I think one of the pieces of background from our SI agency really, a key factor is, as you’ve just explained, tying this to, effectively, preparation time to become a billable asset as it were in the agency world.

I recall the first insight we had into this was from Gary Specter. It was on a partner call with Magento probably [00:10:00] five years ago, very early days of the Enterprise Cloud launch. And they were pitching Enterprise Cloud Edition as the early stages of the business as it was comin,g to market and said they’d surveyed all the Magento SI’s, and the aggregate estimation for preparing as a developer to carry out some work on the Magento installation was 1.5 days. And I thought, wow, you know for us, we’re a small agency, and we love working with the application for smaller businesses.

And quite frankly, for the majority of small businesses, and we do focus on open-source, many of those businesses would struggle to bear the cost of the person-hours for 1.5 days for a lot of the small iterative pieces of work that we do anyway. [00:11:00] On a typical day where we’re rolling out two to four-hour developments in a very iterative kind of CICD way, you know, so deployments are happening all the time and to effectively like potentially top and tail with prep and two-way and the rest of the acceptance process at the end, a two-hour piece of work, you see this massive inflation and what we can assume might culminate in this heightened TCO. That is the kind of hot topic at the moment. So the platform costs for us would just be unrealistic for smaller businesses. So we took the learnings from some of these really large clients that we’ve had the fortune of working with. And we developed the process. Everything that we did was about [00:12:00] 

It was about replication, and it was about taking a process into becoming automation. And then it eventually manifested into a product that’s becoming quite rounded. So one-click replication, you know, so. You click a couple of buttons, and you have, what is as near as we can get a, certainly a development environment, but to feel as local as it can very, very quickly.

And quickly, generally between five and 20 minutes to have a fully functional instance ready to work with from a development or a QA or support or exploration or a sandbox basis. And we realized that when we had the early [00:13:00] seed of this that we felt, for us, we had something that we could take forward.

And we’ve just continued. We’ve continued, albeit on the time-saving aspects of what it began to deliver a few years ago. And actually, we’ve been able to put more and more of our internal resources to make it better and better and better. Yeah, so we’re delighted with where it is today.

It’s used quite extensively by a number of businesses. And we’ve got some exciting prospects. And as you mentioned before, the other complex application stack, precisely as we move now towards headless and PWA, gets ever more complicated for an individual, say, software engineer, to get a [00:14:00] local working environment. So we believe remote, you know, RDE’s with automation around infrastructure replication, but we hope that that’s where the industry will go, you know, and it seems to be the case. We’re getting really strong evidence. Now we’ve got a couple of larger clients who were doing Magento PWA projects and were using Vue storefront. Spin up working view store from dev instances within minutes with no, no localized or DevOps or local infrastructure requirements and to be working and delivering code, usable code to that wider application that they don’t need to become involved with is very excited and some of [00:15:00] the customers that are using it getting excited about the speed that they can deliver kind of project iterations. So, yeah. I don’t know if 

Brent: [00:15:12] I think I want to key in on that five to 20 minutes and that may be a lot of merchants don’t understand the amount of time a developer could take in creating their local environment and especially a new person who’s just been introduced to the project.

I would even say that a developer then who is primarily front end, who would, maybe he or she isn’t that familiar with some of the intricacies of some of the parts of Magento, they might spend a little bit more time or they need some help from a senior dev to get some of these things running the solution that you’re offering really for five to 20 minutes. If we’re taking an average of four hours or three hours or whatever that timeframe is, depending on the level of the developer to get it up and running. Certainly, [00:16:00] if it’s a longer-term project and you have a developer working on it in the long term than four hours or three hours or two, whatever that timeframe is, is negligible over a two or three month period–but having an agile group and having the ability to bring in front end developers to offer and supplement work with the realization that.

Hey, we’re going to get in here. We’re going to get up and running in five to 10 minutes. Wow. That’s fantastic. And I think it’s very difficult for a merchant to understand that and the need for that and the complexity and how much time that will save. You also spoke a bit of the whole process, the QA process, and just bringing somebody in for, let’s just say the merchant has something they’d like to do. It’s sort of last minute, and their regular developer’s on vacation, and as an [00:17:00] agency, you want to be able to help them. Having the ability to easily spin up an environment and do that quickly is imperative. So I think, you know, if you could just speak a little bit to the fact, I mean, to how a merchant should be sort of looking at the time frame from code to get to live and how can they, how can an agency improve that timeframe? I think that would help everybody understand the importance of what you’re doing and how that will really help developers over time.

And then I think at scale too, the more developers you have, the more complex it is to keep everybody on the same page. 

Aaron: [00:17:49] I think the key, the key for me is, and this could be why, whether we’ve got this right or wrong, [00:18:00] this has been my kind of firmer opinion of the last couple of weeks, a couple of years in particular.

With respect to let’s say that the DevOps culture and the practicality of, let’s say, deployment pipelines. Now there are commercial pieces of software that you can work with that can help manage that process. But if you look back over the last ten years at other peripheral sectors of e-commerce, then let’s take email marketing.

Now that is very much ten years ago, the whole mechanics of email marketing and how that evolved into becoming intelligent with not necessarily even AI, but the level of benefit and progression of how static emails to global marketing email [00:19:00] marketing lists slowly progressed through the innovative thinking of the agencies and the merchants on how they could be more successful.

And then slowly over the years that became, it became the intellect, which then eventually became the product. And obviously, now we have a very flourished market with businesses that have very rounded, powerful software solutions that encompass things like AI. So you’ve got Dotdigital, and then obviously you’ve got this whole visual merchandising sector as well, and there’s undoubtedly a convergence between these. Now in DevOps, there hasn’t been this breakthrough. These systems are all very much backend and seem to be always retained as being within the intellectual property typically of the agency if the merchant is small. Or if it’s a [00:20:00] prominent merchant, there’s usually some hazardous assets, probably the best way to explain. With DevOps engineers, that again, it’s not an open policy and it’s not an open kind of culture. It’s usually key people within the agency, within the merchant, who actually hold the keys to that kind of process and the progression of DevOps within a business.

And what we would like to think is that like any other sector that evolves alongside e-commerce, it needs to, as it can break into commercially competitive products that can bring, introduce automation to all these processes to effectively, as I said earlier, is to get the protection and to fight back with protecting open [00:21:00] source with software automation that kind of brings this utopian best of both rarely between open source and SaaS. And that’s what we’re trying to break through and try and convince the industry that that opportunity is, we feel, the single most, let’s say fruitful, way to reduce total cost of ownership, certainly for a platform like Magento, because the colorful array and stark difference in costs from our size and merchants and all people delivering on the Magento2 platform for us is worryingly disruptive because of that. There doesn’t seem to be any leveling of costs.

And that for us, one way of controlling that by introducing that kind of layer of application and automation that we hope will bring a bit of stability to ownership costs for the platform. 

Brent: [00:22:19] Yeah. So let me just speak right to this whole SaaS versus the on-prem or self-hosted platforms.

And look at it from the merchant’s point of view traditionally you know, when we did go, when we were just doing things with FTP, the process to update your website was fairly similar, you know, I guess in the SaaS world, you would go log in and make some modifications to your theme. The more complex your theme is, the more skill you’ll need in doing those modifications.

And I guess I am assuming because I’m not a hundred percent sure. Still, I’m assuming there’s some version control and the [00:23:00] theming inside Shopify or something that somebody, somebody will correct me if, if there isn’t version control or if there isn’t wow, that’s going to be horrible. But I’m assuming there is. In the traditional FTP world, there was no version control unless you had it on the server itself, which, you know, a lot of agencies would do.

Then, you know, from a SaaS platform, you probably have a staging environment that you could publish. Those changes to a live environment. You want to do some kind of testing. I think what you’re saying is your solution is very similar to that process where even a merchant who had some light development knowledge or just had to change a color and a CSS or something like that could log into a staging server.

And if they had the same sort of skill sets, they could, you know, I’m just very theoretical here. They could modify that code on the server and then publish that [00:24:00] to live. 

Aaron: [00:24:03] Yeah, I think that’s sort of an excellent attempt to bring me back to the simplification that I need to be able to communicate as we take the product forward because I’m often really dragged into much deeper conversations now.

Yeah. And another way to put it is let’s take a couple of current real-world scenarios. So if you are, you’re on M2. And you want to look at a PWA or, let’s say, somewhere in the middle. You want to look at the Hyva implementation. Now you may be a merchant who just wants to bring an expert in who’s got a year’s worth of experience in Tailwind CSS, doesn’t care about the Magento infrastructure application, the staff, or anything he’s just [00:25:00] brought in because he isn’t, he’s a Tailwind guru. Now, this fully facilitates the fact that you can spin up a replication from production. It manages the source control branch off, and it gives you, effectively, root access to a server that is in total isolation.

So you can go and do what you want. You can allow, with just the provision of an SSH public key, that individual to do anything to run havoc if they wish to because you can destroy that infrastructure, or you can click a button. It will analyze the file structure, and it will report back a suggestion of what’s going to go into source control.

So you can accept that work back in. And this is for me. This was the missing link. And the failure and demise of the, [00:26:00] what was with Magento 1, the connect system and the admin system. And in the Magento 2, it was, I forgot what it was called, but it died in 2.3.5. They removed it.

So, kind of the extension connector interfaces without the marriage of changes on the Magento application to source control. You’re left with the only risk, you know? So we couple those things together, you know, so that we can install a module and the system knows exactly what’s been done.

So you’d give a Hyva expert access to a server and tell him to go and do what he needs to do. And he finishes at the end of the day, and you click a button, and it will say. Here are the changes. Now we can accept those into source control, and you can click another button, and we’ll go running regression tests all night and deploy automatically if you [00:27:00] want.

If you’ve got outstanding regression tasks, automation is just, it is the future, and it sits. It sits nowhere in, in the accessible commercial domain, as a, let’s say, as the productized agency, which is why we get such disparity and confusion with the marketplace and TCO that is at the mercy of the agency.

So yeah, I think we take that culture outside the agency and put it independently. And it means then that the merchants have better platform control. They feel like they have more control over the application because they do, and the agencies and the experts can work more independently because the kind of [00:28:00] operational culture of the website in terms of its progression doesn’t need to live externally to the merchant. It can belong. So it’s agencies can deliver code to source control, and that’s their responsibility for doing application infrastructure. That’s what, that’s what platform as a service is. So that just basically takes control and makes it more independent.

Brent: [00:28:23] Yeah. And I think from the merchant, so again, looking at this through the lens of the merchant, if they sign up for a SaaS-based solution, like BigCommerce or Shopify, they don’t care about the infrastructure. They don’t care how the code gets to the server, but they just want it to work.

And you know, I think the reality is that merchants on Magento would also like it to work, but they would also like to do everything they want to do inside of Magento or inside of their application, which they can do anything. Yeah. So we you know, we talked about some simple things that can get easily published [00:29:00] to production.

The reality is that there are some very complex things that are not even possible in a lot of the SaaS solutions that as a developer and as an agency, this helps you to get those things into production, much quicker and much more efficiently. And I’m just gonna, I’m just going to go out on a limb much more, with a lot more safety in terms of visibility on code, visibility on how well that code works in a near-production environment, and then getting that code live and even let’s just say that it is you, that there was something missed in QA or something missed in UAT or there is some third party that’s on the production that nobody tested and it didn’t work. Going backward is also easier, like some regression or some return, a one-step back.

Do you agree with that?

Aaron: [00:29:57] Yes, absolutely. [00:30:00] Yeah. And I think this is whereas a business, I suppose, beginning with its passion and eye on the smaller business that, you know, to be fair, the majority we talk to. Probably glaze over if we start talking about deployment pipelines and, you know, in some cases, regression testing. I think that visibility and exposure of authors as an agency to those enterprise-level businesses where that level of operation is is an absolute necessity to de-risk.

You know, they, a hundred percent is almost. I mean they call it now configuration as code. This is where Magento is going. It’s to have to jump into a Magento admin system and frantically configure things. Cause code is just gone live at the same time. [00:31:00] That’s where we lived in Magento 2.2, and certainly Magento won.

And as that has progressed and we now have this evolution and this concept of CAC and configuration as code now, thankfully, I thank the Lord. We can take the exact configuration of the Magento application alongside a new code and deploy  live instantly at the same time. So the configuration all happens in unison with a deployment that just de-risks so much, and it’s been such an eye-opener for us to be able to take that methodology down to our smaller clients because with many of those, it doesn’t take much in terms of, you know, disruption. And we understand we want to be deploying 50 times a day. You know, if we have to have operatives and people who are skilled to go into Magento admins [00:32:00] for smaller businesses and go jumping around, changing.

Configuration and tuning, and configuring the new module that’s just gone live. It’s not there. It’s not the scalable progression of the application. And I think as those features have been introduced to Magento, rightly so it points the progression further in the sense that there is almost an inbuilt deterrent from maybe working in Magento admin too much to configure the application, you know, with this new ability to lock the configuration down to give people less of a reason to be interacting so much with the application, but we’ve seen it.

We’ve seen it so much where you can go into Magento admin one or two. [00:33:00] And change a setting and cause a problem, you know, and I think to take even that aspect. There are small merchants that probably wouldn’t like this, but when you show them the benefits of everything going through a process of automation and therefore baked into source control, then changing and setting in system config here away from production, never in production, away from production that even itself as a configuration change, go through a regression process.

Then we start to understand that. We are, without locking that door, we are moving towards SaaS without becoming SaaS and, and gaining both benefits and flexibility, you know, and that’s for us in smaller businesses that are showing a remarkable opportunity in again, [00:34:00] cost reduction because we’re not mopping up. We can click buttons and deploy and know that we don’t have to have three or four resources ready to pick up the pieces after because we just, all we need to do is increase the regression testing and the processes in pre-production and production starts to take care of itself, you know? 

Brent: [00:34:26] Yeah, I want to key in on two pieces there. The first piece is the ability for the merchant to really screw up their store. I’ll just be very blunt, really screw up their store by just logging into admin. It can happen in anything. You can screw up your eCommerce or Shopify, or Magento. And I think that you’ve brought up a great point that they should be screwing up their store in some non-production environment. And getting into that habit. So the first part is, you know, just doing the habit [00:35:00] of playing with some of these things, and your typical merchant would never log into staging just to see what happens when they click something.

They would most likely log in, click it in production, and if it breaks, they would go back and unclick it. The unfortunate things that happen in real life are that they’ve clicked it. And now, suddenly, they’re locked out of admin. So, the ability in a set now they have to call some, you know, some call center in some far off land.

It could be Newcastle. Who knows. And try to restore that but getting into the habit of doing things in an appropriate way and educating the merchant on how this should happen is, I feel, the first step in just best practice around e-commerce in general, not Magento, not BigCommerce, not Shopify, not any of those other platforms, Shopware.

Helping them to understand that, yes, [00:36:00] the code should go through this process, but even the configurations should go through this process that will help them to be better, I think, a better merchant, but also just a better store owner and understanding that some of the things that the store owner does will impact their production environment and what they could be doing or, you know, a lot of people are going to have a staff. What their staff is doing is impacting their live site and how that live site impact will reduce their sales at some point if it stops their site from working for an extended period of time. 

Aaron: [00:36:40] Yeah, absolutely. I think in, taking well, similar kinds of analogies from other areas of both Magento and other industries.

I mean, you have the concept of, take the enterprise staging, for instance. I mean, that is a feature that allows. [00:37:00] content to be staged before it’s made live or from a marketing perspective, planning and visibility of a marketing event in the future. No, again, that’s for us.

It still doesn’t really encompass everything the whole, the whole application, you know, they’re always, they’re always individuals within a business and the more that can be involved, the better, the more innovative the companies, the more accessibility of any kind of staff members involved to get access to, call it a sandbox environment, an environment that they can do anything with.

The more they can, the more value they can deliver to the business and potentially drive that business forward. And that is not isolated singularly at marketing events. It’s the whole Magento application. It’s how I can maybe use this new feature to [00:38:00] understand how, whether this configuration is better or this method is, you know, this extension could be used in this way.

And to sandbox that somewhere away from production, as you say, is absolutely what it de-risks, what’s happening in real life now on production. And it gives you the safety net of doing it away from production, and the fact that it is an infinitely replicable system that you can clone 20 instances of production means that there are not individuals tripping over each other.

So you’ve just done this. I should just knock this out that, you know, you can have individual instances, or you can work on a team environment for a particular activity again like, content staging, but it starts and stops at contact staging for planning marketing events. And it, of course, that’s only a commerce feature, so it’s, again, it’s one of those things that doesn’t serve the community and the open-source customer base. So we had this thought two years ago, and we quite simply built it into the infrastructure. It was a system time change. You can spin an instance up, set the system clock on the container that runs, and just say select this future date to next week.

And then all the facilities of open source that can schedule campaigns and design changes and rules were effectively there in commerce because you were setting the system date on there, on the installation to two weeks in the future. So that one could work, but just turning it into the enterprise schedule because we’re setting the date to two weeks ahead.

That’s just another, another byproduct, really just an excellent brainstorming session. Still, there are so many other ways of really drawing much more out of the Magento open-source application than really getting credit for it at the moment. I think that’s the main reason. The open-source and the community are relatively quiet, and that is both scary and, in a sense, disappointed.

 I think there needs now to be a resurgence to really not bite back, but push out this content and show the world really how amazing Magento Open source, in its foundation, really is. 

Brent: [00:40:42] Yeah. So three points, and then I think we’re going to run out of time.

The first point is just the education around the sandbox idea, and the reality is the merchant should already be used to sandboxes if they’re running PayPal or any payment gateway. They want to make sure their payment gateway works before they [00:41:00] go live. They all give you the ability to do a sandbox.

Yes. Sandbox should never be something the merchant doesn’t understand. And if they don’t do that as an agency or developer, you should be educating the merchant about this concept of a sandbox. And I think that you brought the idea of a sandbox right upfront. And a big differentiator, I think, between what you’re doing and what a SaaS version is doing, or even the traditional way of running a Magento store, is the ability to have ten different environments and how many people have a merchant that has so many great ideas. They want to test every idea every day. But that idea is stepping on this idea because.

Developer A is working on this, or Developer B and the merchant is saying, we’ll just add more people to it. Okay. Your solution does add the ability to theoretically add more production people. [00:42:00] Because we can segment that development process into thin little parallel silos that then can be merged in later.

So I think those are the, you know, the sandbox thing and the ability to have all these different environments. Indeed, the different environments are something that is a big differentiator from the traditional SaaS model. But you know, I think that would help merchants see the value in what you’re doing and help them to understand that that value will get their code live faster, even then in something, you know, like a SaaS environment.

Aaron: [00:42:42] Yeah. I think that this conversation we have quite often with businesses of all sizes. And I think it boils back to this [00:43:00] concurrency, I think is the one key thing that you honed in on. We have some larger clients that we invite to exploit the application because it could be QA’d. It could be exploratory. It could be training. It could be bugs. It could be a small feature, a subset of a much larger delivery. We’ve got some clients that have up to 50 concurrent instances. And what that does is creates independence. Then it creates an opportunity for brand new ideas to go straight through to production, obviously critical issues to be independently fixed and go straight through.

And, and as we know. The business has changed and adapted almost daily. So what could be a priority to the business last week that might change next week? So a concurrency level to allow the [00:44:00] streams of work and ideas to change pace means that it buckles this tradition. At the same time, the rest of the business can only really get visibility of that feature in three weeks because UAT, which is usually the only kind of accessible point that the business receives visibility, is there and not behind another two work packages or there’s a bottleneck because it’s a single stream. All these instances are globally visible at any point. So for us, things that stop, start decisions, people go on holiday, and all these are the normal business activities that can slow and speed up individual streams are facilitated.

Brent: [00:44:48] So I have my last point that I wanted to talk about, and then let’s just recap what you just said. And I liked that concept, the concurrent concept. Still, the reality now is that headless will necessitate merchants to look at some hosted solution, like a PWA, and that they have to continue to think about how that code gets into production.

So I think Magento’s is an excellent example of how you can run anything headless on top of it. But BigCommerce now allows for any PWA, and Vue storefront has a solution that runs on top of BigCommerce. So you know, making sure that your developers understand that process, even in a SaaS environment.

And how that can help the merchant, the agency, the developer to streamline the process of getting that code live no matter what backend solution they’re using. It could, you [00:46:00] know, at some point, it could be Commerce Tools, or it could be Shopware. There’s an infinite amount of solutions that the MDOC solution can provide that would help the entire workflow happen faster and more efficiently. And I think the key is that it happened safer. 

Aaron: [00:46:23] Hmm. Yeah. I mean, with PWA, we looked at PWA. We looked at the customers that we had at the time. And at the time, we made the firm decision to focus firstly on the storefront.

And we now have a facility and support within the MDOC Application for Vue storefront as a stack. And to answer a couple of points there. It’s [00:47:00] broken into almost a three-layer application stack independently and managed with MDOC in that you have your Magento backend and the headless stance, you have your caching layer, which is the view storefront API, and you have a facsimile view storefront instances. And those three components not only can be independent but that now we’re for some significant benefits with the right kind of infrastructure and the orchestration in place. So that. Let’s say we can have a development backend. Now maybe you need to carry out some work on exposing, let’s say, a point system, you know, developed a point system on open source and now needs to be in the backend to exchange the relevant data. That needs to be exposed to a new development at the API layer [00:48:00] and involves the storefront API work, and that it could be that you can spin off five or six instances all referencing that particular API layer, which is still in non-production, that’s still an active development. Still, you know, the people developing, you know, the JavaScript guys here, you know, someone developing a user interface for points and redemption and checkout are all entirely independent. So I’ve got something ringing here, but I’m not quite sure what it is. 

Brent: [00:48:38] Yeah, and that’s a great point. Having the ability to segment out those different processes allows for the future ability for new features to be introduced, and [00:49:00] there are no restrictions on this that would preclude someone working in a traditional Magento environment.

If they’re working in a headless environment that could be doing the same thing, just decouple the backend, moving a new backend, your two frontends, and in that scenario, your two friends and items are still going to be the same. 

Aaron: [00:49:25] Yeah, absolutely. Yeah, I think that level, that the slicing up, particularly with your storefront, would have been three key components.

It affords that progression almost marries, thankfully with the direction that we’re going in is we’ve got to introduce this automation because you know a heavy Magento backend requiring all these application components with elastic search Redis in the middle of gotta be populated.

And we’ve got clients that take [00:50:00] 16 hours to populate and then index from nothing, to have to orchestrate that locally just to do a bit of CSS on the front-end is not feasible. It won’t be possible, and it won’t allow Magento to retain the competitive edge as it attempts to continue the kind of support for innovation and openness if the application stack cannot be automated from an orchestration perspective.

So it’s very exciting to see these other strands introduced and PWA converge more. You can swap out the backend and the front-end that you’ve developed on the storefront. It could be connected to a different backend next year. I mean, that in itself is exciting.

Brent: [00:50:56] Yeah, exactly. We’re almost [00:51:00] out of time here. I did want to cover some important points on how to pronounce the Hyva theme. It almost sounded like you were saying “Hoover,” Which just sucks up the theme.

Yeah, I think it must be where you live. Jisse had some points, and Vinai had some points, and Wilhelm had some points on how to pronounce it. And the other thing is, it is Redis. And I think that you mispronounced it. There are many more English speakers in the US now than in England, so I would just stress that a lot of us in America do pronounce things the correct way, but manywe don’t have to dive down into that. Great. This has [00:52:00] been very informative. I hope that you know, I hope the merchants didn’t.

I hope we didn’t get too complicated for the merchants. I think it’s important that the merchant, the developer, and the agency all understand how important that is. And I think one, one good way that we could end it with is if you could, in one sentence, say how this will help the developer, how this will help a merchant, how this will help the agency would give us a good, you know kind of, closing off point on why what you’re doing is so important for our community.

Aaron: [00:52:39] Yeah. I’ll certainly try it. I think to encapsulate all the potential benefits that are shared across those particular disciplines for us. It is the transition of repetitive activities in your professional capacity in your role in a business as a merchant, as a [00:53:00] developer, is introducing automation where it needs to introduce a cost-saving many we benefit into the working developments of Magento as an application for the benefit of all, not only risk reduction.

But as I say, it a significant cost-saving, and it is not unlike any other industry that’s introduced the same methods to bring safety and cost reduction. Likewise, it’s progress in technology. So that’s what we hope to do. And hopefully, there’ll be other platforms that emerge too, as I say, further stabilize and reduce costs for Magento as a whole. 

Brent: [00:53:58] Yeah, that’s great. I really [00:54:00] appreciate it. Aaron, so no relation to Moss from the IT crowd.

Aaron: [00:54:12] No! Less hair as well. 

Brent: [00:54:14] Great. Hey, this has been fun,willidea should try to do this again. And as things progress and as you know, maybe even some demos we could do in the future or something like that, I don’t know. Let’s keep it open. I love what you’re doing and how you’re helping the Magento community, and keep it up.

Keep up all the good work. 

Aaron: [00:54:37] Thank you. Thanks for inviting me. Take care. 

Brent: [00:54:39] Yep.

PWA Studio vs Hyva vs Vue Storefront with Jisse Reitsma

Brent Peterson and Jisse Reitsma discuss all things frontend, including PWA Studio, Vue Storefront, and the new Hyvä theme for Magento 2! We hope you enjoy Talk Commerce EPISODE 1!

Notable quotes from this podcast

The front-end world moved on with a focus upon modern-day practices to improve the lighthouse score, to improve the mobile experience and nothing changed within Magento. @jissereitsma

Jisse and Brent talk about different headless topics and Hyva

Today on the podcast, my guest is Jisse Reitsma. Jisse is the founder of Yireo.com, an extension developer, a developer trainer, and 3x Magento Master. His passion is for technology and open source. And he loves talking as well.

Jisse joins me to talk about all things about Magento; PWA Studio, Vue Storefront, and Hyva

The shifting to Hyva Theme and what that means for agencies and Magento developers,  The era of multiple frontends, How to build a better Magento community,  Advice for hiring a Magento Developer, and much more.

You’ll learn:

(0.55) My concerns as an agent/leader on Magento moving from using the Vue Storefront theme to Hyva.

(2.21) Jisse’s thoughts on the reasons for moving and also talks about the counter side of this.

(8.22)  Negative effects of Hyva hype on PWA Studio and why Jiss thinks this is not Justifiable.

(10.20) Jisse’s blog posts that have the technical details for Hyva Developers: https://www.yireo.com/blog/2021-02-21-magento-pwa-studio-vue-storefront-hyva-all-suck

(11.12) Why in five years’ time there’s going to be multiple frontends and the impact of this on the developers and agencies.

(13.30) How to deal with the negative impacts of having multiple frontends and the hesitation I have on Vue Storefront.

(14.26)  Challenges that come with Hyva.

(17.11) Why Hyva is a winning game for a lot of agencies, but not all.

(18.12) Why the Magento community needs to be critical about the good and the bad part of Magento. .

 (29.29) Challenges that the developers and agencies are bound to face while using Magento and also what the clients look for in Saas Solutions. We talk about some of the tangible solutions for these challenges

(36.03) Advice for hiring a developer and the mistake to avoid that I made while hiring.

(38.10) Jisse’s thoughts on why there are fewer PWA Studio buys.

Ideas/Quotes

  1. The interesting part is that they set out to replace the current frontend that we basically got to hate; all of the knockout requirements and too much JavaScript, too much complexity and more importantly it’s also really hard to optimize. 
  1. The front-end world moved on with a focus upon modern-day practices to improve the lighthouse score, to improve the mobile experience and nothing changed within Magento.
  1. If you dive into Deity, you really need to get and understand the whole architecture of a React App, communicating with some kind of node middleware layer where Magento is just part of ultra microservices in that backend.
  1. I got started with React about three and a half years ago. I started doing side projects and only a half year later I began to say that I was maybe good at React.
  2. Before doing that first project, you first need to become a Vue developer or a React developer.
  3. It’s logical that as soon as they become negative about something and they are willing to be honest, and open about their own personal opinion, they’re going to share that opinion.
  4. Now that Hyva is on the rise, suddenly a lot of agencies simply decide “now PWA studio is shit”.  Basically, all of those other alternative front-ends are not good enough.
  5. I can see why if you’re a React developer trying to do Hyva, it might be confusing because you have to know all the different functions that a typical Magento team would know.
  6. So instead of talking about one front-ends, the reality is going to be in the upcoming five years that there’s going to be multiple frontends.
  7. We met with a client for who we did some training for and their site was loading in eight seconds! And somehow they found that acceptable and then I started doing some analysis. And your typical Magento site loads in four seconds, which is still not acceptable!
  8. I feel like at some point the Magento community started to accept some of these things as “we’re not going to go much faster”.
  9. Five years of stagnation has led us to having the regular theme load in four or five seconds or whatever that is. I think the Hyva Theme was exciting for me is that they’re showing less than one second load times, which I think that’s super exciting .
  10. I learned something about composer, for instance, and I went back to Magento then I thought, am I not understanding it properly? Or is Magento doing it differently than I would do that? And slowly while diving into all of that technology I learned that Magento developers are people too, and people make mistakes.
  11. People within Magento make architectural decisions and some of them are awesome. But some of them are maybe less wise.
  12. The whole purpose of open source is just to collaborate and work together to improve it and be critical as well.
  13. The inner core of Magento is just so full of opportunities still. There are so many good things in architecture as well. However, we need to be critical about what are the good parts and what are the bad parts.
  14. They don’t want Magento to be the perfect CMS. Because it’s not about building a CMS. It’s about e-commerce. They don’t want the inventory system to replace all of those ERP systems out there. They simply want to have a flexible system that could be implemented in numerous sites.
  15. The real goal is just to make sure that they do e-commerce as well as they can while relying upon the community to keep them sharp and to direct them in the direction that is needed.
  16. As it gets more complex, fewer people are going to be interested in it. 
  1. Each of the agencies is going to make their choice and it will be some kind of a hybrid between using a wired-in theme, like Hyva, or using Vue storefront or PWA studio.
  2. The difficulty is always like technology is maybe open source and it’s all available without the price, but there’s actually a huge price in there and that’s the customization bit.
  3. I think that most of the clients out there looking for a project don’t know about the technology at all. So instead of actually selling the technology— “Hyva people are saying that you can’t build a fast shop with Vue Storefront, or I don’t believe when the people of Vue Storefront are saying the same thing about the alternatives. All of those technologies nowadays are leading into faster front ends anyway.
  4. Technology and the agency are Tightly connected. And that’s where current diversity comes from in the current community as well. Different people, different needs.
  5. The client is going to care about the amount of time it takes to build it, the speed of the site when it’s done, how much it costs to maintain over time, and then finally, what are the features that are there without having to do anything? And then what features can I make at some reasonable price?
  6. I think that there’s so much change and that therefore a lot of people in the ecosystem of Magento are confused.
  1. The more difficult thing is for each developer, for each agency, but also for each client, is to make the right choice in the right way. The bottom line is that it’s not going to be easy, but definitely, it’s going to be offering more opportunities than before.
  2. Get a React developer to do React. Don’t try to just instantly convert a Magento front-end developer to React. 
  3. So sometimes I’m getting an email from people promoting their services because they’re good at everything. So they are specialists in all things. But actually a specialist at nothing.

What Was Mentioned

vuestorefront  https://www.vuestorefront.io/

Hyva themes : https://hyva.io/

Vinai on Twitter:  https://twitter.com/vinaikopp?lang=en

Magento Community: https://magento.com/

Yireo on Twitter: https://twitter.com/yireo

Jisse on Twitter : https://twitter.com/jissereitsma

Willem on Twitter: https://twitter.com/willemwigman?lang=en

Full Transcript

Jisse: [00:00:00] What do you know about “Hyva” already? 

Brent: [00:00:07] I only really know what I saw at the launch party. One of the things that really interested me out of the launch party was some of the topics around “why did they change”?

They started with Vue Storefront and they found it very complicated. Then they said, “Oh, let’s use Willem’s theme.” Suddenly within a week or two, they had a working website. 

I’m interested in this because I feel like in the last [years] since Magento 2 came out, it feels heavier and it’s bloated and it’s harder and people are complaining and so this seems very fresh and exciting. That is the number one thing I had a really good conversation with the Vinai and he was excited about it 

Jisse: [00:01:16]  I liked the part that Vinai mentioned somewhere on Twitter or maybe repeated as well that this was the first time he got excited about something in Magento. So, that’s proving a point as well yeah so, to me I find it interesting that indeed Integer_Net, the creators behind Hyva, first tried out VueStorefronts and I believe before that, they tried Deity as well. (Another PWA provider as I call them because they basically just supply you with part of the stack.) On top of it, you can build your own PWA. 

But for me, the interesting part is that they set out to replace the current frontend that we basically got to hate all of the knockout requirements and too much JavaScript. Too much complexity and more importantly it’s also really hard to optimize. 

The front-end world moved on with a focus upon modern-day practices to improve the lighthouse score, to improve the mobile experience and nothing changed within Magento.

When they [Integer_net] started with Deity, I think they were promised [their solution] will be the perfect option to do something better with the front-end. There was one caveat, they used to be based upon React is using also a really React-based stack with Apollo clients, or at least in the past, I believe that was part of the story and their architecture was basically nothing like Magento. 

And because of that, if you dive into Deity, you really need to get and understand the whole architecture of a React app, communicating with some kind of node middleware layer where Magento is just part of ultra microservices in that backend. Back then a lot of people were promised that it would be awesome and also easy. And maybe it’s still awesome, but it’s definitely not easy.

So then they [Integer_net], started with VueStoreFront and they got led into that same promise, but to my personal feeling as in it’s, like the same architecture and it’s offering a middleware layer where Magento is one of those backend services that you would connect to. Now not based upon a React, but based on a Vue. So to make it successful, you really need to be a good Vue developer. 

I got started with React about three and a half years ago. I started doing side projects and only a half year later I began to say that I was maybe good at React.

And that’s the difficulty for a lot of Magento agencies.  If they are being lured and promised an easy kickstart with some kind of PWA technology. They think “but then we’re going to do the first projects” then we’re going to make a couple of mistakes. With the second project, “it’s going to run better.” With the third project, “it’s going to be more successful”. But before doing that first project, you first need to become a Vue developer or a React developer. That’s where Willem stood up and he said we could become React developers. We could become Vue developers but why? 

We could also just recreate the front end in a better way based on that same Magento stack that showed the XML layout and the PHtml templates. The technology that is loaded into the browser, CSS and JavaScript, that’s just got completely wiped out and rebuilt for something better which is where the performance comes from. But because of that, it’s a tiny little layer that the front-end development team needs to know about. I call it that tiny, but switching to TailwindCSS and Alpine is learning a total new way of dealing with things so that there is a learning curve. Definitely, there’s the kickstart of becoming first a junior [developer], then slowly you become a senior [developer]. In general, that promise made more sense to a lot of developers.

So that’s the long story short. A little of how I see it, how they got started with Hyva in the first place, and where they see the benefits of it. However, I think there’s also a counter side as well. The release party of Hyva was nice to see so many different friends from the Magento community get excited about something within the scope of Magento. I think that’s showing something and it’s well worth Hyva already. However, I also caught that negative sense that people were not too happy with Vue storefronts. 

Brent: I got the sense that there was unhappiness and it’s really directed from Willem and some of [Integer_Nets] experiences around those people that worked with it.

Jisse: Yes, it’s logical as soon as they become negative about something and they are willing, to be honest, and open about their own personal opinion, they’re going to share that opinion. However, now that Hyva is on the rise, suddenly a lot of agencies simply decide “now PWA studio is shit”.  Basically, all of those other alternative front-ends are not good enough. But I still remember the days where I have given PWA studio training to an experienced team of react developers. They understood everything I told them about PWA Studio. It was not hard for them. It was natural the way the architecture was built, hooks were being implemented, the stuff they needed to do themselves because it was not done for them.  I started to talk about theme inheritance and they started to laugh “Hey, but we don’t want to have theme-ing. That’s what we do anyway, with a react application”, they build their own stuff. 

Brent: I think we should split this into three areas. One would be the technical side. (But we don’t want to go too technical) The next one would be the agency side and how an agency approaches [Frontend development]. The third area would be what the client is interested in. I’m not super interested in talking in depth about the technical bits of this and I think —

Jisse: oooh, so disappointing. 

Brent: I’ll post a link to your blog in our show notes when we publish this video. Your blog posts go through a lot of it, in-depth. It gives a good summary of what we should expect as a developer from a technical side. And for me, it was a good perspective on what a developer should be looking at.

Then as you jump to the agency side, you think “Oh, okay. Yeah, that does make a lot of sense”. I can see why if you’re a React developer trying to do Hyva, it might be confusing because you have to know all the different functions that a typical Magento team would know.  I thought [your blog article] was very interesting. 

Jisse: That’s basically, maybe also the thing for developers. I think actually a lot of the developers out there are listened to. That is mouthy. They actually are mouthy multiple ways. So first of all you hear them speak out loud about certain things, but they also easily share their own personal opinion. Which makes it always harder for maybe other developers to point out like, Okay, but I disagree or I agree with a certain vision there. And I think with the Magento ecosystem, it’s now a fact that actually Adobe is going to go for the PWA studio route. It’s also a fact that a lot of Magento developers love Hyva as well. And it’s also a fact for me that actually there’s a lot of agencies that don’t want to go the Adobe way, but don’t want to go the Hyva way, but they want to go their own way with the front-ending. So instead of talking about one front-ends, the reality is going to be in the upcoming five years that there’s going to be multiple frontends. For me that’s challenging already because as soon as I would receive somebody who’s interested in front-end developer training, my next question would be “but which one?” Which frontend do you want to use? And if there’s zero knowledge then it’s also more difficult to find out what kind of technology would fit that person best. And that would be on a per developer basis. But then if we are looking at it from an agency point of view, then to my personal understanding it’s either the commercial parts that you need to deal with or still the developer part, but then it’s not one single developer, but it’s just a bunch of developers. So how to make sure that you’re adopting that specific technology that is actually the best for your development team.

If they are going to hate it, you’re not going to be productive if they are going to love it, but they’re not going to be really productive about it. It’s not going to work either way. Somehow you need to find out all of that beforehand, then that’s the challenging thing I think, for the upcoming nine years.

Brent: Yeah. And I think too what is your goal as an agency is your goal. And as an agency to have something like Vuestorefront that you could also bolt on to BigCommerce. I think that if you have a mixture of business and there is a solution that Vue is the answer for, and you have a team of Vue developers, and you can be developing storefronts on BigCommerce or Magento that makes a lot of sense to centralize in that solution. The only hesitation I have on Vuestorefront is that you’re putting it on them. Like it’s not, a sort of independent thing.

Even Hyva. I would like to talk about some of the commercial bits of it. I feel like Hyva should be an open-source, it would be a much more successful project if it was open source. But then how do they make money on that part of it? 

Jisse: The money is one part, but it’s also basically how they find the time to make sure that it’s moved from this early stage where a lot of features are working but it’s not yet complete. As in the old front-ends which makes a couple of people say but then Hyva is not stable enough. But there’s also basically the calculation that you need to make, if Magento it’s a traditional front end, there’s a hundred percent feature complete. However, with every customization, it’s going to cost you twice while with Hyva it’s going to cost you half. But it does not feature complete yet. It’s just depending upon what kind of project you’re running, which one is going to be more profitable. And I think the aim for Hyva is just to take over that’s what they dream of, but you can’t do that unless you have some financial guarantee. So that’s actually still what’s happening internally. But yeah back to your point about Vue Storefront. The lock-in is something actually that makes me laugh a little bit because what is the current lock-in with Magento to the traditional front ends? While there’s a lock-in with an open-source project called knockouts. There’s the Lockin with an open-source project Require, and there are so many different projects involved with Magento because Magento is not just all of the codes written by Magento, but it’s the combination of hundreds of open source projects. And the challenge is actually not that much who owns that code because, with Vue storefronts, it’s open source. So that’s not really the difficulty. The more challenging question would be how well-maintained that code. And then, I have to honestly say that Vuestorefront is actually so eager to, to still fulfill their own goals, to make sure that their own community is happy. So they’re really active. While I honestly don’t know about the activity of the knockouts project. 

Brent: I guess I’m not familiar with the knockout one.

Jisse: So that’s actually part of the traditional front end. The knockout JavaScript. But yeah so, basically there are so many different open source projects already making up Magento. And often we don’t realize it. And it’s just, now that we make somebody else responsible for maintaining that frontend while Magento has not been really maintaining it for five years anyway.

So, as I see it, we’ve been in a lock-in already. We’ve been a Corona lockdown but then a Magento lockdown for the last five years and it’s not that Magento was forcing it upon us. But it was simply us not being clever enough. To break out of it. And at least Diety and VueStorefront paved the way and now Hyva is just doing it in a different style. That seems to be like a winning game for a lot of agencies, but not everyone. And that’s just proving that the lockdown is over 

Brent: I think the reality is a couple of years ago or whenever Deryck (Harlick) and I went on a business trip to Belgium with Adobe and we met with a client for who we did some training for and their site was loading in eight seconds!

And somehow they found that acceptable and then I started doing some analysis. And your typical Magento site loads in four seconds, which is still not acceptable!

Jisse: I find it hard to compare things. Slow loading time definitely is bad.

Brent: And the point is that I feel like at some point the Magento community started to accept some of these things as “we’re not going to go much faster because…” I don’t know what the “because” is, it doesn’t matter. We’re just this big, huge company, and, I’m not going to name any names, is working for this big agency and their load time is eight seconds. Can we improve on that? Yes, of course, we can improve on it! PWA studio comes out and your load time is one second or two seconds out of the box or something. Why shouldn’t Magento? Why? As I feel, I think you’re right. Five years of stagnation has led us to having the regular theme load in four or five seconds or whatever that is. I think the Hyva Theme was exciting for me is that they’re showing less than one second load times, which I think that’s super exciting .

Jisse:  Well that’s still the technical part right. But I personally also see that there’s a kind of philosophy goal. Basically, if you study what’s going on with the Magento community, it’s interesting that we’ve been in that situation for five years, and then only after five years, some smart Dutch guy stands up and says “I’m going to do it differently”. And to me, it’s, showing also that still, too many people refer to Magento as being the total solution provider for everything.

While the reality is that once I started to dive into Magento 2. I started to read myself into all of that related to technology. But once I learned something about composer, for instance, and I went back to Magento then I thought, am I not understanding it properly? Or is Magento doing it differently than I would do that? And slowly while diving into all of that technology I learned that Magento developers are people too, and people make mistakes. However, because they are Magento developers, suddenly they need to come up with the most ideal and most perfect solution. While the reality is that we’ve learned already for the last five years that’s not the case. People within Magento make architectural decisions and some of them are awesome. But some of them are maybe less wise. And then we bluntly just copy all of that and say okay, but because it’s Magento, then it’s true. While the whole purpose of open source is just to collaborate and work together to improve it and be critical as well.

Brent: I agree with that. The critical part is something that we’ve been lulled into a sense of complacency on what we have. And the reality of that is that people are flocking to Shopify and some of these other SaaS-based platforms. 

Jisse: Yeah the reality is as well that the inner core of Magento is just so full of opportunities still. There are so many good things in architecture as well. However, we need to be critical about what are the good parts and what are the bad parts. And a funny thing is actually, I’ve been talking about this with Magento people as well and they all confirm the same picture. They don’t want Magento to be the perfect CMS. Because it’s not about building a CMS. It’s about e-commerce. They don’t want the inventory system to replace all of those ERP systems out there. Now that they simply want to have a flexible system that could be implemented in numerous sites, but there’s still a reason why people or larger e-commerce clients have ERP systems as well. They’re not looking to replace all of that. Even though sometimes you get that impression by looking at the roadmap. But the real goal is just to make sure that they do e-commerce as well as they can while relying upon the community to keep them sharp and to direct them in the direction that is needed. Then back through the front-end bits, I find it almost funny that only five years later after that initial release of Magento 2.0 after so many people left Magento or were looking at PWA solutions or some people were negative about Magento altogether. That they came up with an alternative themselves. So what happened in between? That’s the thing I find funny to conclude. Sometimes it’s not inventive enough to come up with a clean solution or, maybe it is because currently we have Hyva and we have a wonderful community coming up with exciting things. But yeah, so that, that’s like the anthropological approach of how I see things as well. 

Brent: I’ll speak from the agency side because as an agency person, I’m dealing with both sides. I’m dealing with what the client wants and the costs of what we can deliver to the client. And then from the sales side you’re dealing with, it costs this, and because there’s some complexity, you have to say no to the client, which no salesperson wants to do that from the developer’s side, you have all these mixed messages and complexity and different technologies that the developers should learn to be able to execute on something. So, as an agency, you’re getting pulled in all sorts of different ways. One of the easiest things about Magento, when it first came out, is it was just a monolith and you just did it this way. And there were a lot of choices, right? There are even more choices, which are good and bad. I think one thing Vinai has said too as it gets more complex, fewer people are going to be interested in it. 

Jisse: Yeah and that’s maybe referring to the Magento core architecture. So things like MSI are both awesome, but also really difficult and I actually read a Slack thread this morning where a lot of people were just also discussing that maybe one of the good things about Magento currently is that you could remove MSI as well using “hacky” things which are maybe a go through for you. Also, I do see people get enthusiastic about MSI as well and, basically, the reason to have this little call together was to discuss the front end and the interesting thing again, for me as well is that with that front-end some people love Hyva and some other people are critical. Just like with React and just like with everything else.

Magento is no longer that monolith. So that’s, like, the reality. That everyone needs to realize, not only developers but also agencies and also the clients. And it doesn’t mean that the era of Magento is all over. It just simply means that we need to make certain choices more carefully.

And the difficulty there is for a developer. It should boil down to what kind of technology are you good at? So if you are bad at creating React code, but you understand Hyva [and the Magento traditional frontend] then go that way. But if you’ve played around with react already, and basically you want to get rid of that XML layout of the traditional front ends, then react is the way to go.

So I, personally, think that developers should follow their guts or their hearts. It’s more of a personal choice. For an agency, it’s a more difficult choice because you already have those developers and what you need to find out is which direction all of those developers are leaning into. Are they leading towards Vue or React, or Hyva? What is getting them excited? Because if you’re trying to push it in an opposite direction of what they actually want, it’s not going to work out.

But if they’re going to choose a direction that they find also in but they’re not good at it Then it’s also not going to work out because then you’re wasting the client’s time and money. And that’s, I think, like the most difficult part, all of those choices need to boil down to economics. Money needs to be made. And that’s also the most frustrating part for the clients. If you go to one agency in the near future that agency will say, “Oh, but we use Hyva. And the performance is guaranteed”. And then you go to another agency and they say “We’re using PWA studio and the lighthouse score, there is much better than Hyva”

And then you go to the third one and they say “Well Vuestorefront is more independent”. So you don’t have it with Magento. And what should you choose? I don’t know. I honestly don’t know. 

Brent: Each of the agencies is going to make their choice and it will be some kind of a hybrid between using a wired-in theme, like Hyva, or using Vue storefront or PWA studio. They’re, going to make a decision internally on which way to go, or they might have a big enough organization where they have Vue developers and they have some React developers.

But I think from the client side the hard part is figuring out the cost and the long-term maintenance and then comparing that to some other SaaS platform. If you look at Magento, in the sense of just, “Hey, I’m going to turn it on”, just like you turn on a SaaS type of thing, it’s no more complicated or less complicated than it would be just turning on Shopify. The hard part is that you can do whatever you want to it. And as soon as you tell somebody, “yeah, of course, you can do that, but it’s going to cost this much money”. They’re like, “what? No, I want to do it though. And I don’t want it to cost any money.” 

Jisse: So the difficulty is always like technology is maybe open source and it’s all available without the price, but there’s actually a huge price in there and that’s the customization bit. But I think that most of the clients out there looking for a project don’t know about the technology at all. 

So instead of actually selling the technology, Hyva people are saying that you can’t build a fast shop with Vue Storefront, or I don’t believe when the people of Vue Storefront are saying the same thing about the alternatives. All of those technologies nowadays are leading into faster front ends anyway.

It’s just that the technology and the agency are Tightly connected. And that’s where current diversity comes from in the current community as well. Different people, different needs.

Brent: The reality of it is that the client is going to care about the amount of time it takes to build it, the speed of the site when it’s done, how much it costs to maintain over time, and then finally, what are the features that are there without having to do anything? And then what features can I make at some reasonable price? Those are really good indicators of what, as a salesperson, I’m going to tell the client. It is up to the agency to spell out that Magento is going to cost this much to maintain the less you do to it, the cheaper it is going to be to run it. If you just get Magento out of the box [it’ll be cheaper]. If you attach something like PWA studio or Vuestorefront you’re essentially headless, and once Magento changes, if you don’t add a bunch of modules, you are almost like a SaaS platform. You could run Magento on the back without ever having to touch it, just do the standard upgrades and run your front end the way you’d like to run.

Jisse:  That’s still an option for headless. There are agencies out there that want to specialize in Magento, but others are just, open-minded more than that, they also want to take in other competitors of Magento. But I think that there’s so much change and that therefore a lot of people in the ecosystem of Magento are confused. Like, where should we go next? And what’s going to happen? But I was just reminding myself that in the past, we had the same points where Magento 2 was introduced and we needed to migrate to Magento 2. But then with a stack that is much more complex with a front end is still dead, slow, and outdated and there are so many things wrong with it. We still managed to do all of those different projects. We still managed to sell all of it to the clients as well. So apparently we could still do that with the new upcoming front-ends as well. 

Brent: We launched a project when Magento 2.0 came out. It was November of 2015 when it was started and we had a project live by January.  I won’t say who it was but it was very difficult.  We definitely looked at Magento 2 as being bigger, better, faster, more features. And there certainly were more features but it certainly was bigger, and faster was still coming. 

Jisse: Overall I, and we think that the challenge of the upcoming time is not going to be how good the certain technology is or which PWA is going to win the battle. I think they’re all going to win. The more difficult thing is for each developer for each agency, but also for each client. Is to make the right choice in the right way. The bottom line is that it’s not going to be easy, but definitely, it’s going to be offering more opportunities than before because basically all of that wonderful technology is now at our disposal, which is true.

Brent. Regardless of whether Hyva is better than Vuestorefront or PWA studio, it has sparked some excitement in the community and we’re talking about it now. I would suspect that we’re going to see more people talking about it. Your blog post summarized it very well by saying  “Get a React developer to do React”. Don’t try to just instantly convert a Magento front-end developer to React.  I’ve made that exact mistake. We’ve just put people on those projects saying “it’s just JavaScript, just do it”. It’s not actually listening to them.

Those types of things from a technical side are a great place to start and a great place to do it. The challenge is making sure that if you’re going to have some developers that are specifically doing something, then it’s harder to get them to, at some point, be redundant.

Jisse: Yeah, exactly. And that’s, I think one of the points too is that the technology stack is just growing and it’s not just Magento or React or Vue, but it’s also an elastic search. It’s also all of those other microservices that are currently being adopted by Magento. Put together, you can’t be a real good full stack developer because the stack is too full. So that’s, the stack is far too large to have that knowledge and to be good at everything. So sometimes I’m getting an email from people promoting their services because they’re good at everything.

So they are specialists in all things. But actually a specialist at nothing.

Brent: It does lend to the whole idea of how do you get somebody into Magento so they feel comfortable? From a technology side and talking to a client, you can’t make it overly complicated. Some of the ways people are approaching this are wrong right now to get people into Magento. Sometimes you’re explaining too much. There has to be a different approach and there has to be a different approach, even from the Vuestorefront and PWA sides. There has to be an approach of having some buy-in from Adobe from an agency side, I don’t see a lot of PWA stuff happening yet. I know that there’s JH and there are some agencies that are doing PWA studio. But honestly, I don’t see it. I don’t see hundreds of stores going out there getting launched every day when that’s what should be happening.

Jisse:  The question I still have is: Is it still not happening because people don’t get PWA or is it still not happening because nobody was actually waiting for PWA they were waiting for something like Hyva. But likewise, a lot of people were on Magento 1 waiting for Magento 2 to improve in a certain way and then it didn’t happen. Because they were simply waiting for the wrong Magento 2 version. So Magento 2 is a different approach, a different technology, different strategy for dealing with things. And that’s something we need to accept. So for PWA, I personally believe that PWA studio and Vuestorefronts are more than ready. It’s just a question of are you expecting full features of everything that was there in the past with Magento making Magento so complex or are you just waiting for those core features that are well-supported just to have an easier platform to build your own features in an easier way. Lowering the barrier of new functionality. So it’s just a question. What are we waiting for? And I, at least I see also the benefit of Hyva which is that we’ve got this alternative, which resembles Magento so much. But now done properly in a modern-day web environments with Tailwind CSS and Alpine JS. So that at least the performance is good already out of the box. But it doesn’t mean that PWA is not going to happen. It’s just that  PWA is not going to happen for everyone. 

Brent: It was great talking today. I did have a couple of questions from our team. They wanted to ask you one question from Madeleine Anderson was when are you moving to Minnesota?

Jisse: Currently we have a situation with a pandemic happening all over the world. So I think that maybe we postpone this question for next year 

Brent:  And just my comment is we had two weeks of minus 20 Celsius straight without ever going above minus 10 Celsius. And it seems like a great place to live in January.

Jisse: But still you, think, I think you are still electricity, right? 

Brent: Yes we are very accustomed to very hot and very cold. We had another question from our Latin team and they want to know if you like tacos. 

Jisse: I do. 

Brent: Good. We’ve covered all the important points in our webinar today and I’m super excited. Anything that you wanted to say about Yereo? 

Jisse: No, not really except maybe if people are interested in reading that blog. So I’m personally seeing myself as a happy developer guiding people in the relevant technology and personally, I’m just happy to dive into Hyva, but I’m also happy to dive into a PWA studio and Vuestorefront. So come talk to me if you also want to debate more or all about this because the more discussions we have about this the more healthy the Magento community will get.

Brent: I can’t agree with you more about that. I think that regarding some reinvigoration into the community. This is a great time to start. Soon we’ll be able to travel and soon we’ll be able to have our in-person conferences and hopefully Mage UnConf will happen this year. I don’t know if it’s going to, 

Jisse: Mage UnConf Minnesota?

 Brent: No, is it already canceled for Germany? It’s usually in September, October, or November?

Jisse:  I don’t know whether something is going to happen there or not but I can maybe also still promote that Reacticon is going to happen for the fourth time and it’s definitely not going to be in person though. It’s going to be online. Just like the previous time, free attendance to anyone. And it’s going to be focused on all of this front-end stuff and more. Like the proper pronunciation of Hyva

Brent:  My react to that is that I’m viewing that at a new angle now, and I’m excited for Reacticon 

Jisse: Mic drop. Perfect ending

Brent: All right. Jisse Thank you. 

Jisse:. Yes. Thanks for having me. 

 Brent:  We’ll do this again. We have so many more topics now that I’ve thought about as we’re talking here and again, I’ll post the link to your blog posts in the show notes and we’ll link it directly to there. I feel like everybody should read it. And it was a great summary of those three technologies

Jisse:  Awesome. Thanks. Yeah. All right. Bye. Thanks for having me.

Wow, you read the entire transcript. Not sure if anyone has done that. Some of the keywords that a service is asking for is speed vue banner stand. Why it wants banner stand or retractable banners is beyond me. Serriously something wrong there. More likely that vue file and the import vue function for the js file is way more important.