We are joined by Yoav Abrahami, Chief Architect and Head of Velo to discuss the transformation of Wix from a Website builder to an application development platform. Wix Velo enables developers to implement code that runs either on the client-side or on Wix hosted Node server, while constructing the UI using a WYSIWYG page editor. In this way, Wix provides an interesting alternative to app development frameworks such as NextJS and Nuxt.

Hello everybody and welcome to yet another exciting and riveting episode of JavaScript Jabber. My name is Steve Edwards, the host with the face for radio and the voice for being a mime, but you're stuck with me. I'm still your host today with me on the JavaScript Jabber panel is first Dan Shapir. How you doing, Dan? Yeah.

Hi, I'm doing great. Coming to you from Tel Aviv, where it's still relatively warm and sunny, still going to work in a t-shirt, so life's good.

Oh, I feel your pain. I really do.

Ha, for sure.

Right here, it's down in the 30s Fahrenheit, which is, I'm not sure where that works out. I think it's about zero close to zero Celsius. So it's been a bit chilly. And after the very, very long and late, warm summer we had, it's even fall we've had. It's a shock for everybody, but enough about that. Also with me on the panel, AJ O'Neill coming as live from somewhere other than normal.

Yo yo yo, coming at you live from the Vertigo Room.

The Vertigo Room.

Yeah,

That's right.

It gives

AJ,

you vertigo

you see.

or supposed to give us vertigo?

You seem to be under construction, AJ.

kind of sort of, but so I'm in the tough shed now, but

the

it,

tough shed.

Ha ha ha!

that's the brand, it's called Tough Shed.

And coming out also live from Tel Aviv in Dan's neighborhood actually is Yoav Abrahami. How you doing Yoav?

I am great, happy to be here.

Thanks for coming. We're glad to have you too. So before we dive into the topic of the day, could you give us a little intro about yourself? Tell you who you are, what you do, where you do it, why you're famous, why people should give you money, etc.

So I'm working in Wix for the last few years. I've actually interviewed the first back-end developer in Wix in 2006 and joined for a few months in 2008 to solve their scalability problem and since 2010 I'm at Wix, officially Chief Architect. Being there I've done a few things like introducing continuous delivery and TDD into weeks, getting Scala as the main back-end programming language, which was a great decision at the time. I've

Ha ha.

created the Weeks Up Market and learned a lot from it. And in the last, in recent years, I'm working on the Velo Project and the Velo platform.

Okay, so Velo is what we are here to talk about today. And I'll let Yoav get into it. But first of all, I'm curious to hear about the name. So for me, when I hear Velo, I think Velodrome and Cycling, Cycle Racing here. And so I'm going to go ahead and say, I'm going to go ahead and say, I'm going to go ahead and say, I'm going to go ahead and say, I'm going to go ahead and say, I'm going to go ahead and say, I'm going to go ahead and say, I'm going to go ahead and say, I'm going to go ahead and say, I'm going to go ahead and say, I'm going to go ahead and say, I'm going to go ahead and say,

Really,

I'm going to go ahead and

you

say, I'm

have

going

something that you think about when you hear Velo?

Yes, I do. Velodrome for weird things come to my minds when I my mind's mind. I only have one actually,

Yeah, when I hear

although

velo,

my wife would

I think.

my wife would dispute that. But anyway, yeah, so I think Velodrome, what does the name vello come from?

So I have to say, I'm a mountain cyclist, so I know Veloform, cycling as well, but the name actually comes from Velocity in the ability

Ah.

to create web applications in a faster way.

Okay, so Velo is the new development platform that they're working on at Wix. So tell us all about it.

So there's a few ways to actually try and explain what Velo is. The easiest way is it's basically taking weeks and taking a cloud and meshing up together and getting a platform that is aiming directly at creating web applications. But I'll try to actually look at it from another angle. When we created the app market in weeks in 2013, we've created a way for partners. to create applications that can be included in a Wix website, SI frames. And the next thing after creating that mashup, and we have lots of partners doing that, was to create a platform for those partners to build their applications on that platform. So the first thing we tried was we looked at those applications, we've seen that most of them are just integrating third-party services and storing some configuration information. try to create a generic backend that will just be a proxy for that backend services and provide them with write cross-domain and credentials and stuff for the website and guess what that failed The thing we learned from it is that when you want to build a web application, you must have a database and you must have a backend. You must have a server that you can actually code. So the next problem is how do you create a platform when someone can actually run code on backend code on your platform and do something that makes sense, that is safe, and scale that up.

And this is where it comes to the idea of let's build a cloud. round

up, which is basically no.js, MongoDB, an online development environment, and Wix to draw the user interface, all of it pre-integrated so that you can just start it up and code and be running and deploy in less than a minute.

But

And this is basically what we're going to do.

if I can pull us back a little bit before we delve into those technical details, if

Mm-hmm.

I ask most of our listeners who know what Wix is, and I assume many of them do, but maybe not deeply, most of them know it as a whizzy Wig environment for easily building web applications without coding at all. I don't need to know HTML, I don't need to know CSS, don't need to know JavaScript. I can drag and drop my way to a fully functioning website, even with relatively advanced features and capabilities, like e-commerce, and a forum, and booking, and stuff like that. And you're talking to us about a development platform. Now, you came at it from the direction of the app market, which is the way to extend the way environment with additional functionality beyond that provided by Wix, but why would a WYSIWYG platform be a development platform? Like what's the motivation here?

So that is a very good question. Let's look at the market of building frontends. On one side, we have tools that build websites, Shopify, Webflow, Wix, and all kinds of other platforms. Those tools solve a real problem. When you want to build a website, you need to take care of lots of different concerns. You need to take care of things like a performance and a CDN. and SSL, web security, being responsive, GDPR, PII, cookies, accessibility, and the list just goes longer and longer and longer and each year it becomes more and more complicated to build a website. So if you don't have a platform, you have a problem. Now on the other end, we have developers and they're getting requirements to build things like let's say renew your insurance. your ability for your customers to renew their car insurance, or your ability to go into your bank website and transfer money. Now, a lot of those things are actually customer facing. Those are customer facing applications. They still need the same support you get from the website. So you still need to think about GDPR and accessibility and web security and responsive, NCDN and all those other concerns. But you need those code your business logic. You need the ability to connect to your backend services and build that application. And this is the unique offering that we can provide with Velo. On the one end, we get that foundation of a website builder. We have everything we need to be a customer facing application. On the other end, we have the cloud, so we can have all the abilities to integrate and build that application, that business flows and that business entity that integrated through an API gateway with your enterprise.

So when you started your description and you were talking about the app market, if I'm putting it in the context of the drag and drop that we talked about before, what that really enables and in that regard, it's really similar to the app market that you get from either other platforms like the ones you mentioned like Shopify or maybe even app market for mobile devices is the fact that third parties can provide functionality beyond the one that's offered by the platform provider itself. So in the case of Wix, Wix might provide its own functionality for blogging, but you gave an example of something having to do with insurance, maybe Wix did not develop something for integrating with, of providing insurance like services. So somebody, a third party that does specialize in that can come in, build an application integrates into Wix and then a Wix user can use drag and drop functionality from Wix, but also integrate that, again, using drag and drop. So is Velo really intended for the people building those third parties to make it easier for them to build better third parties? Or is it targeted at the Wix users themselves? more sophisticated

Thank you.

functionality beyond what you can do with just drag and drop pre-built components.

So that's the most interesting thing. Velo was created from us learning from the use case of the app market. But Velo today is a tool for a weak user or a group of weak users to build their own application. Be that building a very complex website, be that building a startup, or be a part of a larger organization and exposing that organization services So we started from learning from one domain, but we actually, where we are today, is a totally different domain. It's a domain of building any kind of web application, and we're utilizing both the drag and drop interface in all of the foundation we get from Wix with that ability to customize it and actually code and build the application on top of that. So we're going to start with the application. We're going to start with the application. We're going to start with the application. We're going to start with the application. We're going to start with the application. We're going to start with the application. We're going to start with the application. We're going to start with the application. Done? We don't hear you for some reason.

Yeah, it doesn't help when I'm muted.

Yeah.

So if I'm looking at it from that perspective, so again, when most people think about Wix, they think about it as what is known as a no code platform. I can, like I said, I can drag and drop my way into a functioning

Thank you. Thank you.

