Why we went with PreactJs to power the dev.to frontend

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.

Comments

[Dan Abramov]

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.

[Ben Halpern]

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.

[ImTheDeveloper]

Have you or any of your guys/gals played with Vue.js as of yet? I've been messing around with a bunch of frameworks as of late and I have to say preact somehow missed my list so I'll be giving it a run when I next have some time and a suitable use case for it. Would be interesting if there's any comments though to compare against vue as I've been using that for a couple of months now after finding react a little too heavy for my liking, but ultimately they all play in the same space with similar structuring.

[Ben Halpern]

Vue seems like another well-crafted post-Angular-1 project with some really friendly functionality. Just look at some of the code from the official guide.

<div id="app-5">
  <p>{{ message }}</p>
  <button v-on:click="reverseMessage">Reverse Message</button>
</div>

var app5 = new Vue({
  el: '#app-5',
  data: {
    message: 'Hello Vue.js!'
  },
  methods: {
    reverseMessage: function () {
      this.message = this.message.split('').reverse().join('')
    }
  }
})

Really easy to see what's basically going on here. A lot more baked-in niceties than React that can clarify the syntax. It's also built around easy onboarding/adoption as a key feature. I can see why people like it. If I played around with it more, you might be able to get me excited, but for all the things we really care about, Preact seems like the clear choice for us.

These posts by @neradev are a really good introduction to Vue

An introduction to Vue.js - Chapter 1 - Basic Setup

Moritz Schramm

#javascript#vue

[Rémy 🤖]

VueJS is indeed a post-angular tool, but it would be very short-sighted to reduce it to that:

• There's an amazing Webpack loader for components (just try it out)
• If you like JSX (meh) well there you go
• States update are detected automatically
• There is server-side rendering (see projects like Nuxt)

It's really my default (and only) go-to framework, I've never heard anybody complain about it (not even the guys that said "I'll never do front-end again it's too crappy")

[ImTheDeveloper]

I've built a couple of projects now with the early nuxt versions and its been great. I'm really tempted to give it a run within an electron app since I found the learning curve very quick to jump onto.

[Rémy 🤖]

I've used it on U2Guide and yeah, it rocks (well, I had to leave the project before then end, but anyways).

[Hamza]

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.

[Devin]

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!

[Ben Halpern]

I'll follow up on this later if I can gather my thoughts about it but not a fan overall

[Phil Nash]

Ooh, I'd love to hear your thoughts on this. Especially since you've built a performant application.

[Daniel Golant]

"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.

[Natalie Martin]

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!

[Ben Halpern]

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 😁

[David Alberto Adler]

How do you initialise preact with server rendered html? Does it go something like this

1. Server rendered rails *.html.erb view
2. JS is loaded by execution is defered
3. Preact deletes HTML and rerenders?

[Nick Polyderopoulos]

Hello,
Thanks for this beautiful post about the internals of dev.to.
Are there any other blog posts like this ? to learn more about the infrastructure that you used and why ?
I'm pretty interested in the backend technology (i am more of Backend Dev)

Thanks.

[Ben Halpern]

This question has me thinking that we should make it easier to do sub-queries on users and tags because the answer is a big yes but it could be hard to find. Anyway, here are some key posts:

What it Takes to Render a Complex Web App in Milliseconds

Ben Halpern ・ Aug 18 '17 ・ 4 min read

#webperf #meta #cdn #webdev

The dev.to tech stack

Ben Halpern ・ Aug 9 '17 ・ 1 min read

#ourstack #meta

Making dev.to Incredibly fast

Ben Halpern ・ Feb 2 '17 ・ 5 min read

#webperf #meta

This is also going to be, more or less, the subject of my talk I'm preparing to give at CodeLand and then again elsewhere after that if all goes well. Making it into a good talk will really force me to center in on the core concepts we work with.

[Nick Polyderopoulos]

Thanks for the fast response :)

You could make a tag only for that i suppose.
If this tag is unique it would super easy to search. (Basically this is what i tried before asking you :) )

[Ben Halpern]

Somehow I never thought about getting this granular with tags, but that's a perfect scenario. Will definitely think about doing that and pushing that functionality.

[Yuri Polchenko]

Now after two years of online life, what do you think of PreactJs as framework and what is your recent 2020 choice of JS Framework or other methodology?

[Rasmus Schultz]

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 😊👍

[Alex Rudenko]

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 :-)