What JavaScript framework should we go with? That's a question you've probably seen posed a lot, and also answered a lot, and yet it's still really hard to settle on. When I started this project, almost two years ago, I was fairly burnt out with the JavaScript landscape. I loved the React API but wasn't in love with the results I was getting. I plowed along with my professional project, but from a personal perspective I completely stepped off the ship for therapeutic purposes.
I care a lot about web performance and building applications to stand the test of time. I felt personally helpless in my efforts to accomplish these things with this landscape, so I set off to build a simple server-rendered with virtually no JavaScript dependencies where I'd write everything in plain-old Vanilla JS when I needed to. The idea was that nothing on the web is as important to the user experience as speed/performance, and it's a great priority to hold as #1.
It was a great idea. Not only did I come up with a project I loved working on, but people loved the devotion to performance. What started as a personal project has grown up to serve about a-million-and-a-half monthly unique sessions, a lot of happy members and starting to grow faster than ever. We are now a small team which share these values (or at least accepted them as unmoving constraints). We've learned to treat our CDN as a critical layer in our stack and application logic, and to treat latency as a serious issue on the web—Especially outside of the United States.
I did not renounce JavaScript. As mentioned before, I just took a step back. For all the goodness of the initial choice, the plan was always to evolve when the time was right. Since the start of the project, I've been able to observe the ecosystem evolve and learn about what was most valuable for this project.
I've had my eye on PreactJS for quite some time. As I learned more about the project, it became clear that it shared my values. Here are the headings on the project's home page:
- Closer to the Metal
- Small Size
- Big Performance
- Portable & Embeddable
- Instantly Productive
- Ecosystem Compatible
These values speak to me big-time and I can see that there is a lot of care devoted to them. As mentioned before, I love the React API. The fact that me and my team can learn Preact by learning React, and then maintain an understanding of the differences and hiccups through attention to detail, is a wonderful way of working. I feel like we have super powers by implementing a faster React, even if there are tradeoffs.
The creator of Preact is Jason Miller. I gained more interest in the project as I looked into some of his presentations. I feel like he "gets it" and I'm happy to invest in his passion project.
I'm also quite pleased with his choice of attire.
Our team's first Preact feature is a new onboarding flow. The feature itself is live but still pretty minimal, as we shipped with intention to iterate. It's just the kind of feature we wouldn't have wanted to build with Vanilla and had held off on building altogether until we settled on an actual front end direction. Jess and Andy did most of the work in developing the feature, and they did a great job with it so far.
Jason also recently joined the Google Chrome team, which is an exciting development. Addy Osmani has talked about and written about Preact and I hope this means that Preact will get even more support and growth. It has been a great project.
dev.to is driven to be a great citizen of the web. We're having fun leveraging the powers of progressive web apps and I'm really excited for this feature to come to Chrome for desktop. We'll, of course, keep you up to date on all developments.
Latest comments (24)
How do you initialise
preactwith server rendered html? Does it go something like this*.html.erbviewdeferedHey Ben, outside of Dev.to's onboarding, is everything else server rendered html? (erb?)
"We've learned to treat our CDN as a critical layer in our stack and application logic, and to treat latency as a serious issue on the web—Especially outside of the United States."
I love this approach because it means that inefficiency/resource glut on the backend only hurts the service, not the user. If you want to write something quick, dirty, and inefficient, you're free to, and you only drive your own costs up, not hurt the end user experience. It's freeing.
When you say “faster” do you mean the smaller bundle size, or were there actual interactions that Preact handled faster?
In my anecdotal experience (and from speaking to people who did this in some companies) replacing React with Preact in interactive apps can actually make the interactions slower.
I’m not saying this to bash Preact but I’m just curious what specific measurements you did. I’m sure we both understand “closer to metal” is just marketing—both use the same language and similar data structures 🙂. Although again, I can see that for a small app the bundle size difference can be worth it.
Yes, primarily talking about bundle size. As a web app with our characteristics and outlook, this is a big priority. This could change depending on how browsers and the market/product evolve, but it seems like the right route for now.
I've been tinkering with hyperHTML, HyperApp, Preact, React, Snabbdom and others for some months now, and the one I'm really excited about is this:
github.com/picodom/picodom
It's a bit rough around the edges still (and I'm trying to help) but I love the concept of taking functional components all the way, which is made possible by having life-cycle events on every element - you no longer need a class/instance just to get the life-cycle callbacks, and that's powerful.
Using the SAM pattern, you can implement the entire view as a pure function of the model:
sam.js.org/
I have yet to experience first hand how this works out on a real project, but I'm excited!
Note that this isn't about the 1K footprint or even about performance to me - while those are nice side benefits, the main thing I hope to get out of this is just simply front-end code that anyone can read, understand and change 😊👍
I have also selected Preact for my side project. In this project the app has to be embedded in other websites and, therefore, it needs to be as slim as possible. With Preact I am now at 25 Kb (gzipped) level. I feel I can improve this a lot by rewriting the app with vanilla JS (I don't need to update DOM frequently) but I am not ready to sacrifice my developer experience just yet :-)
Can you share top 3 advantages and disadvantages of using Vanilla Js?
I'm curious to know how you feel about Google's AMP thing. Do you use it in dev.to at all? Something about it's always rubbed me the wrong way a bit.
The idea of performance-driven development is really interesting to me, and I think it's ultimately good for both users and devs. Thanks for making the world a more performant place!
I'll follow up on this later if I can gather my thoughts about it but not a fan overall
Ooh, I'd love to hear your thoughts on this. Especially since you've built a performant application.
Thanks for the great post !, I'm really excited about Preact being used in dev.to :D , it's a great alternative to React and I find it as an opportunity to understand the React codebase, Jason said that the idea of creating Preact came from the need to learn how React worked internally, you can check the whole conversation here Preact with Jason Miller.
There another library worth mentioning here : Inferno, it's also very powerful alternative to React.
I'm always happy to see devs who want to stick to vanilla-as-possible JavaScript! I LOVE React, but the heaviness of JS frameworks always bums me out a bit. I'm excited to check out Preact!
Sometimes it's about the journey. By starting from the ground and resisting the urge to rush into anything, we've been able to stick to our guns on performance. Far from a perfect codebase/product, but it hasn't become a total mess either 😁