website using the collection of pre-provided pre-built components. What you're describing is something different and kind of competes or is an alternative to development platforms or development frameworks kind of like on next.js or a Nox or or a remix or stuff like that to an

Exactly.

extent at least.

Exactly. When you think about it, if you go take Next.js, Next. React, or anything like that, and you're going and building a web application, take Create React app. You run it, wait like five minutes, 10 minutes for all of the NPMs to install, and you have a running React application on Node.js. But at that point, you need to start designing. Create handling, cookies, GDPR. of all of those stuff. So you have a lot of things to do there in order to create the application. In Wix, you can go into the Wix editor, draw your application. Actually, what we see a lot of users doing, they let their designer draw the application on Wix. And then the developer just wires things up, creates the backend, creates the logic, create all of the things that the developer does, and they have an application. Click a button. It is deployed globally on four data centers continents and you get a production application running.

But so here's the thing. You know, when I think of a web development platform, I usually think of the ones that I mentioned. Of

Thank you.

choosing a framework being React or View or one of the new ones or relative new ones, the meta framework, which basically automates the process of deployment and builds the route for me and does the backend. And usually these days the meta framework providers also provide the deployment services like you mentioned, CDNs and integration with the cloud. And those are the platforms or frameworks that I usually think about. So effectively what you're saying is, one that you should consider called velo by wix and you should be thinking about using velo instead of using say next.js. Correct?

Yes. And you like anything in the world, you have a trade-off. And the trade-off you're making when you're choosing a platform like Velo, Velo is a very opinionated platform. That means that we can give you a much more efficient platform. That's why you can actually get from a start to production you can draw DUI instead of code DUI. So we're solving lots of problems on the way. But that means that you're working on our platform, which is a very broad platform. It is very opinionated. You're up to the level that up until about a month ago, your only option of using our platform was using our own online ID. Even that level of having everything preintegrated. By the way, today we've opened that, or a month ago, we've opened that.

But I still believe that at the end of the day, a Velo application or web application must be deployed on the Wix platform. It can't be deployed somewhere else.

Yes, that is right. And that is again, one of our advantages. By having the application deployed on the Wix Cloud, it means that we can manage all the aspects of the life cycle of the application. It means that we can make sure that it gets the best service in terms of media, CDN, traffic, in different geographies. It means that we can automatically update the application as regulations change or as browser change. roll out more optimizations into the application in a seamless way and that that's what it means to be a managed service. You get a lot of service for that which otherwise you would have needed to manage yourself.

So before jumping into the services that you actually provide, I think it might be beneficial to describe maybe the process. So let's say I'm a developer listening to this podcast. I think, hey, this sounds interesting. It could be nice to build the UI for my application using drag and drop and then hook in the functionality. But how do I try it out? go about it. What does the process, like you mentioned, if I'm doing React, there's the Create React app. If I'm doing a next JS, they have the way to create a new project. How do I start a new project in the context of Wix? You just said that it's really quick, but how do I do it?

So the process of starting a new project in Velo is pretty simple. I think you'll need to register to Wix, which is probably the hardest part in the process. Once you've registered, just open any template of Wix in the Wix editor. At the top, you have a developer mode, turn it on, and you have an ID. With that ID, you can start writing front end code, you can start writing back end code, which runs in OGS. You can start creating the collections in a database. and you can start utilizing any of the different features we have in our product. Click on publish, it's running. I know it sounds strange, by the way, you click on a button and you have a running application because the one thing I didn't say is a build step. The build step is actually managed for you as well. So when you click on publish, your application is running in a matter of less than a second.

And the code that I write, do I write it in JavaScript, in TypeScript, what do I write it in?

So the code you write is JavaScript, both front and back end. And the one thing that is a little bit different is that you cannot use the DOM directly, you use our own abstraction on top of it, the Wix components, because when you think about it, when you use Wix, you draw the UI. So you drag buttons, you drag inputs, you drag boxes, you drag galleries, you drag any kind of element on the page. And once you do that, you get an ID So for instance, if you want to click off a button to change an image, you would do on button, the button on click and then maybe the image.src equals something. And both would be accessed through a Wix API.

To be honest, it isn't that strange because, you know, again, when I'm coding in using a framework like React or like Vue, you know, the idea is usually not to directly access the DOM. You use

Thank you.

whatever

Bye.

services those frameworks provide, you know, whether it's React, so you use JSX, or whether it's Angular or Vue, and you use their templating languages, you know, you can circumvent it. the framework and go directly to the DOM if you want to when you're using these frameworks. But it's usually not recommended. You do it when, you know, as a sort of an escape hatch, usually, like when for some reason the, the, the, the indirection layer that you have in place isn't sufficient and you need some functionality that isn't exposed. If I understand, though, correctly what you're saying, that in the context of Velo, it's not that you, you, shouldn't directly access the dome, it's that you cannot directly access the dome at least in you know directly or it does this easy way

Well, well, the fellow is built so that you will not access the dome. However, like anything else, there is an escape route. You can actually create a web component and when you do web component, you have full access to the dome. It actually runs native on the page. So

Ah, okay.

we have the flexibility. The

But I guess that in most cases, you actually, again, you don't want that because you want to work with the APIs of the various Wix components that you put on the page using that drag and drop capability. So, that's it.

Exactly. And by the way, the reason why you want to use the components is simply because it's the most effective way to do to build the user interface. You just think about creating any kind of application. How much effort are you placing in positioning your different inputs and groups and titles in the right place, choosing the CSS, choosing the right formats, all of this stuff. In Wix you can do all of that in the user interface with direct feedback. You just draw the stuff and you can even let your designer do that. You know directly

Well,

on Wix.

yeah,

So

that's

all of

the

it.

reason that most people who do work in those frameworks usually use some sort of a design system, which kind of enforces certain layouts and certain design choices like fonts, borders, colors, etc. You know, you usually try to avoid customizing them manually for each and every component.

Yeah, that's the right way. And when you use Wix, you get, in some countries, equivalent. All of our components are actually, you can call them design system, but in fact, they're much more flexible than the design system because you have a lot more control on how they look and feel of those.

So can you give an example of some of the components? I mean, you know, I assume they're the obvious ones like a button or or or some or a text block. But you know what what do you have beyond that?

So let's see which components we have. So we have, of course, text and image and gallery, which is very rich gallery component with lots of options. Obviously video, music, shapes, buttons, groups. We have a repeater component, which you can design. One instance of the repeater. for each item in your data that you provide to it, it would repeat that representation as many times as you want. You can use that in a flex layout or a grid layout. You have a mega menu which you can design. When it opens, you can design each tab individually. There is a tab component. There is a full suite of input components, like a text input, a drop down, boxes, slider, rating component. Of course, you

can use an iframe, you can create your own using a web component. I think there is something around over 100 different components in the Wix environment.

And I guess that some of the components are fairly advanced. Like if I'm thinking about, I know that Wix has functionality for e-commerce and like I said, for booking and events and stuff like that. Do these also constitute components or are they built from smaller components? How does it work? I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know.

So let's first talk about the business solutions in Wix before

Okay.

going and track them in the editor itself. We have introduced about a month ago. By the way, about a month and a half ago, we had our first developer conference in New York for Wix. In that conference, we've introduced three new products. One of them is a Recon platform. The Wix Recon platform is taking are different business applications in the space of booking events, e-com, and connecting them all together so that in one cart you can actually check out with both an event, a booking of an appointment, and a product. That's by the way something that I don't think I've seen with any other competitor. On top of that we've added lots of extension points into are different business solutions from the ability to connect your on payment provider to customize DAX, customize what's called additional payments on a cart and so on. There's like, we call those SPI service, a programming interfaces, kind of the vice versa of APIs, and they allow you to go into Velo. and write basically a JavaScript function that would implement a certain API and then have the Wix business applications call that when they need it. For instance, to carry it your own custom payment solution, let's say you're doing a game and you want to have your own game coin and allow people to check out in your store with your own game coin, you can do that. So all of those are constitute into our business API starting from simple CRM solution, a global payment solution, stores, booking is three different products, appointments, courses, and see always forget the third one. Events is another three products that are connected there, which is you have events, tickets, sitting plan, and so on. And all of that is connected together. Now, when you use any of those applications in weeks, user interface for the full application. That comes from the Wix No Code product. So when you do a store on Wix or a booking solution on Wix, you get the product gallery or the service gallery and the service page and all the checkout flow. And if you have both of them, of course, it's unified checkout flow. And when you're using Velo, you can then customize that experience. You get more options to customize and extend those experiences. So you can start doing some really really cool stuff.

