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?
Latest comments (48)
I think you should look in to web components, especially lit-element.polymer-project.org/ . That said, preact seems good too.
Not related but I was looking at the code:
Double quote after comment-deep-1.
Hey Ben
How Preact working out for you ?
And please also write a blog about rails performance and optimizations . If possible some tricks about heroku .
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:
Hope my few points can help you.
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.
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.
This is a good thought. I sometimes forget Polymer exists, but I definitely need to introduce this into our discussion.
Lots of people tend to forget Polymer exists - but I think it is built precisely to fit your case.
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.
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.
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
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.
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.
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.
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
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.
I would strongly recommend Preact from my personal experience.
P.S: I've authored a detailed blog post on Preact blog.codeinfuse.com/getting-starte...
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!
I love this change. React is great 👍 However, Preact.js is super awesome for the web and my mobile's data / battery. What a great decision!
+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.
Yeah, I'm getting a lot of great vibes from everything you're describing.
PreactJS is a fun choice. I'd say go with it. ⚛️ Preact core team is also very helpful for this kind of stuff. 💯
Or at least give it a Vue 😂
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.
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
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