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

Ben Halpern on December 18, 2017

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... [Read Full]
markdown guide
 

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.

 

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.

 

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

 

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

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.

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

 

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

 

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

 

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.

 

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:

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.

 

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

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.

 

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 😁

 

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?
 

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

 

Hey Ben, outside of Dev.to's onboarding, is everything else server rendered html? (erb?)

 

Can you share top 3 advantages and disadvantages of using Vanilla Js?

code of conduct - report abuse