Now you mentioned, and again I'm kind of jumping back and forth as

Thank you.

things

occur to me, you mentioned that code, VeloCode runs both on the front end and on the back end. Now in the front end, I guess it's kind of easy to understand. I mean, I think you kind of described it that it's a development model that's kind of similar to working with the DOM that I can, let's say if I have a button element, I can connect the JavaScript function to the click event handler and run functionality on the client side that I think is fairly straightforward. And then I can once I intercepted that click event, I can modify various properties, I guess something like the background color of the button or the text in a text box or whatever. But you also mentioned that I can run code in the backend. And that usually involves acting with, you know, various other services or reading and writing stuff to database. I know that AJ, for example, is like a fan of certain databases. Remind me which databases you like, AJ.

primarily just Postgres

But...

and SQLite, but that's more for embedded applications, not for general applications.

So is that also the case for back end code in Velo? I mean, is it also for managing data and interaction with other services? And is there a database functionality? If so, which database? How does it work? So, yeah. 

So one of the things that we've learned when we set out to, even before we set out to do Velo, is once you build an application on the web, you must have a backend and you must have a database. Otherwise, you're actually very, very limited in what you can do. So the first challenge for us was to figure out how to do that at scale. Today, we offer with Velo a Node.js server that you can code into. You can run, you can actually write the code that runs into that Node.js server which is per site. We're running roughly around one million containers every day. We also offer you an abstraction which today is over MongoDB, the Wix database. Roughly we have around 60-70 million tables there, roughly in terms of numbers. And both of those are bundled with Velo. Now Node.js being Node.js, you can do anything that Node.js is capable of doing. You can install NPM packages and we give you a certain set of services from Wix on top of it. So we do give you, of course, an API to use the database. You have a scheduler API. You have an API to expose a function to the website or the client. And then in the client, you just call that function as a function. and that function will be executed on the backend on Node.js. We're doing all the magic to make that happen. You can open APIs to the web. We call that feature HTTP functions and just call them using curl or any other system. You can call a various weeks business applications APIs. We have, I don't remember the exact number, but it's probably in the hundreds of APIs you can call from create product to start payment to whatever and you can listen on business events like a cart being checked out and run code on that event and react to it in some certain way. You also have a socket solution that your backend can notify the client or certain clients with events. So you have a full suite of services there. on dotbeckham.

If I contrast that to, let's say, Next.js. So Next.js, you can obviously run the Next.js server in a node environment. But I know that Versailles is pushing very much a serverless type of an approach where you're running, you're invoking stuff like functions that can run

either on the back end or even in, you know, now they're kind of introducing edge computing as well. What I'm hearing from you is that it's more equivalent to the node type approach of basically you've, it's not just a function that starts and stops and has really limited API. It's more like a node server or, or, or is it more than that or different than that.

It is a full node server. I think it's right now, it's version 16 or something like that. But basically it's Node.js. One thing that we're doing, we're not trying to invent new APIs or new paradigms when we don't need them. Node.js is a great paradigm. It works great on the backend, especially for web workloads. And by using it directly, we give a lot of flexibility to our users. But maybe it's worth mentioning, when you hear about AID or giving an OGS back end and running it as a container, it probably costs a lot, because the container per month is like 10, 20, 30 dollars. You can't get down from that price point. We're doing it at 0.2 cents. So that allows us to run, that's one of the innovations we have in our product, it allows us to run in a much more efficient and much more resilient way, a full Node.js backend for site in such scale, to a huge scale.

So if I built my backend, my web application that has a front end and a back end on top of Wix, and I'm writing my code in Node, how many nodes backend servers do I get and how much does it cost?

Right now, Velo is free. It's part of Wix. We're allocating today for most users up to one container. The reason why I'm saying up to one is because we're actually, most of the time, the container is going to be not running. When you need it, it will be available in 20 milliseconds, so you don't care. And if it dies, you get another one in 20 milliseconds. So again, you don't care. And if you get enough traffic, We can scale you up to more, you know two three four as much as you need If we'll get to that point We might be asking you a what you're doing. There isn't why I saying that in most web workflows You will never need more than one container You know in order to get to just to give you a sense of what I mean there In order to generate traffic that is over the ability of one node. Yes to handle probably two or three, probably half a million users a day to generate that level of traffic. And Node.js can handle 5,000 RPM easily, unless you're doing something really, really suspicious. And to generate 5,000 RPM, you need probably half a million people for regular web workload. If you're doing something different, which is something that requires more, we have the capability to give you that. And we have all the infrastructure to have a full, what's the word, full elastic solution on the backend. Basically you get a, the way it would work is that you have a scaling group that is allocated to the site and we know how to allocate the resources.

 

AJ, that kind of resonates with what you keep telling us about the fact that you can, you know, you like to run your note servers on digital ocean and basically just use that one note server to handle as many users as you're ever likely to get.

Yes!

Ha!

That's what I'm saying.

Thank you for that detailed answer.

Yeah.

Ha ha. Um

Yep.

And you said that in terms of database, you've implemented a layer above, you said Mongo, I think MongoDB you said.

Yes, right now we have a layer on top of MongoDB. But we also have a way, again, it's an SPI, a way for you to plug your own database backend. So if you need a different kind of engine, MySQL, Postgres, SQL Server, a Spanner, BigQuery, anything like that, an open source adapter that you can install on your cloud, it exposes APIs that we know how to call and once you do that from the Wix side it will look like a native Wix database but the actual data would be stored and managed on your database so you can go and do whatever optimizations you need you can talk about we can talk about regulations if you need to store data in a specific location or if you want your to be in your own project and owned by you and not stored on Wix. And this is one of the flexible things that allows us to not have data at rest on Wix when we don't need it. And you can have your data at rest in your own project on your cloud.

But again, the Velo solution as well as the Wix site itself that Velo is implemented on top of, all of that is hosted on the Wix servers, on the Wix infrastructure.

The default one is on Wix infrastructure, Wix servers, which are running in, I think it's four or three different data centers. We always have the, in terms of how Wix works, we always have the ability to fail over between different regions. So if let's say our US East region fails, all of Wix will shift to ES to West or to EU and that includes the databases that are provided by Velo.

Now, if I take us back to the workflow, if I'm again comparing this to the way that, so for example, currently at the company where I work at Next Insurance, the what we call the public website or the front end part of our offering, the public part of our offering is implemented using There are something like seven developers who are working on this and they all have The next environment installed most of them are using visual studio code. I think a few might be using IntelliJ and you know pulling and pushing things into into github and and using Jenkins for automated builds and and and and there's the end-to-end test environment, and there's using Cypress for end-to-end tests, and it's fairly standard and straightforward configuration. If I'm working in the Wix environment, how much am I using Wix tools versus how much do I use the standard tools like the commonplace or the open source tools, ones I just described.

Just before I answer that, you said you have in your team seven developers, right?

In that particular team, yes, I think, yes. Six or seven.

and how many designs

That's a good question. I don't remember off the top of my head. I would need to check. I don't remember. I don't work with the designers usually, so I'm less concerned with that part. I don't

The

know. I don't

reason

know. I

why

don't

I must...

I don't know.

I understand, but the reason why I'm asking is because those designers are actually part of your team. The development team is starting from design, not from development.

Oh yeah, for sure, they get designs built on Figma and they need to implement them in code. Yeah, exactly.

