DEV Community

Ben Halpern
Ben Halpern Subscriber

Posted on

Thinking about going with PreactJs for dev.to

The dev.to web application has been built on "vanilla" JavaScript for performance purposes specific to its architecture/tradeoffs, so we have not made a lot of use of libraries. But it's growing to become a sometimes-complicated app and some of the client code gets a bit spaghetti-like.

We are still going to render the core experience from the server, but interactive components on the site that are handled on the client like the follow buttons should probably be handled by a state-driven framework like React, Angular, Vue, what have you.

PreactJS is a 3kb view library meant to be a way more economical alternative to React and I think it's the right choice for us. We have experience with React on the team and it seems like a pretty clean way to handle our concerns.

Does anyone have thoughts on the matter, or know of any other libraries or blog posts we should check out that could help with this choice?

Top comments (48)

Collapse
 
elizabethgarcia710 profile image
Elizabeth Garcia

I'm currently working with Preact / Preact CLI on a project. The experience has been very positive. Having access to the React ecosystem is a huge win.
tai mu origin mu mobile lau.

Collapse
 
patrickodacre profile image
Patrick O'Dacre

While I prefer Vue, if your team will have the easiest time moving to Preact, then that counts for something.

Personally, the pace at which Vue is improving, and the official libraries like Vue Router, Vuex, makes Vue all the more attractive.

But again, all things being equal, sometimes the best tool is the one you know the best.

Collapse
 
ben profile image
Ben Halpern

This is not really an impending move, so I haven't even consulted the team yet. There are more React-knowing folks on the team. I have a cursory understanding of Vue, but would have to do more research. As an outsider, I haven't had an aha moment with Vue but from what I can see, we don't really need router/state management things. We don't do any client-side routing and what I really want is the ability to make small apps-within-the-app that are pretty self-contained.

@pandyzhao you've used Vue, right?

Collapse
 
andy profile image
Andy Zhao (he/him)

I haven't actually used Vue; my coding bootcamp recently switched to Vue, but I finished being a TA before that happened.

Most of my framework experience is with Angular 1 and 2, but I'm indifferent to it. Happy to try out Vue.

Thread Thread
 
ben profile image
Ben Halpern

Okay cool. Feel free to give it some thought and let me know based on what our constraints are. My gut is that it's not really meant for our type of app.

Thread Thread
 
dorianamouroux profile image
Dorian Amouroux

I think VueJS works great for either SPA or small features within a HTML page. You don't even need to have a complicated WebPack setup. You can import the library and start coding with no-configuration, and in ES5. You can progressively replace the vanilla js with VueJs components.

Thread Thread
 
easrng profile image
easrng

The same is true of preact. One line of JS pulls it in from pika

Collapse
 
patrickodacre profile image
Patrick O'Dacre • Edited

Vue is very self contained. It aims to be very easy to adopt in increments.

Laracasts offers a free series on Vue, and from a quick watch, you'll see how easy it is to get it working in small chunks.

And if you'll forgive the self-promotion, I have a few tutorials on Medium with some CodePens you can look at.

medium.com/vue-by-example

Collapse
 
galdin profile image
Galdin Raphael

I've worked with Vue, and it's awesome. I've never worked with react though.

However, since you mentioned the 3kb file-size and the fact that your team knows react, +1 for Preact 🙌

Collapse
 
ahmadawais profile image
Ahmad Awais ⚡️ • Edited

PreactJS is a fun choice. I'd say go with it. ⚛️ Preact core team is also very helpful for this kind of stuff. 💯

Collapse
 
spences10 profile image
Scott Spence • Edited

Or at least give it a Vue 😂

Collapse
 
_ergo_ profile image
Marcin Lulek • Edited

How about looking at Polymer 2.0 instead? It it built on web standards, it is fast, efficient and you can create nice reusable components with it.
Web components will work nicely together with preact so that is a good way to go too.

Collapse
 
ben profile image
Ben Halpern

This is a good thought. I sometimes forget Polymer exists, but I definitely need to introduce this into our discussion.

Collapse
 
_ergo_ profile image
Marcin Lulek

Lots of people tend to forget Polymer exists - but I think it is built precisely to fit your case.

Collapse
 
balajmarius profile image
Balaj Marius

You may want to check Inferno too, it is faster than Preact.

Collapse
 
ben profile image
Ben Halpern

Cool, I'll check it out. Thanks.

Collapse
 
nickytonline profile image
Nick Taylor • Edited

Inferno is all about performance. FB took notice so much, that the React team hired the creator of Inferno. I believe the bundle is smaller than React, but I think in terms of bundle size, Preact comes on top. the API is a drop in replacement for React 15, but for Fiber (React 16), as far as I know they are not compatible in some respects, e.g. Portals, Fragments. See github.com/developit/preact-compat....

