Transcript
Voss: My name is Laurie. My pronouns are he and him. I have been a web developer for about 26 years now. I, for a little while there, was co-founder of a company called npm, Inc., and a couple of other startups. What I've always been is a keen observer of our industry. For the last 10 years, my jobs have involved analyzing data about websites, and how web developers work. More recently, using data from surveys from tens of thousands of web developers. My talk is about a model of how web technology evolves that I've been working on. I'll be using examples from history to show how the model works. Then I'm going to take a leap, and try to use the model to predict where web development is going to go in the next five years or so.
The Model (Web Development Technology Cycle)
Let's start with the model. There's not a lot to it. The beginning of the cycle is that people have some technical problem. They try lots of different ways to solve that problem, and they get paid a lot of money to do it. Then there is a period of wild experimentation. Once everyone has seen a problem has been solved, they're like, "Give me that way, I liked that solution." Soon, instead of solving a new problem, everyone finds themselves rebuilding the same solution over and over. You get better at doing it, and you begin to form best practices for doing it properly. Eventually, the way that you solve it arrives at consensus. Then some clever person writes it down in a blog post or a book or something, people start giving conference talks about the way to do it. Then the problem is solved, and developers get bored, because they've got the design patterns locked in.
Eventually, one of those bored developers realizes that they can save time and effort by building a general solution to the problem, a framework or a product or a service. This is interesting to the developer, because the framework is more interesting to build than just solving the same problem over again. Once it's done, you never have to build that solution again, or at least that is the idea. Turning it into a product like this is commoditization. The process of commoditization is not clean or simple. Lots of people will get the idea to commoditize the service at the same time, so there will be lots of different products and services and frameworks, all at the same time, in a period of intense competition, trying to become the solution for this problem. In addition, people form religious attachments. There are flame wars. People write blog posts accusing everybody of doing it wrong. It can be really brutal.
Eventually, you do get some consolidation to one winner, or maybe just a small handful of winners. That is because it's simpler to have one way to do things. By this point, all the solutions that are competing in the marketplace are going to be pretty good. If everybody can agree to do it one way, that is itself an advantage, because you only need one set of documentation. You can hire people knowing that they will already know how to do it the way that you do it. The economics of the situation favors consolidation. The process is also not very enjoyable for a lot of people. It generates a lot of complaints from the people who used to make easy money by solving the same problem over and over, because doing the same thing over and over is easy. They can argue that their custom solutions are going to be better because they are paying careful attention to the circumstances of each customer and each app. They're often right about that. A custom-built solution will probably be better than an off the shelf solution. It's not going to be so much better that it is worth all the extra time and money that it takes to build a completely custom solution from scratch. Especially when there is a framework out there that you can buy off the shelf, and it will be pretty good. The economics drives people towards a framework, drives people towards commoditization. In all of these cases, I could be talking about a framework or a product or a service. I'm just going to say framework over and over. In all of these cases, I mean all three of those things.
All of this leads to stage 7, which is whining about the fundamentals. It is entirely impossible to skip this step. People who are used to building a thing from scratch, will start to complain that people who are using the framework are forgetting the fundamentals. This is considered to be a major problem. The fundamentals they're going to assert are key to writing good software, and to doing what you do well. If you don't know the fundamentals, you are going to be a bad person. While those people are still whining, a whole bunch of new people will show up who do not know anything other than the framework. They do not know whatever those fundamentals are that the other people are whining about. They don't care. They are just going to be building a bunch of fun, new stuff, and solving new problems using the framework. It's important to keep in mind that at every stage of this cycle, you're adding new people. In fact, the number of people involved is roughly doubling at every stage of the process. There's twice as many people who know best practices as did the experiments. There's probably twice as many people using the commoditized product, as we're accustomed building things using design patterns. The number of people whining about the fundamentals are going to be vastly outnumbered by the number of people who are just adopting the winning solution and not caring about the fundamentals.
The last stage of the process is migration. This is when those who are involved at the beginning are faced with two options. They can become the people who build the framework or the product itself. Because the framework itself is always going to need to evolve. It's going to need to change. It's going to need to adapt. It's going to need to expand, because the world is always changing. The people who decide to become the framework builders, the people who decide to specialize, can get really good at those old techniques that used to be bespoke. They can get so good that nobody can ever hope to approach their level of quality. That works fine, because it's great for the framework. It's being written by the people who are best at it in the world. It's great for the specialists, because they will always have a job. There will always be work for specialists maintaining infrastructure at lower levels in the stack. There's a second option, which is that you can become part of the crowd of new people who are solving new problems using that framework. Maybe you think that the old problem is boring or difficult. Maybe you just like building new things. One thing is for certain that there's going to be a lot more jobs building using the framework, than building the framework itself. Most people are going to end up using the framework rather than building it. That is the full cycle. There's wild experimentation. There's best practices. There's design patterns. There's commoditization. There's intense competition. There's consolidation. There is whining about the fundamentals. There is mass adoption. Then there is migration, repeat.
In reality, the cycle isn't so clean. The stages often overlap. There's usually several of these cycles going on at the same time in the industry in different corners of technology. The result is that technology is a layer cake of the things that developers used to have to think about, that have become products or services. We call this layer cake, the stack. New layers in the stack are constantly showing up as expectations of quality in the industry continue to rise, and the old ones get abstracted away or turned into some service that everybody agrees is fine. The funny thing about the stack, is that while everybody agrees that there is a stack, very few people agree on what is in the stack and where it begins and where it ends. If you take one thing away from this talk, it should be that there is no such thing as the fundamentals. That is gatekeeping nonsense. If you can get your job done without knowing stuff lower in the stack than where you are, then it doesn't matter what you don't know. When I became a web developer, people genuinely said that because HTML is an application of STML, you had to know STML to really be a good web developer, otherwise, you're ignoring the fundamentals. How many people have even heard of STML?
History Of the Web
To prove how this cycle works, let's do a lightning recap of the history of the web. I want to show you how many times this has happened because it's going to be difficult to swallow the prediction I'm making. I want to really ram home that this is a real cycle, and it's very hard to break. Because you're going to want to whine about the fundamentals, and I would like to convince you that the best thing to do is embrace the change instead. The web was born in 1989. The way that you built a website in 1989 was you wrote some HTML by hand. You saved it to a file on your hard drive. Then you ran a piece of software that spoke HTTP. That would serve it. That was the state of the art. Then there was a period of intense competition, in which there were hundreds and thousands of competing pieces of software that served HTTP. Soon, things began to consolidate. One extremely popular option was the Apache Server. Soon, either everything used Apache or it worked very much like Apache did. A few people were still writing their own web servers, but not many, not none, because in the early 2000s, Apache was essentially replaced by NGINX in the marketplace. There is still and there always will be innovation going on at levels lower in the stack, but it is not a major focus of competition for most people.
By 1994, the major innovation was the Common Gateway Interface or CGI. CGI let you answer POST requests from browsers with dynamic responses. That was a brand-new idea. A website, instead of being static HTML, it could respond to what a user had posted. It could be interactive. It could get input and respond with output. To do that, you'd have to write a piece of software that understood HTTP, and then run that on your computer or under your desk. This started another period of wild experimentation. First, you installed Apache. Then you started writing a piece of software that parsed the HTTP headers yourself. Your software would glue strings together to make HTML, and it would then send them back via HTTP to the user. This too got really old really quick. Soon there were libraries written in languages like Perl to do this tedious parsing and output for you. Then somebody wrote some libraries that wrapped C libraries for you to make personal home pages, and thus was born PHP. PHP parsed the HTTP headers for you, and then sent HTML back to the browser for you automatically. You just wrote the code that did the logic in the middle. This was a fundamental breakthrough. There was great uproar about it. People using PHP were forgetting the fundamentals. I was told in 1996, with a straight face by other developers that because I used PHP, I wasn't a real developer, because I wasn't parsing HTTP headers myself. PHP took the world by storm.
Meanwhile, over in the hardware land, sticking a computer under your desk was getting really boring. People decided that they would make whole custom-built buildings to stack computers in with power and networking and stuff, and you could colocate your servers there. Soon, somebody got the idea that driving to the colocation facility was tedious and expensive, so why not just hire some people who hung out permanently at the colocation center, and they would rack and stack the servers for you. You just hire them by paying for it with a credit card. That was much easier. That was great. There was a period of intense competition. Suddenly, there were thousands of web hosting companies. They all priced things slightly differently. They provided different options. They varied enormously in quality and especially uptime. There was a gigantic competitive fight that drove quality upwards and prices way down. This is how commoditization works.
Everybody wanted a server. Most people wanted Apache on that server. They were ok with the server being Linux. They probably wanted a database. MySQL was popular. They usually wanted PHP installed, and thus was the LAMP stack born: Linux, Apache, MySQL, and PHP. It became the default way to host a website for a solid decade there. Even though none of those companies had anything to do with each other, and Linux didn't even have a company. Because economics is often the driver of who wins these cycles. The cheapest thing wins, even though nobody was pushing the LAMP stack as an integrated solution, the LAMP stack became popular because those things worked together and they were cheap. The operating system was free and so were PHP and MySQL. LAMP started out cheap and got even cheaper because soon everybody knew it. It became cheaper to hire people. It became cheaper to train people. It became a self-reinforcing cycle. New projects would get started on LAMP, because that was what people already knew.
What were people building on the LAMP stack? It turned out they were mostly building blogs. In fact, somebody realized that nearly every website in the world can be generalized to being like a blog. In 1999, there were 23 blogs online. In 2006, there were 50 million. This led to a period of intense competition. Suddenly there were thousands of competing blog products and services, just an absolute blizzard of them. They were all pretty much the same. The result was that WordPress 1, and WordPress became a framework. It became a way to build any website, not just a blog. It was very popular. How popular? Forty-three percent of websites are powered by WordPress today. In fact, WordPress is more popular today than it has ever been. Even though these days WordPress is sometimes used as a backend with an API to feed some other frontend.
Now you're beginning to get the idea of how this cycle works. We have a problem. We solve the problem. There's a whole lot of logos of two dozen products that you've never heard of. Then three that you have heard of, because they won. This keeps happening, so let's go faster. Introduced in 2004, and peaking in 2006, Rails changed the game for building web apps by abstracting away a huge amount of the skeleton of web apps. People complained a lot that people who were building on Rails didn't know the fundamentals of web development. Invented in 2006, jQuery smoothed over the web's rough corners. It got enormously popular. jQuery got so popular that its APIs got built into the web. This was funny, because there were people complaining that jQuery developers didn't understand the fundamentals of the web. Then jQuery became the web. Anybody who understood jQuery was understanding the fundamentals of the web. Then there was GitHub. Launched in 2008, GitHub exploded in popularity. Source control had been a thing forever. Open source software at the time was distributed mostly by SourceForge. GitHub took version control and made it much easier to use. Now there's lots of people who don't really know the difference between Git and GitHub, and probably never use Git by itself. Back over in the land of hardware, colocation lasted a long time, as the level of abstraction for hardware. It was really good. You were renting a physical computer. You knew roughly where it was. You knew what hardware it was, what memory, what hard drive. You installed your own software on it. If it failed, you needed to physically replace it.
Round about 2006, AWS introduced EC2, which abstracted away the hardware. Now instead of renting a specific computer, you were renting the idea of a computer. It had virtual memory and a virtual hard drive. Actually, it was just a fraction of a much larger computer that Amazon owned. You probably didn't know where it was, except that it was probably in Eastern Virginia. Any hardware level concerns were gone. You no longer knew what hardware where it was running on and you didn't care. Knowing what kind of hardware you were using felt like a fundamental part of being a web developer until suddenly, one day, it wasn't. That doesn't mean that there's not people who still know about those things. Of course, they do. There are thousands of people whose whole job is running power to servers and making sure the networking for them works. There are huge companies that make billions of dollars doing it. Over here in web development land further up the stack, we no longer need to know.
Of course, in cloud computing, there wasn't one winner, or at least there hasn't been one yet. In addition to AWS, there's Azure, and Google Cloud, and Alibaba, and a solid dozen others. There's lots of competition, but you don't need to care it turns out, because AWS has 33% market share. Everything works like AWS, even if it's not AWS, because that's what everyone already understands. The other ones just modeled themselves over the leader. The concept of cloud hosting has won, completely won. Cloud hosting is just how you run a service in 2022. In a way that you probably don't even think about, in the same way that people didn't think about, should I use LAMP or not in 2005?
Let's hop back to the world of software. 2009, Node.js was invented. npm was invented very shortly after that. Initially, npm was all about Node. Really when npm started taking off is when it became about JavaScript in general, around 2014. npm is a really great example of how the succeeding layer is always so much bigger than the layer before. npm is essentially a distribution channel for open source, like SourceForge. SourceForge gets 15 million downloads per week, which is a lot of downloads. In the last 7 days, npm served over 40 billion downloads. In a week, React gets 15 million downloads all by itself, as much as everything on SourceForge combined. We're going to be talking more about React a bit. This is not for me to make fun of SourceForge, my point is that the jump in scale is a key part of this cycle. WordPress was not twice as popular as all of the blog software that preceded it. It was hundreds of thousands of times more popular, just many orders of magnitude bigger. It is in a totally different space.
What's Happening Right Now?
Let's skip ahead to the present. Take for granted that Docker is a framework, that Kubernetes is a framework on top of that framework. TypeScript is a framework that lives on top of JavaScript. All of these went through the same cycle or are going through the same cycle. I could explain them all. If there's one thing that you've picked up from this talk already, it is that web developers get bored easily. Having toured all of those past cycles, where are we now? There's two big changes that I see that are currently at stage 5 of the intense competition. The first is serverless. That is the thing that is happening right now. We've been abstracting away hardware for a while, so we didn't even go further. AWS released Lambda in 2014. Forget hardware, forget virtual servers, forget an operating system, or server software, what if you could just deploy functions directly? You just write some code, and AWS makes sure it gets the input and returns the output to your browser at essentially arbitrary scale. We call this phase serverless. I'm still mad about that, because there's more servers than ever before. That's what we called it. The serverless revolution is far from done. There's still lots of people deploying containers. There are tons of people competing to be your serverless platform. Our survey data in 2021 said that 46% of developers are using serverless functions. As a sneak peek of the survey data that we will be releasing at Jamstack Conf, now 70% of people are using serverless. It has become fully mainstream. It is becoming the normal way to build things. Soon, there will be consolidation, and there will be people whining that people have forgotten the fundamentals of servers.
If you thought my talking about npm a little while ago was a self-serving reference, you're going to really love this next bit where I talk about Netlify where I work right now. Because the other technology that I see at stage 5 right now of intense competition is the one represented by services like Netlify. We can loosely refer to that type of service as the Jamstack. Assume you're using source control. Assume you want to see the end. Assume that you are doing continuous integration. Assume you want serverless functions. Assume that you don't want to have to set all of that stuff up yourself, or host it yourself, or make sure that it works together really neatly, then you get Netlify. Netlify can be thought of as a framework for deploying and testing and hosting a website. It solves a bunch of problems that were getting really boring for all of us. Netlify is currently in the intense competition phase. AWS has Amplify. There's Vercel. Azure probably has some service that does this. All of them are doing the same thing. They're taking a thing that used to be your concern, how to run tests, how to deploy, how to preview changes before putting them into production, and they're turning that into one thing that you don't need to think about anymore. Who's going to win? Obviously, I have made my bet by going to work for Netlify. The Jamstack concept, the idea that this should be a single thing that you don't have to think about, that is well on its way to winning the market.
Now let's talk about React. Introduced in 2013, React is enormous. React's model for encapsulated components solved a huge pain point in web development. It also went massively against received wisdom of how you should write web pages at the time. It threw HTML and JavaScript in together. Sometimes it throws CSS in there. Sometimes it writes the CSS in JavaScript even more controversially. That was not how you were supposed to do it, or at least that was what everybody agreed at the time that React was released. React demonstrated that web development best practices had got stuck at a local maximum. The result was that React exploded in popularity and took over the web. React's share of web development right now is almost unprecedented. In our latest survey, 71% of developers said that they have used React this year. React is well into stage 8. There are tons of people whining about the fundamentals of people who only know how to build websites using React and don't know how to build websites. It's just as nonsense as it was before. I've only seen a frontend framework that got as big as React once before in my life, and that was jQuery. We were just talking about what happened to jQuery. JQuery got so big that browsers adopted it and built it into the web API, and it became the web. That could be what happens to React. It would certainly make our web pages lighter if we didn't have to ship this React library to every single web browser in the world. How's that going to happen? Is JSX going to become part of the web? Are we going to start building in the Reactive model? I feel like something has to give at this stage because it's just so big.
One thing that we have already is web components. These are the native web components. They're highly performant. They're built into browsers. They encapsulate code behavior and style like React does. The syntax is really annoying. What I would love personally, is if somebody found a way to make React syntax work with native web components, and then we could all be happy. Even with their current issues, web components are making their way into the mainstream. Thirty-three percent of developers in our survey this year, said that they are regularly using web components, which is solidly mainstream. One way that you can tell that a solution is likely to win in this marketplace, is if some people decide it has already won. They start building new things assuming that you've already used the previous solution. They'd say, you're obviously on EC2, so this is how you deploy this thing to EC2. Or they're like, you're obviously using WordPress so here's a plugin. That's happening to React. Today, there are a whole bunch of new frameworks, like Astro, and Remix, and SolidJS, and Svelte that are built with the assumption that you'll be using React. They assume that you know how React works and that you are happy with it. They focus on solving other parts of the problem.
What's Next?
What happens if we assume that React is going to win? Maybe it will get absorbed into the web. Maybe it will stay a framework. Assume it hits 80% or 90% adoption, can we predict the next turn in the cycle? Can we predict what happens next? That depends what you think the problem that we're solving is. Let's look at some of the candidates. Could it be the metaverse? Not yet. They haven't even figured out how to draw feet. They said that they had, and then it turned out that they had actually faked the video where there were feet. They had to admit that they haven't actually figured out how to draw feet yet, which is even more embarrassing than not being able to draw feet in the first place. Metaverse is clearly not ready. Nobody's building en masse for AR yet. Barely anything is going on. What about Web3? No. I could do a whole talk about the problems that come from modeling your entire web as a series of financial transactions. We don't need to argue about the merits of crypto, we can just look at the data. The number of people building in this space is still tiny. Again, a preview of the results I'm going to show at Jamstack Conf, only 3% of devs in our survey said that they were regularly building things using any of the Web3 technologies we asked about. Then there's Web5, which I was joking about this. Jack Dorsey has actually announced Web5 and has a whole company building stuff around it. There is no Web4, because you took Web2 and you added Web3 equals Web5. The future is definitely not whatever thing that Jack got high and came up with and thinks is Web5. The way to figure out what is next is to look at what happened before, the thing that got abstracted away, that is the thing that we got tired of is the thing that we got bored of solving. That's what's going to happen. That's what's about to enter stage 4.
We abstracted away the hardware and the operating system and the server, right now there is intense competition between frameworks. We think we might see a winner. What happens if it's React? What happens if people get bored of React? What happens if they try to abstract React away? I'm going to show you a product called React Bricks. Three years ago, I predicted that somebody would build a product like this. A couple of months ago, they DM'ed me on Twitter and said, we built that product that you said somebody would build. I'm just going to show you the general idea of React Bricks. You run npx create-reactbricks-app. It creates a development environment for you that runs on your local machine. This is what it looks like. It's a rich editor for a web app, and it runs on localhost. React Bricks allows you to build a multi-page web app by dragging and dropping prebuilt React components. You can add content within the UI directly by just typing it in. You can use the sidebar to customize content and behavior. You don't have to know how to code to use React Bricks. If you do, you can also create your own reusable components. You can add more bricks, as it were. The components are just React. They are React with some custom elements that tells the UI where you can enter text, and what the sidebar properties are that you can modify. The components encapsulate code, they encapsulate behavior, but they are not the content. The content lives in a database that is separate and attached to the UI.
Imagine a world where React Bricks gets really popular. There would be enough existing components that you would almost never need to write your own component. You'd hardly ever have to fall back to the code. If you wanted a blog, grab and drag and drop a blog component. When it's in images, throw in another block. You want a Stripe integration, there's a block for that. With three drags and drops, you can create an entire e-commerce site. You could build a whole website without knowing any React at all. In fact, you could build an entire website without knowing any HTML. That is where we get to the point where I hate my own prediction, because a web developer who doesn't know HTML, they don't know the fundamentals. How can you be a web developer and not know HTML? I hate this prediction. It's my prediction, because I love HTML. I have been writing it for 26 years. That's what makes me believe that this is a persuasive vision of what the future could be like, because it makes me deeply uncomfortable. The thing that wins is usually the thing that gets that reaction at first.
If you think about it, this is how web development was always supposed to work. The very first web browser, worldwide web itself, was a WYSIWYG editor. The web was invented by Tim Berners-Lee from the get-go with a drag and drop GUI in mind. That was what he thought it would be. What could be more fundamental than fulfilling that original vision. Once again, the economics are pointing the way. Web developers have never been in as much demand as they are now. We earn so much money and we are effectively building the same thing over and over. A login system, a list display, a search bar, an address form. People have got very excited about design systems recently, and those are an important and necessary step. They're literally the design patterns. The next phase is automating them. We can't just stop there. Because the fact of the matter is that the world needs far more websites than the current set of web developers can supply. That is a problem for the whole world.
We all earn tons of money, and yet websites still suck every single time. I'm using some company's website, it sucks. That is because it's too hard. It is too hard to build websites, still. There's still too much effort involved and there aren't enough of us. That is making the quality of our experiences suffer. For websites to stop sucking, there need to be 10 times as many of us. The way that you do that, the way that you get there is you make web development 10 times easier than it is today. This is one of the ways that you could do that. There are other possibilities of how you could do that. One possibility for accelerating a web developer is GitHub Copilot, which predicts what you're going to write using machine learning and essentially autocompletes it. This, to me seems like solving the wrong problem. If I have to write the same code so often that ML can predict what it is going to look like, then I should not be writing that code at all. That code should be in a component and I should just use the component. I shouldn't have to write anything.
Also, you may be thinking that this is scary. Web developers who don't know HTML, it is scary. If the future happens this way, then you are going to find yourself in another one of those great migrations that I was talking about. You will at that point, have three options, or maybe four. The most obvious option is the default, do nothing. If you already work lower down the stack, you're racking and stacking hardware, for instance, or you're writing database software, these changes in the frontend world are not going to affect you very much. Your skills will remain in demand. What will change is how you're delivering them and who you're delivering them to. If you do interact with frontend code, it's almost certainly going to affect you. The first option is to specialize. Become one of those people who are building the components themselves. Like I said, we're always going to need those. Things are going to be changing. Requirements are going to be changing. People are going to be adding new functionality. Things will need to be maintained, adapted, and expanded. The developers who can build these components and build them really well, they are going to be very much in demand. Everybody is going to want them. They're going to do what specialists always do. They're going to become so good at building these components that it's not going to become worth rolling your own.
The second option is to become one of the people who are using the framework and just start building sites this way. You can become the wise elder of the space by slapping components together more quickly than anyone else knows how to do it, because you got on board early. Then the third option is to be the person who invents this framework in the first place. You could be the person who solves this problem, because I want to be clear, the chances of the winner being React Bricks specifically at this point are basically zero. We are at the phase of wild experimentation in this space. There are a solid dozen projects that I know about, that are taking a swing at letting people build websites this way. Not everything is working yet. Not every part of the problem has been solved yet. There are still some rough edges. I am taking 26 years of experience as a web developer and 10 years of experience looking at data, and I'm staking my reputation, I'm putting a sign in the ground that says this way to the future. Of course, I could be wrong. I'm often wrong. I've been wrong about all sorts of stuff. This feels inevitable. If I'm wrong, then we can all come back to this conference five years from now, and you can point at me and laugh. Maybe we'll all be at Bricks Conf, and you can say that you heard it here first. Either way, I hope I've given you something to think about, about your career, about our industry, and about what the future could hold.
Questions and Answers
Dunphy: Since you work at Netlify, you're mentioning Netlify as a Jamstack framework. I find that's an interesting concept. Can you briefly talk about what it is that Netlify is working on today that you're most excited about or recent releases that you're most excited about?
Voss: I think the direction that Netlify has been moving in for a while now, and all of the other Jamstack services are moving in the same direction, is to expand the capabilities of the Jamstack. The Jamstack, initially got a reputation as static sites. Those two phrases used to be interchangeable. Now I think the most exciting thing about Netlify and other Jamstacks, is the ability to run serverless functions just by throwing them into your app. In particular, Edge functions, which are extremely fast, close to the user. Functionality that lets you really superpower your website in a way that's far past like these static site origins that people think of when they think of Jamstack.
Dunphy: Now, back to your survey. The data says that React is dominating the web. What does the data say about alternatives like Vue, or Astro?
Voss: Vue is the most interesting one. The data said that this year, Vue lost user share. That was a surprise to us, because in the previous years, it had been gaining share, and we were expecting it to continue to gain share. I think personally, that that might be a blip. I think it might manage to return to growth, because the people who use Vue are very happy using it. They are just less happy than they were last year. Vue is always, to my mind, being like a possible successor to React. If it's beginning to decline in user share, that means that it's missed its window, and React will continue until it hits 80%, 90% share. I still think that the potential is there for it to turn it around. Competitors other than Vue, they're also much smaller, but it's very hard to get over the moat that React has built. They definitely have their own leashes. They definitely have good use cases. In terms of being a logical successor, I don't really see one.
How is React Bricks different from any of the many other WYSIWYG editors that have come and gone over the years?
It's not obvious from the high-level demo that I gave. What React Bricks does that is different is that you are building a functional piece of software. You're not just saying this is what it looks like and this is the text that I've put in. You can connect the components to each other. You can say, when you input this form, the data goes over here, it goes to this backend, it gets this response and that response goes here. Which is very much what you do when you are building a React app, you just do it in code. Because most of the logic of a React app is in the API. If you know how to process the API response, that's like 90% of what your React app is usually doing. It turns out, you can express that using drags and drops rather than using code. That's what sets it apart from other WYSIWYG editors, because it's not just what you see, it's what you don't see.
Dunphy: I want to hear your thoughts about code sharing business logic or UI components between web, mobile, and using React and React Native.
Voss: I think we got a question earlier about, will React's dominance extend to mobile applications? I don't think it will be React itself. I think React has had enough time in the marketplace that if React was going to become a major force in mobile development, the way that it has in the web, that you would be seeing that already. The fact that it hasn't implies there's something that makes it not good enough for mobile developers that they are sticking with what they know. However, if you look at Swift, by Apple, it's called SwiftKit, it looks a lot like React. It's not React, but it has many of the same concepts. If you were jumping from React to SwiftKit, you'd be like, I see how this works. It's just components and props. That's how React [inaudible 00:41:49] is translating to mobile, it's taking the concepts, but it's not necessarily taking React itself, not necessarily running React Native on phones.
Dunphy: There's definitely a lot of reasons I think that React has not seen dominance on mobile, not the least of which is many issues with the platforms themselves, specifically, Apple. Apple seems to like their own little bubble. They like to put hurdles up for anyone who deviates from their recommended methodologies that either mess with their version of doing things or more importantly, their purse. Having React subserve this is not something that they're too excited about. I think that's one roadblock, and there are many others.
Voss: What about low code?
React Bricks is a low-code platform. You can type in some code if you really want to. I think low code is a stepping stone. If you think about people using WordPress, I think WordPress has been for a very long time stealthily a low-code platform. It mostly builds your website for you. If you're using WordPress, you might tweak your CSS a little bit, or you might set up a plugin that requires some config files, but you're not writing a lot of stuff. You can do a lot of stuff in WordPress with only knowing a little bit of HTML. I don't think low code's a revolution. I think low code's been here for a while. I think the revolution is no code. We haven't seen that really blow up yet. I think low code is already obviously true. Things like Webflow, Wix, they are, in fact, low-code platforms already.
Dunphy: One thing, speaking of WordPress, that I found interesting, is it has the most adoption but the lowest satisfaction rate. Do you think that's a result of a bias towards a more modern Jamstack-y survey respondents, or do you think this is actually representative of the community as a whole? That WordPress, maybe is seeing its last decade, perhaps, before it gets usurped, or do you think it's going to keep going?
Voss: jQuery is still kicking around, and it's 15 years old. We don't need jQuery because it's built into the web, but like 50% of people are still using it. WordPress will be around a lot more than a decade. We do see in the survey that its share of usage is declining. I do think it has begun the downslope. Web development moves away from tools slowly. It adopts new ones very quickly, but it moves away from old ones very slowly. That process has just begun. It will take a long time before it's really evident, but I think it has started.
Dunphy: Can you talk more about improving quality of websites, web apps. My thing is that improvements in JS frameworks like React don't necessarily lead to better quality products, just hopefully a better experience for developers.
Voss: I think it's correct to say that React in particular has been optimizing for the developer experience for a long time, and has to some degree sacrificed the user experience to do it. My position is that the net benefit to everyone is still better. Each individual React website might be a little bit slower, like I said, than a completely custom solution. The result of using React is that we are able to build twice as many or 5 times or 10 times as many websites as we used to. Websites have gotten a lot better since React came around. It's because React accelerated us and it made us able to put out more stuff more quickly. We have seen more pretty good websites at the cost of a very small number of very good websites. Personally, I'm ok with that tradeoff.
See more presentations with transcripts