So the workflow we're using is different. There are some similarities and some different things. The most important difference is that the designer is part or can be part of your development cycle itself. The designer can actually use the Wix editor and implement their designs on Wix. They will still use Figma. You know, Figma is probably the best design creation tool. It's amazing I'm using it myself. But then when you need to implement the design, instead of the designer explaining to the developer, and then the developer needs to implement that, and the designer needs to go and check that they implemented it in the right way, all of that end over and back and forth goes away. Because the same designer who created the Figma design can open the Wix editor and just draw that same design on Wix. And if something doesn't work out, it can fix it. that you can actually find out to implement it in the right way that actually works. And a lot of times you get that feedback that will start to implement your design, it's not really the same way as it is in Figma. So that is one big difference from how you work in regular teams or let's say non-weeks solution. From that point, you have a choice on weeks. The developers can choose to work online in the weeks online editor with of the tool chain that we provide at Wix, but they have also another option that we introduced about a month ago. They can connect that same project to Git, and then they can go and check out the code from GitHub, use their own any ID, use the Wix CLI, create their own preview versions, and then run them through a CI pipeline with Papetier or any other testing tools like that. And then they have a command in the Wix CLI to actually do the which is basically equivalent to clicking the Wix publish button, with one major difference is that the version that is actually written, both of the code and the UI in your Git commit, is the one that's going to be created and deployed in Wix. So what you get with that is that a very similar workflow for the developers, in that case, from what they're used to doing, but you get the benefit that you also have a pipeline for the designer to join that.

And if you're thinking about the type of companies or the type of solutions or the type of offering that are appropriate, I mean, are we looking at specific types or sizes of websites? Is it more appropriate for smaller websites? Is it also appropriate for large scale websites or for certain types of websites or certain segments? What's the target audience? Thank you. Thank you.

I think the target audience is not about which company, most companies, if not all, can benefit from the Wix platform. It's actually more about what you're doing. If your company is building an online 3D game in the browser, then the online 3D game itself, we don't have a lot of benefit on that part. But all of the other 50 screens you probably have around that from the leaderboards to user registration to payments to anything like that. This is where we have a lot of advantage. And so like anything in the world of tech it's not about using one tool. It's using the right tool for the job. And what we offer is a very productive tool to create UIs that are facing customers on the web up to probably 95 90 90 of the use cases. But we don't try, at least not at this stage, to do the 100%. There are still lots of things on the web that you would probably need to go and code. It's just the same way as... you would use higher level abstractions like JavaScript or Java or Scala in our case for lots of use cases but in some cases you need to go under it and do something more than that. So I would say that in terms of companies that can benefit from what you're doing, anything that comes from the PHP background definitely, you know WordPress and some of the other CMS systems. Anyone that is doing a Anyone who is doing a mid-range in terms of agencies and companies that are selling products as part of their solutions, think about... One example they've seen is an agency that has an application to rent golf courses. In that application, they've been installing that in hundreds of different golf courts websites. That's another example. Another example that we actually, one that we know from here from Israel, is quite a few startups that are using our platform. is a startup that is tracking a fleet of trucks and in the truck itself they have a device that sends information about the location of the truck back to a velo backend and then they're using velo to give a municipal. There are so many examples trying to figure out which one to talk about.

But the reality, if I'm thinking about it, and I actually wanted to ask you, Steve, something about this, because at the end of the day, the majority of websites, from my experience, I mean, we can talk about edge cases, but the majority of websites out there fall into, they mostly do the same kind of things. They're mostly kind of front end for a crud backend. You read stuff from a database play it as some sort of a list or table or whatever, or form, and the user fills in the form, and the data gets saved back to the database. At the end of the day, the data might represent different things, but at the end of the day, it's mostly this. And Steve, I know that you build these kinds of applications a lot. Would you consider something like Velo instead of whatever frameworks you're using today?

I think it has something to do with a combination of things, whether it's personality, whether it's skill level, whether it's what you like to do. So the first thought that comes to my mind, I guess, is how much I'd like to know about the details of what's going on and control it. So you see a lot of no-comers. code platforms out there and platforms that people can use who are not skilled to drag and drop and to just create a quick website where they don't know what's going on behind the scenes. That'll drive me bat blank crazy. Can't do that. I like to have control over my data about how it's being stored, how it's being associated, and so on. So I think the best analogy that I can give That illustrates what I'm talking about is from a language standpoint and I may have given this before so apologies if you've heard this all before But when I learned foreign languages, you know, for instance when I learned Spanish When I was growing up You know, there's two ways that you can Learn language, you know general for the most part that I've seen people learn languages like that One is to take a language course and learn your verbs your nouns how you conjugate all your verbs the different forms or vocabulary, all the different structures, and then you take that as a structure and put it together. Versus someone who learns like what we'd call conversational Spanish, you know, they learn the phrases, they learn, you know, what's commonly used, how can you have a conversation with somebody, what are the basic words, and then you could sort of learn from there. I couldn't do the conversational. I got to know the details. I got to be able to control the nitty-gritty, what's going on behind the scenes. And with some, you know, When I first got into the front-end JavaScript apps, I liked the ideas of the HEPA CMSs, right? Contentful, sanity, butter. There's a bazillion out there now. And they work to a certain extent in that they allow you to control your data structures and your modeling and so on. But when it comes to a hardcore crud app, maybe some sort of management portal, data management portal, I don't like them because there's too many things I control on the back end. So not sure if this is answering your question, but for someone who has specific skills and abilities and technology familiarities, I prefer to stay with what I know and have the control over them versus maybe using a technology that I don't like or like dealing with or so on. For instance, at the beginning, you mentioned you were using Mongo as a database for something like this. And Mongo has its pros and cons. And AJ and I have gone back and forth on this multiple times. I think his quote, maybe he's changed over the years. I really don't know of any use case where you need Mongo. I can speak from personal experience with the app that I use on a daily basis and other platforms that we've dealt with, such as Form.io. It's been a while since we've had Travis on, where that comes into play. And it's useful because of dynamic structure of the data and being able to adapt for that. But other than that, I really haven't seen any benefits to it just because of my day-to-day use of it. In our particular work application, sure, it's great. There's specific reason for it. But something like Mongo would sort of scare me off. And again, it could be just my lack of familiarity with it with it. And if I were to get more familiar with it, then I would be more comfortable. But. just being the person that I am and wanting the nitty gritty detail control, I'd have to think about it.

A question about that to you though Steve, because on the one hand what you're saying totally resonates with me because I often take that same approach, but on the other hand when I'm looking at most developers out there, the reality is that a lot of them don't, you know, they might say that they want to control the nitty-gritty, but at the end of the day most of them don't know the nitty-gritty. are working on top of Next.js, for example. Do they know how Next.js exactly implements the routing? Do they know how React actually updates the DOM? They're supposed to not use DOM access directly. They're supposed to go through React, but do they know how React works? And they use React these days because that's what they were taught at the bootcamp. But if they now go and work other shop, maybe that shop might be using Vue. I mean, you're using Vue these days, but if Push comes to shove and you needed to make ends meet, would you not go and work for somebody just because they're not using Vue?

Not at all. In fact, I was in that situation a couple years ago when I was interviewing in about 2020, I went through, you know, a whole raft of interviews and I actually interviewed for a couple of positions where I would have been using React. I liked, I had been recommended to a couple of the companies and I went through the interviews and said I was willing to do it. And I think I ended up not getting it because in their particular needs were that they had somebody that knew React better than I did. could get somebody up to speed in making an impact quicker than somebody having to come in and learn React. But no, if push comes to shove, I'm perfectly willing to learn something new. And I see that as a benefit in terms of adding to my arsenal things that I'm able to do and jump on. Well, right now, if I were to use something, that's React-based like Gatsby, for instance. I don't know React, and so there would be definitely a learning curve there. But to answer your question, no. Personally, I have no problem with getting in and learning something new. And if you got to do it, you got to do it.

So so my point basically is and and I think by the way that you have that this is a real challenge For wix in this context and I'll get to it in a minute But my point is is that in a lot of ways, you know when you think about wix and it's not surprising Because that's the brand that wix is built over such a long time and invested a lot of money in building this brand wix is an easy to use wheezy wig environment for non coders and And all of a sudden you're kind of asking us to think about Wix as something else. And you're asking us to think about Wix as a development platform like Next.js, like a Noxt, and even more so because like you said, there's an integrated database and the integrated scaling and all that stuff. So it's kind of like you take AWS. a headless CMS and you take an application framework and you match them all together, you shake it up and you get velo. So you're kind of asking us to make a sort of a mental shift in how we regard Wix. So it's not really surprising to me that you get a bit of a pushback from Steve because basically what Steve is really saying is I don't want to be using a WYSIWYG environment, no code with the weak environment, I want to be writing the code. And

Thank you. Thank you.

I'm trying to say it more bluntly, I think, being Israeli than how Steve might say it. But correct me if I'm wrong and misrepresenting you, Steve.