If you're going to use it for follow buttons etc., I think it's a great choice.

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
ben profile image
Ben Halpern

No, we are explicitly not doing this. We plan to keep our basic Rails views for most of the rendered page, Preact will be responsible for rendering things like follow buttons, like buttons, personal extra data on the page, etc.

Collapse
 
Sloan, the sloth mascot
Comment deleted
 
jvanbruegge profile image
Jan van Brügge

Why not use a second Node server just for SSR? That's what I'm doing. My API is written in Haskell, but I also have a Node server that prerenders HTML for the client

Thread Thread
 
Sloan, the sloth mascot
Comment deleted
 
jvanbruegge profile image
Jan van Brügge

Isn't programming evey view twice a whole lot more work?
With docker, setting up another container you can route to is rather easy.
Maybe I will write an article about that

Collapse
 
jenlooper profile image
Jen Looper

I like Vue as well, but I'm quite interested in Preact. I think it will boil down to the maturity of these libraries when you need to move to prod. Will all the add-ons that you're going to need be available when YOU need them? It could be that, at this point in time, Vue's ecosystem is a bit more developed than Preact's. Someone prove me wrong, tho!

Collapse
 
johnlukeg profile image
John Luke Garofalo

I think that you've done the right thing by not jumping to a framework immediately, but I am a React Fanboy so I do think that you're hitting the point where it would make your life much easier.

Admittedly, I'm not very familiar with Preact specifically, but here are some of my thoughts on your choice that I think are worth considering. Obviously, there are many factors that only you can gauge so take everything with a handful of salt.

  • What is most important to you? Performance? Efficiency? Ease of Use? Dependency Independence™?

    • Preact is going to give you a light weight framework, but it's going to have less support than React. Additionally, the syntax/features may not be as up to date as React.
    • If you end up open sourcing, you're potentially raising your barrier of entry for contributors who may be discouraged by having to learn the differences between the two frameworks.
    • React may be overkill if you're sure that the complexities of the app aren't going to continue to grow. I love React but there's no sense in jumping in bed with it, if you just don't want all of the overhead or won't gain anything from it.
  • At some point, you're going to scale again, so it's worth considering whether the framework's value matches your needs later down the roadmap.

  • If server rendering is very important to you, you should also check out Next.js if you haven't already. It's not going to be more size-efficient than Preact but it may meet all of your current needs, while preparing you for scale down the road.

Ultimately, I think that you're making the right choice to move towards a framework at this point and I think that Preact is going to put you in a better position than you are in today, but it's worth considering what your future roadmap is telling you.

Young Padawan

I hope my ramblings provide you with valuable ponderings! Let me know what you end up going with :)

Collapse
 
ben profile image
Ben Halpern

Interestingly, I think the use of Preact covers a lot of the concerns you've outlined. Preact literally uses the React API more or less and is mostly different in how it's implemented under the hood. So React-knowledgeable devs should be able to come in and be productive quickly.

React, the "fully native" version of this sort of API is probably the best choice for "sure the app's complexities aren't going to grow". That's an interesting discussion because I'm sure the complexities will grow, but we're not designed like a single page app, so complexity in the components should remain pretty localized.

Thanks for your initial input, what do you think about these things?

Collapse
 
johnlukeg profile image
John Luke Garofalo

Interestingly, I think the use of Preact covers a lot of the concerns you've outlined.

Ah, that makes a lot of sense, thanks for clarifying! I've never used Preact so my opinions about it are subject to scrutiny.

React, the "fully native" version of this sort of API is probably the best choice for "sure the app's complexities aren't going to grow". That's an interesting discussion because I'm sure the complexities will grow, but we're not designed like a single page app, so complexity in the components should remain pretty localized.

Yeah that makes complete sense. It's hard for me to make a concrete opinion without reading through the code base, but you are obviously adept at considering the effects of each framework.

Given what you said, I think Preact is a great choice for you. Here's where I think you'll find the greatest value from Preact: I think that it would provide you with a way to introduce React Components to your code base and allow you to migrate to React fairly painlessly if your complexities call for it. Kind of like a "try before you buy" situation. You can slowly migrate some of the spaghetti into React as you go and if you need to migrate, then it should be pretty straightforward. Hopefully this provides a different perspective on the matter!

Collapse
 
koriolis profile image
Nuno Ferreira

I would take a look at MarkoJS, especially if you're rendering at the server. Because it doesn't use a DOM on the server it's really really fast.
Also love it's layered design and tons of other features. And it's really lightweight at only 11Kb and it's even faster than PReact or Inferno.

Collapse
 