Yeah, but again, that's just a personal thing. That's how my personality works, how my thought process work. As with any tool that's put out there, there's no tool that's gonna be put out there that's gonna make everybody happy. And that's the nice thing about having a variety

Thank you.

of

Thank you. 

tools, whether it's somebody that just does it all in the witty wig and it does for you versus someone who likes to piece things together. So

Ah, the steams.

as to the challenge that you're speaking of in terms of, changing wicks from it was known for this and now we're going to do this. Yeah, sure, that'd be a challenge. You might find that you get more people who are coming. It's like, dang, I've always wanted to do this and have a little more control and now I can do it. Hard to say until it's out there a little more.

I have to say that I totally understand what you're talking about. It's... But I want to shed a different light on it. Definitely it is a challenge. But when you go and look at our industry, and you look at our industry over a course of 40 years, 40 years ago we would build our own computers and we would have built our own data centers We wouldn't trust anyone to do that for us. And about 30 years ago, we started IEAR in place in data centers and we would just still build our own computers. And about 25 years ago, the first serverless offering was created, which is called by the way PHP. You would just create a PHP file, upload it to some vendor, and it would run it for you, run the server for you. in 17 years ago in EC2. And about eight years ago, we started with Silverless on a, it was a file base and a parse. And I am out of light for some reason. Can you, out of power?

I'll cred you froze.

I think,

Hello?

yeah, we lost Yoav there. Hopefully he'll be able to connect back. We need to be wrapping up soon, though, anyway, no?

Yeah, I know. Yeah, I was thinking that too, for sure.

By the way, you guys are really, really quiet today.

Well,

I'm

you were more familiar

still kind

with this

of out

so

of

I was

it.

just letting you do the talking so

Yeah, no, I really wanted to pull you in, Steve, because to the great extent, you're the target audience for this.

Mm-hmm.

Mmm.

So why don't you think so?

Ah, well first, first,

And

well

if you don't

first let's

think

get Yoav

so,

Bak. I do have some things that

why

I'd

don't

like to contribute.

you say

I'm just gonna

so?

go ahead and do some of the other things that I like

Hmm.

to do. I'm gonna go ahead and do some of the other things that I like to do. I'm gonna go ahead and do some of the other things that I like to do. I'm gonna go ahead and do some

Yeah.

of the other things that I like to do. I'm gonna go ahead and do

Please

some of the

do.

other things

Ha

that I like to do.

ha ha.

Oh, yeah, well, back to recording is our quality. Ah, credit.

Now he'd be back, I hope.

you Go.

Yeah, I'm still kind of out of it from

What did

having

you

Be

this

have?

in

Did

flu

sec.

you have COVID

and then this

or

cold.

something?

I don't know. I think it's just some kind of flu and then it's just it's snowballs.

Mm-hmm.

But kind of didn't get worse, just got different. So went from being flu to being coughing fits, to being kind of a cold, but still the cough is, some days it's better, some days it's worse.

I'm a COVID virgin and I really need to keep myself

Thank

safe

you. Bye.

ahead of the flight to Australia. The last thing I want is to get COVID like a few days before the flight to Australia and not be allowed

I don't know.

to fly or something.

Oh man, yeah, that would suck. COVID version, that's funny, I hadn't heard that. I am too. Can you check Dan, do you have a way to check with him to see if he's trying to get

To

back

be

in?

honest, I'll see. I'll try to send a message to him. Let me see if I can.

I don't think there's any such thing as a COVID version or

look i might have had covid

rather Corona version. You have to have had it. You have to have.

No,

There's

not

no

necessarily.

way you haven't had it unless

Yeah, there is.

you've stayed in a box and not had any deliveries. 

No, I have not had it. Cause I know it because I like when I donate blood with the Red Cross, they've checked antibodies. I'm not sure if I'm gonna be able to do that. I'm not sure. I'm not sure. I'm not sure. I'm not sure. I'm not sure. I'm not

Look,

sure. I'm not sure. I'm not sure. I'm not sure. I'm not sure. I'm not sure. I'm not sure. I'm not sure. I'm not sure.

my

I'm not

wife

sure. I'm not sure.

had

I'm not sure.

it,

I'm not sure. I'm not sure. I'm not sure.

so I probably had it back then, but I did the test a couple of time and they all came back negative, but those were the home

I

tests.

think the tests are random.

Yeah, those

I

are

think

worthless.

the tests are random. I don't think that they actually tell you stuff because I am certain that I got it back when it first happened, the very first strain before it was even in the news. Like a week before people started talking about it,

Mm-hmm.

I had just a really bad, I was just incredibly

Wait

tired

a minute,

and I was sleeping

I

for

sent

about two

him a

weeks.

message via Twitter and he hasn't responded yet. I'm going to try to send him via WhatsApp. Actually, let me see if I can do it from my computer. Just a second. Okay, I sent him a message via WhatsApp. Let's see if he's able to rejoin.

If we have to, we can just wrap it up from here if she's unable to get back in.

Yeah.

Hey, sorry.

Ah, there he is. Oh, looks like he had to change something.

Yeah, the power outage.

Oh,

Oh no.

that's wonderful. It rains in Israel like a few drops, and then the electricity goes.

Yes, so electricity went away.

And now it's back.

Anyway, now it's back.

So Jo,

And

So

hopefully

where do

if

it's...

we leave

you

off?

were about to respond to Steve's comments, so let's resume from there. And before we resume, just so you know, we will need to wrap up pretty soon. I know that AJ also had a few things to say. And after that, we will probably go into picks.

Okay, so I'll

Unless you have something important that you feel that you need to add.

No, I'll try to do it a bit quicker. I think when you look at, I'll try to answer for Steve. When you look back at our industry for the last 40 years, we are shifting from building our own everything from computers and data centers, then to just computers in a rendering data centers, then to managed VMs, with EC2 and then to serverless with solutions around 2014. And when shifting more and more workloads to the clouds and going upstream, always going in upstream and into more managed, more opinionated and more NIR abstractions. And I think Velo in that regard is the next step in that evolution. you would have built your, you wouldn't even have containers. You just start maybe with a container. And 10 years ago, you'd use VMs, and 20 years ago you'd build your own computer. Today you're still coding user interface. But that's not going to last. Coding user interface is going to, I don't know if it's within now with Velo or five years from now or 10 years from now, but you're going to become much more efficient with much more P&D platforms. And same goes for you do our backend or database and all of the other concerns. We...

I think you're kind of comparing apples and tyrannosaurs here because when we talk about the path to virtualization, it's the same CPU cycles that were happening. Today I could build my own computer, I could plug it into the wall, and there's no difference between the capability that I have doing that versus using a virtual machine. There's no there's no difference. I mean other than that I Get more capacity at a lower cost if I if I plug my computer into the wall But then I have the issues of the reliability,

I have

which

to

is

disagree,

why we had co-location

AJ. I'm going to push back on you, on your pushback. Because you're absolutely correct that as long as your computer runs fine, then there is no difference. But if you need, if there's a problem with your computer, if your fan goes, then you're going to have downtime. Whereas when you work in a virtualized

Yes,

environment,

but this is not the important part.

Why is it not? If you want to update your operating system, you're going to have downtime. All of these scenarios are solved by virtualization.

But I could just swap one computer for another. But the point is that they're compatible. The point is that I was getting at is that it's a standard, right? Once you get to the point of running Node, everything that's underneath of it doesn't matter and you have full control, right? Whether I wanna put another hard drive in a physical computer or whether I wanna attach a storage volume, it's essentially the same thing. I, It's a one to one translation. So yes, I could get more control or get a faster speed. There's some advantage and disadvantage to whether I physically have the computer near me or whether it's virtualized, but it's really just in the noise because it's the same thing. It's still a hard drive, it's still a computer, it's still running CPU cycles. When you move into an integrated platform, and I've been scrolling the docs we've been here just trying to get a sense of what the heck is Velo in a way that I can internalize it. One thing that I really like is that it's kind of taking all of the stupid boring things that you'd pretty much implement with almost no distinguishable difference and it modularizes them into a no-code solution. So we've got Wix chat backend, Wix bookings backend, Wix capture backend, events back end. And so when you look at all this stuff, I think that what I want is the evolution that's like the virtual machine. What I want is, well, I could run this here or I could run it there, but it's just basically standardized stuff. And this is really cool from the perspective of wouldn't it be great if we just had some no code standards of here's the API is for authentication, just these are APIs that are just gonna work 99 times out of 100 and they're portable. But the issue that I have with something like this as a developer is that it's not portable, it's just for Wix. And so whereas, yeah, I enjoy DigitalOcean, but DigitalOcean is both great and completely unimportant because I could just as well use Volter or ScaleWay.

Agile, Agile, I think this is a key point. Basically what you're saying is that you're disproving everything in cloud space except for VMs, and that's it, basically. What you're saying is that cloud should just provide you with VMs or maybe containers, but serverless is non-portable. You can't take a serverless function from AWS and move it to GCP because the API is different. You can take either one of them and move it to Azure and all they're also different. And same goes with

Yeah.

anything. You can take messaging from SNS or SQS or whatever AWS says and move it to GCP. Same way you can't use any of the analytical databases because you can't install them anywhere else. You can't take any of the networking infrastructure of a VPC or anything like Edge or anything like, any of the services. The only portable service is a VM or container. There's nothing else that is portable. You can't even take a workload from Postgres and move it to MySQL. And even if you think you can do that, try

Well,

to...

I wouldn't even want to do that because that's again, that people will equate those as though they're similar, but they're not, they're worlds apart.

So let's take Postgres and move Postgres to Postgres. Even moving Postgres to Postgres from one cloud to another, you might be surprised. You might get surprised when you go to the managed services. So any choice you're doing except building your own VMs, you're going to go into an opinionated environment and that's going to limit your ability to move from one place to another. So you're going to go into a new

opinionated

environment,

is fine, the portability is the issue.

of

It's

opinion.

not that I'm eliminated by it being opinionated. It's that

Yes

it

you

becomes

are.

a,

Yes you

well, yes,

are.

you're limited

Oh.

by something being opinionated, but that's not the true limitation. Because if it was that I could run this same opinionated stack in multiple places, then I personally would feel better about it. I would want to adapt some sort of, I think we should have something like what you're creating that's in the space of an open source implementation where it's, hey, chat is largely been figured out. We wanna know when somebody's typing, we wanna be able to support emojis, we wanna be able to link to an asset, we wanna be able to embed a video player. But chat, you look at Discord, you look at Slack, you look at Facebook Messenger, them. They're just annoyingly different.

The problem there is that you're stripping away all of the service element. You're best saying, hey, let's give you a chat. But if tomorrow there's a regulation that requires that chat to do something different, that means that you, as the person who selected that open source and implemented that in your application, will need to go and refix that. And when you say to, when I say a refix, you might take a new version and it might just But there is a good probability to take a new version and it won't work. And you need to start fixing and making things work together. Just think about this situation, you're taking chat.

No, I'm happy to have services, right?

Yeah, but...

But like with my car, with my car,

Bye.

 

I don't service everything on my car. I take it to a mechanic, but I don't have to take it to Toyota.

But here's the

It's

thing,

not

AJ,

like...

the thing is that the majority of developers think that they have freedom or a certain amount of freedom. And it turns out from my experience that they have a lot less freedom than they think. Again, going back specifically to the example of the platform that we use at Next, which is mostly built on open source stuff. It's built on Next.js and using WordPress as a CMS. And it happens to be hosted on Amazon. If we want to move from next JS to something else, that's going to be really hard. If we want to move from React to another framework, that's going to be super hard. If we want to move from Amazon.

But you can run React on anything you want to run it on.

So what does that actually mean? If we want, first of all, we have a service written in Angular before historical reasons. I hate it. I want to move away from it. We can't, we're stuck with it because rewriting it from Angular from to something else to a React is a heroically an effort.

But it's your intellectual property. It's actually your intellectual property. I don't quite know how to get the essence of what I'm saying here, but I think that that's really it, is that if you build something on top of say, Velo, you don't have any intellectual property. You own zero intellectual property.

Oh,

If

I

you

disagree.

build something with

I

Angular,

disagree

you have

with

the

that.

intellectual property. It's yours. 

Actually,

It's yours.

you do have

It's

a

yours.

particular property. Any code that you write, any design that you create on Wix is owned by you. You don't

But

know of the code.

it's not.

It is. What you're saying is super interesting, because you remind me the same talk I had with backend developers 10 years ago, when we were talking about using higher level services from clouds. And they were like, why should I use SNS from AWS? When I do that, I can't move to another cloud. And if I choose to use this service from GCP, once I do that, I can't move to another cloud. I'm stuck. I now have to be just in GCP. There's no way I can move to somewhere else. Now, being a company that works on both clouds, we have data centers both in GCP and AWS, we are very conscious of those differences. And any time, any service you're using on the cloud that is a little bit more than just a VM and just hosting a database on your VMs, you get exactly those same problems. And then at that point, you hear that exactly the same talk you just gave from all of the backend developers. And they'll say, yeah, you know, would mean is that when we move this workload from AWS to GCP, we will need to rewrite our services. We'll need to write all of our business logic. And we don't want to do that. Well, the reality is, is that you never, you almost never do that. You know, you choose a cloud, you know, all of the clouds are built.

I get that, but it's about the ability. It's like free speech. That's what I equate it to, right? There's a lot of things that I don't

Let's.

want to say that I'm never gonna say. There's a lot of language that I'm not going to use, but I still want the ability to use it, right?

Bye-bye.

I'm not gonna say terrible things about you, but I want the ability to.

So let me give you that exact point. Any managed service you're using is a trade. You're getting a lot for the managed service. The trade is your trade in freedom, the freedom to choose. Anytime you're doing that, and I can show you if you want over the last 40 years, it's a clear linear progression of us developers giving up freedom time and time again. and for managed services. In a minute, more

Well,

and

that's

more.

everybody.

We'll be back.

I

Thank

mean,

you.

that's, you look at government, right? In the world, people are giving up more and more freedoms every day to let government do something for them. This is a human trend. We will always sacrifice for convenience. There will come a day when the Black Mirror episodes are all true. And that's what we're

But

doing. We're

it's

doing

also

this for the

the

people who are watching this. We're doing this for the people who are watching this.

Thank you.

price

Thank you. 

of modernity because we're getting ever more sophisticated services that we cannot provide ourselves. You know, in the old days, we would get water from the well. These days, I like to get to open the faucet and get water directly through the pipes, but I need the government or some other water company or whomever to manage my pipes for me. You know, I gave up a certain amount of freedom. have.

But you didn't give up any freedom. You could still draw a well yourself if you live

not

in an area where

in

you

israel

can draw a well.

not in israel you can't

You're

uh...

not allowed

Well,

to

I

hear.

mean, but you didn't give that up. You didn't give it up. You simply chose an option. I mean, you could still go, if you want to, you can still go get water and then boil it.

And likewise, you don't have to use Wix. You can use something else. You know that when you use Wix, it's kind of like you're trading your freedom to dig a well and draw your water from the well for getting pipes and to your kitchen sink.

But I don't think that analogy works well because you could still... So for example, let's take solar energy, right? If you want to get off the grid and you've got the battery, whatever, you can at the point where the electricity connects to your house, you could technically, although I think not legally, disconnect the city power and... It's a plug-and-play system. You could plug in the solar and the batteries

Look,

for House in theory.

I'm not going to argue libertarian ideology. Basically, what I'm saying is that all solutions out there, and I do agree with you Av here, that you're trading freedom for convenience with Velo. You're getting, you're certainly getting a higher level of abstraction than most frameworks provide you with today, certainly with everything having to do with building the user interface. tied to the Wix platform. So is development

I'll

for iOS by the way.

Yeah.

You know you

All

have

right.

to go to the Apple eyes. Sorry, yes you are.

I'll add two things here. What you're getting is you're getting greater velocity for development at a lower price. That's what you're getting. And it does mean that your application or a good part of it is running and tied to the Wix APIs. Now, you could if you really want, you can take our own API for the front end and create another implementation for it and then run it whenever you want. The things that are not portable and never are portable is when you get a business service when you get a Payment platform or an e-commerce platform you can always port to another platform But they are there but it will be a different API and that means you're going to an effort in porting from one to another But but that's life you get a service, you know get a payment provider You can integrate with Stripe directly or with PayPal or with someone else and And each one of them has different API. There's no standard payment provider API. And there's a good reason for it, by the way, because they're different. Same goes for Recom. The Wix API for Recom and the Shopify API for Recom and the B-Commerce API for Recom are different because those are different platforms with different advantages. But you could on the UI, the back end, it's no JS, it's standard. The database, basically it's an ORM layer on top of database you can create your