bilalbudhani profile image
Bilal Budhani 👨‍💻

I would strongly recommend Preact from my personal experience.

  • It is a breeze to work on & has a very little learning curve.
  • The ecosystem of the framework is evolving in a good pace.
  • Preact already has a great amount of libraries around it's concept (for instance, preact-router etc.)
  • More and more companies are discovering it's use case & ease it provides.
  • Already a bunch of big players are using Preact in production apps.

P.S: I've authored a detailed blog post on Preact blog.codeinfuse.com/getting-starte...

Collapse
 
karolyi profile image
László Károlyi • Edited

spaghetti? I hope you use webpack or some other modularizer tool. if yes, you should modularize things and thus avoid spaghetti code.

guess what, I'm still using jquery with webpack and other widget npm modules pretty effectively. (I know, for some, jquery is cancer, but I really couldn't care less)

until shadow dom is supported natively by almost everything, I'm sticking with jQuery. I'm not the kind of guy who jumps on every bandwagon, be it angular or react.

Collapse
 
easrng profile image
easrng

I'm not going to the to get you to use a framework, but have you tried fetch and querySelector? The only reason these days for jQuery is IE support, and if you need that, I am sorry.

Collapse
 
ben profile image
Ben Halpern

For the time-being we do not use any modularizer tool. Code is organized via naming conventions. It's been fine for now but won't scale bigly.

Collapse
 
karolyi profile image
László Károlyi • Edited

I would give webpack + ES6 a shot then. I use it with gulp (as I do also stylus + sass with bootstrap 4), and it does wonders to the code.

see some samples at liveedu.tv/karolyi

Collapse
 
nitishdayal profile image
Nitish Dayal • Edited

+1 Preact. There are other libraries that might be more performant in certain cases, but performance and size aren't the only selling points Preact offers. Similarities to React API as well as a provided compatibility layer which allows the use of React-specific libraries with Preact are really nice. For a team that has previous React experience it can be an incremental migration (if the need is to get product pushed out quickly, start with preact-compat to get the foundations quickly laid out and then transition to full-on Preact as beneficial).

Community is great too. I creep their Slack channel and they're super friendly.

Collapse
 
ben profile image
Ben Halpern

Yeah, I'm getting a lot of great vibes from everything you're describing.

Collapse
 
jvanbruegge profile image
Jan van Brügge • Edited

I love Cycle.js, because it allows to be used for any application and still feel natural, while other frameworks tend to concentrate on the DOM and leave out the other stuff. One brilliant example here is HTTP with React/Redux. There are X redux middlewares, but it still does not feel first class.
I also like that with Cycle, you state your intentions explicitly, every possible interaction with the outside world (DOM, HTTP, WS, etc) is injected into your app.
Never had a better testing experience than with cycle.
Disclaimer: I recently became core contributor to cycle.

Collapse
 
ben profile image
Ben Halpern

At a high level, I really buy into Cycle.js, but I haven't yet found the time to dive into the details. As we ponder these choices without a strong deadline, it's a great time for me/us to give it a good look.

On a side note, you and anyone else on the team is super welcome to post on dev.to and use the platform to spread the Cycle gospel to your heart's content. I enjoyed your post from back in April. Cross-posting from other sources is welcome.

Collapse
 
jvanbruegge profile image
Jan van Brügge

I recommend watching Andre's introductory course, where he builds a toy Cycle from scratch.
Shows very well that there is no magic in Cycle.js, that you are able to write a toy version yourself (imagine that for Angular).

And i will post a few articles in the near future, at least one of them about Cycle.js

Collapse
 
dandenney profile image
Dan Denney

Disclaimer: I only have ~4 months experience with React and ~1 month with Preact.

Given that you're rendering server-side and primarily switching to improve the read/writability amongst the team, I definitely "thumbs up" Preact. Their focus on perf will align really well with serving content from the server and, as already covered in other comments, you don't lose anything that you'd need from React.

Collapse
 
darksmile92 profile image
Robin Kretzschmar

As already said by many others, value the inputs of the comments by yourself and take them as critical thought-provoking impulses.

On one hand there is the fact that you already have React experience on your team so it would not take much time to get on track with React.
On the other hand there is a nice post here about YAGNI (You aren't gonna need it). YAGNI maybe saying that you don't need React right now so go with Preact if it fits your needs for now.

My choice would be React and here are the arguments:

  • React done right prevents you from getting the mentioned spaghetti-like code.
  • With the future in mind, React may fit better for scaling purposes
  • The ressources on React and the community is (as of my knowledge) much bigger than Preact at the moment.
  • You have the React knowledge on your team, use it; don't loose it (by people possibly not ready to move to PreactJS)

Hope my few points can help you.