own implementation. You can create an open source implementation in Ausitz wherever you want. But when you want to get the full Japan, the full managed service and get that gain of both price and velocity, this is where you're running on the Wix platform. That's why you can deliver that advantage.

He- he- and- and-

Again, I don't think that that's necessarily bad. I'm just saying that it's not the thing that I prefer as a developer that likes to have a sense

Thank you.

that the intellectual property that I create is owned by me or by my employer.

But again, I'm going to your idea of intellectual property. When I think of the intellectual property that's of interest for me, when I develop, let's say an application using React, it's not the nitty-gritty of using this hook or that hook or creating this JSX or that JSX. It's the algorithm, it's the business logic. And that I can take with me no problem. If I can give the analogy, and again, I'll be using, you know, but it's just good for an analogy. Let's say that developing an application from scratch in React takes me, for a certain React platform, let's say for Next.js, takes me, let's say, two months. But since it's now portable, quote unquote, because it's in React, and let's say I want to move it to Remix because I decided I dislike Vercel, let's say it's going to take me now two weeks I can take a lot of the React stuff that I did. I don't really need to reimplement it from scratch. But still I have effort because they are not the same. With Wix, if I want to move it from Wix to Remix, it's gonna take me the full two months of a total rewrite. But the upfront cost would have only taken me two days. So the question is, do I want to pay two days now and maybe two months later, or two months upfront That's the way that I see it.

And this, well, this is the classic vertical integration versus horizontal, what's the word I'm looking for? Componentization, right? This is the IBM versus the Apple model. And this is what Apple does too, right? Apple first partners with somebody so that it gets its development time down. So, you know, they partner with somebody to create CPU chips, for example, Motorola, and then eventually they either buy Motorola so that they're exclusively producing the chips for them, which I think is what they did when they created the iPhone. I think that they bought their old Motorola team from the 80s that Motorola was selling off. And then they fully integrate, and it's just, it's a sliding scale of intellectual property. In the beginning, they had no intellectual property in that space. They leveraged someone else to gain expertise and get intellectual property in the areas that were more More open, you know Designing the phone at all and then once they had accomplished that then they went back and then they got the intellectual property for the chip itself And now almost everything other than like the Broadcon modem or something and probably some of the NAND chips are all Apple intellectual property throughout the entire iPhone and And so this is a valid and a good business model that you can choose to say, hey, we're going to give up being able to own any of the intellectual property for this segment. We're going to

Thank

 

partner

you.

and componentize instead. And then once we are ready to maximize our resources in this aspect of our business, then we'll go back and

But

we'll

I don't like

create

your

the intellectual

usage

property.

of the term intellectual property because what you're implying that if is that if I write my application for the Apple App Store, Apple has the intellectual property for all my code. And that's not the case.

Well, no, because you can actually run that independently of the Apple App

No,

Store.

no,

You

I-

do not it is not required to have the Apple App

If

Store in

I

order

can't,

to run

well,

that code.

can I run my application on the iPhone, not through the Apple App Store? Maybe technically, but not practically.

Sure, and yeah, but that's why a lot of people want

So

those frameworks that

the

will do it on both.

concept of intellectual property is a legal one. So you know, I totally agree with you that once I write my application on top of Velo, I can't run my application anywhere else unless I do a full rewrite. I totally agree with you on that. I disagree with you with the statement that that means that Wix has owned the intellectual for my software. That's not the case.

Well, but you don't have the intellectual property because it is Wix's intellectual property,

What

right?

do you mean I don't have

The

the intellectual,

predominant,

the business logic

because

that

the predominant

I implemented?

pieces, which yeah, so very tiny, tiny sliver, the business logic

That's

that you

the

implemented,

important part.

sure, that's yours, but you can't, but it's not portable.

I

You

agree!

can't, but this whole argument is maybe a little bit mute because it's, I don't, I'm saying that for me, and really this was, Two things, one, what I consider to be a false comparison of the evolution of virtual machines, because I consider that to be entirely one-to-one the whole way through, and even to this day, you can still just take something off the shelf. You can go to Walmart and you can run the same software that you can run in the cloud, and you can have the same configuration parameters. So

that was one argument. The second argument was more...

That's not true today. You can't

But

take

it is.

a service function around in your machine and in your house. You don't have that capability. Maybe with a test server, but nothing really that

Thank you.

really

Thank you. 

would work.

But it, okay, so I have to go down the street to get co-location, but the thing is, it's the same, the pieces of the stack are the same and they're interchangeable. The other argument was more, you know, earlier we were saying, well, Steve, why wouldn't you use this? And I'm, that's, this is just me responding to, I love the idea of having components that are discrete components for common things that probably don't need of configuration like you know just scrolling through the list here I think this is great I would love to see you know a cleaned up version of an of an npm like thing that has this I would love to see a you know a self-hosted.org that has a list like this that you know CRM back in forum back in groups back in payment back in but that's it's awesome I think it's absolutely awesome I'm just I want that in a Lego like structure rather than a... And I think the niche for this is where you have businesses where the businesses are not scalable businesses, where they're not growth stage businesses, where it's, you know, I've got something that's pretty small, pretty self-contained, has a limited customer base, and I'm going to be building this thing going to become, you know, it's not going to become a billion-dollar business.

Hi.

Maybe it's going to be a 10 million-dollar business. This is not going to be a billion-dollar business and that's

But here's again

fine.

where I disagree with you, because my experience is that most development teams, and it's an unfortunate truth, and maybe we don't like to hear it, but most development teams don't know how to build scalable solutions. And usually the solutions that they build turn out to be not scalable. And so the winners, those happen to know, they knew how to bring in that top engineer, for them. But the majority of businesses don't know how to build scalable businesses. They don't know how to build secure businesses and they don't know how to build performance software. Believe me, I know. And

Yeah, so I mean, maybe I could be completely wrong, because maybe, for example, Nike, maybe Nike would be the ideal customer for this, because it's not a software company. They don't do anything in tech, but they need to be able to contract out to hire, and they need to have better, more customized features

Again,

than other shoe stores.

I don't like the distinction because you're making because a good friend of mine recently told me and I had to agree with him that in this modern world, all companies are tech companies. Nike is a tech company. Your bank

No.

is a tech company. I mean, the next insurance is an insurance company and we're a tech company. Anyway, that's about

I have

but

to say...

but but to be honest you have and I have I have to say something You know the pushback that you're getting here or on actually two fronts one is the fact that it is tied to the Wix infrastructure, it's not open source. It's closed source and it's tied to the Wix infrastructure and the second having to do with the brew the Wix's brand of not being a company oriented towards web developers, but rather historically towards the people who want to avoid using web developers. Those are two big pushbacks that you're going to need to contend with in order to make Velo succeed. And I think it's going to be a bit of a uphill struggle. And I think it's going to be a bit of a uphill struggle.

Well, I mean, before we wrap up, we're going way long here, so we need to get wrapped up here and move to picks. But I guess I'll just reiterate what I said. I mean, I think this argument could go on ad nauseam between all of us knowing our opinions. I just want to reiterate one of my points. I'm sure there's going to be a market for this. You just happen to hit two people here that have stronger preferences, have more experience, some more control. There will be people that want to use this, I'm sure. There's a wide enough to use a fancy word panoply of developers out there that have different skill sets and different needs and different use cases. And so,

I mean, you can even look

you know,

at this

I

as

think

like

there

an

will be

optimized

people to use it. Yeah.

WordPress. You know, I mean, it's

And for

WordPress

some people, that

has

may be

a

great.

billion plugins and they're all crap. Here you've got, you know, a hundred plugins and they're probably really high quality and work really well.

So all right, with that, we will wrap it up and move on to pics as much as I know we could talk about this for another hour and a half. Pics are part of the show where we get to talk about other things than tech, anything that interests us, food, movies, games, or it could be tech. Today we'll start out with Dan. What do you got for us for pics, Dan? 

Okay, so my first pick isn't really a pick. It's more of an observation. So the past two weeks have been really tumultuous times for the React ecosystem. It's been kind of amusing to see what's happening. So it kind of started out on October 25th with had a meta person on stage more or less saying that the future of, that Next.js is the future of React. Now, they kind of took back that statement a little bit afterwards or clarified it and said, oh no, we actually also love Remix and the other frameworks, but they did say it and people did hear it. So, and it's also true Next is the platform that's mostly embracing the React take on the future of web development with React server components and stuff like that. So we had this kind of a statement really positioning Next.js as the future of React in October 25th. And we had kind of like grumblings from the remix crowd, for example. But then we got potentially even bigger news on October 31st when we learned that Shopify is actually buying remix and that remix will now be a part of Shopify. And in fact, kind of replacing hydrogen, which means that whatever hydrogen was up to October 31st, that's no longer the case. And now remix is hydrogen. So, really tumultuous times in React land. It will be, and while all this is happening, we've got all these new frameworks coming out of the woodwork and kind of challenging React's dominance, you know, with Quick, we've had Mishko on our show, and with Solid, we've had Ryan on our show, and so, you know, all of these new and interesting frameworks, you know, it's like that Chinese saying, may you live in interesting times. It seems to me that we're definitely living in interesting times. And it will be interesting to see how Wix fits in with Velo in all of this, you know, Hoopla and whatnot. So that's kind of my first, I don't know if I'd call it a pick. Like I said, it's more of an observation. My second is also kind of an observation more than a pick. It's the ongoing war in Ukraine, which is still ongoing. into winter, which probably means it's going to be a lasting and really painful stalemate for a while while they hunker down in the snow. But so we're probably going to be hearing less news about what's going on there, but it doesn't mean that the fighting is over or that the suffering over is over. And therefore, as usual, I call upon all our listeners to do whatever they can to help the people in Ukraine and through this ordeal. And those would be my observations for today.

Thank you, Dan, for picking those observations. Excuse me for a second while I gag. Okay, end of it. All right, AJ, you're next. What do you have for us for picks? 

I started listening to... where did it go? The Big Short. I think that's the one, yeah. And that seems pretty interesting and scary.

listening

So...

as in to the audio book not watching the movie.

Correct. Correct. Yeah.

Did you see the

Yeah.

movie, by the way?

I have not seen the money.

It's a good movie.

I don't know. I was kind of in a fever dream state while I was listening to it. So I heard the first hour or so. Okay, there is some new flu thing that's going around, it seems. The flu skipped two years and so now it's back with a vengeance, I guess. And so I got it. And

at least And so I still have the cough. And sometimes I still just start gagging for no reason, well, not for no reason, but because of my gag reflex and the cough and everything. Anyway, so I started listening to it while I was in kind of almost fever dream state. It helped me fall asleep, not to say that it's boring, but just that it was able to engage part of my mind so that the other part of my mind could relax and I could conk off. So I need to actually get back into it to see how good it is. And maybe it wasn't that good. Maybe it's just cause I was in a fever dream state. But I think it was. 

I

think

was

it

going

was.

to

But

say,

anyway, the...

picking a saying you could fall asleep to a book isn't exactly the best.

And while I fall asleep, I fall asleep to all sorts of books. Another thing I'm going to pick, two more things. So mentor pilot, I also while I was in the fever dream state for a couple of days and just looking for anything to engage my mind, I pretty much ran out of all of the watch later stuff I had on YouTube. And then I came across mentor pilot and it's this guy who I think he has three or four different channels related to. being a pilot and flying. But on one of the channels, he just does crash reviews. So think of any of the recent flights, well, recent, you know, the last, any flight period, really, just the last 20 or 30 years, he'll go through the black box recording, he'll just go through step by step and explain what happened during the flight, what was done well, what were areas that could have been improved better manufacturing or better pilot action, what the NTSB and FAA recommendations became due to the situation and why flights are safer today because of what was discovered during the investigations and whatnot. And so it was just really interesting and fascinating to understand how flights work and all the different issues that people that are running commercial flights run into. And then the other the other thing I'll pick is, and this is going to be somewhat controversial, but the Matt Walsh show Matt Matt Walsh is a comedian. But a lot of people, especially people that report on him and then pick him up on other news networks, don't know that. Because he's very deadpan. And if you were to just watch part of the show or listen to part of the show without understanding that he's a comedian, you could think, what's that internet law where the difference between sarcasm and extremism, you know, you get to a point where if you don't know, you just don't know, I forget what that one's

I forget

called. Is that

as

Poe's

well.

law?

I just,

I think that's Poe's law.

I forget. I just know that on the,

Anyway, so he's at...

I said, I just know that on the internet there are no rhetorical questions. That's all I know.

Cough, cough,

Every,

cough!

every rhetorical question will be answered on the internet.

Well, he says all sorts of whambastic and inflammatory things. And then, you know, so people will pick up something he said and then just, you know, make a big deal out of it. And then he will the next day read an excerpt from the article or whatever where people are, you know, calling him the worst thing since Hitler. And then he'll make fun of it. just agree to whatever they say. You know, one time he made a comment about anime being literally evil, and then that snowballed into this thing, and then when he gets on the show, he's like, some of you may have noticed that news network, such and such, put up on an article, because I called everyone who watches anime a Satanist, and you know that everything I say should be taken with the same seriousness and severity This is absolutely true. And I couldn't stand by it firmer and I'm glad they picked it up and let the world know. You know, this is the kind of terrible human being that he is. So anyway, I've just, I've enjoyed listening to his podcast because he's so terrible and hilarious.

Okay, I will go next with the picks. My picks are, I like to think, the highlight of every episode, but the dad jokes in particular, but I'm sure there are those that will debate that. So I'll start with my dad jokes of the week. Some are better than others, but that's par for the course. So first of all, simple question. How do you spell the word candy with only two letters? C and Y. Dan has a confused

No,

look

I

on

think

his face.

that's a joke better written than said out loud.

Yes, you sort of have to visualize that. I'll give you that much. So what is worse than a box that contains venomous snakes? A box that should contain venomous snakes.

Well, that's kind of vari-

I saw where

Yeah,

you were

that's

going

kind

that

of

winter.

variation on your half apple with half a worm in it joke.

Yes, yes. Oh, thank you for reminding me. That was very good. Yes, what's worse than an apple with a worm in it, an apple with an half-eaten worm in it, I think, or something like that. And then finally, you've all heard about the blind carpenter who picked up his hammer and saw, but did you hear about the deaf shepherd who gathered his flock and heard? And then, the blind carpenter who picked up his hammer and saw, and the blind carpenter who gathered his flock and heard, and the blind carpenter who gathered his flock and heard,

Hmm, okay.

Saw her get it anyway.

Yeah.

Okay, that's it for my jokes of the week. And finally we're on to Yoav. Yoav, you have any picks for us? 

Oh, px. I can share what I should have been

Uh-oh.

done for today and didn't because I wanted to honor you and visit you here. And that was actually doing night mountain cycling in the rain in the Judea desert going down about a height of almost a mile. and hopefully staying alive after that.

Yeah.

Okay, so let me get that clear. So you're in the desert riding a mountain bike in the rain at night. And what other part did I miss?

in a very, very strong descent, about the height of a mile, the height difference, and across 20 kilometers, about 15 miles of distance, which is really, really, really fun if you're really into it, and sounds really urban if you're not.

Yeah, and if you don't mind falling, I guess.

Well,

All right.

it happens

Yes.

sometimes.

That's sort of funny. I mean, when I first got into PHP, my SQL development, early 2000s, my first, one of my first projects was working with another developer on a website for a bike shop that's best specialized in downhill mountain bike racing. You know, that was the whole thing. All the races were downhill. You had some pretty hardcore bikes, you know, to be able to handle that kind

For

of stuff.

some reason I'm reminded of that Douglas Adams quote that he said that the trick in flying is learning how to fall and miss the ground. So

Ha ha.

I hope you can achieve that the next time that happens when you fall off your bike.

It's kind of the same

Uh...

thing and that's what you're trying to do. Miss the ground.

All right, so with that, we will wrap up this episode of JavaScript Java. Yoav, thank you for coming on. Before we leave, if people want to learn more about Velo and you and what you're doing, how can they best do that?

They can go to www.weeks.com or you can just find me on Twitter, you have a Brahmi on Twitter. Reach out.

Alrighty, awesome. With that, we will wrap up this very long episode. Thank you to my panelists, thank you to you all for coming and we will talk at you next time.