Ask HN: What is your front-end stack of choice if you start a new web-app today? | Hacker News Reader

Ask HN: What is your front-end stack of choice if you start a new web-app today?

13 pointsyonibot11 comments

If you begin a new front-end-heavy app today, what is your stack of choice?

The front-end world is changing at a dizzying speed, and it's making me nauseous. I'd love to adopt React, but I'm curious how other people are using it as part of a complete production-ready 2015 web app.

* Angular 2 is not yet ready, and will not be backwards compatible. * There are a million choices for flux implementations, and it seems like the community hasn't yet converged on any one choice. * Are people successfully using Rails with their flux implementations in production?

View on HN

I would suggest Meteor. It is not purely a front end stack, but a full stack. However, since you mention flux and rails it seems you might also be interested in a backend.

Meteor has a bit of a reputation as a "playground" stack. The sort of stack you pick when you need to implement something quickly but might want to rewrite it before production. However, I find the Meteor stack to be very production ready and have a few applications I have built and use that have high traffic built with Meteor.

As for frontend heavy applications, I would consider looking into the Meteor React integration. Meteor is giving React first class support. The native blaze engine isn't bad but I do prefer React.

One final note, Meteor's community is fantastic. The irc channel always has a number of helpful people in it. And there are many people actively helping to answer just about all Stackoverflow questions. I highly recommend it.

I've been heavily leaning towards Cycle.JS lately (http://cycle.js.org) for personal projects. I haven't pushed anything to a Production environment yet, but I really love Cycle a lot more than React. (Cycle is vaguely like React, and explores some similar goals, but Cycle is based on RX and encourages a stronger, immutable functional composition than React.)

For production applications at the moment I'm still mostly using Knockout as it is reliable and runs almost everywhere.

Ractive.js is one of the frameworks I've been used for more personal projects as the learning curve is a lot less than other modern frameworks out there.

Otherwise for work, I'm mainly using Angularjs 1x version, not sure whats going to happen once Angular 2 is ready for production

I'm also using 1x, but not sure what to do for new production apps right now.

React, react-router, Backbone models, https://github.com/magalhas/backbone-react-component, systemjs, jspm

I don't have a personal opinion on the matter, as I'm not familiar with the wide variety of JS stacks, but the most visually attractive projects I've seen so far were made with Rails + EmberJS (and React is some cases).

"Visually attractive" is completely orthogonal to the technologies you use.

Orthogonal means 'irrelevant'? Might be, CSS and JS comes in many flavors.

What does anyone think of Aurelia? (http://aurelia.io)

I was a fan of its predecessor Durandal for providing a good set of conventions for a SPA built with Knockout. Once Knockout added components, however, I started switching back to raw Knockout and maybe a router library.

Aurelia to me is interesting. I appreciate that it's still modular and well architected like Durandal. In that regard I trust Aurelia more than I would trust, say, Angular (1.0 or 2.0). I like that Aurelia is encouraging people towards JSPM (and SystemJS), which I've been recommending as well.

That said, I don't think I would actually use Aurelia in a project. For applications that need a deep legacy support it's clearly still the best option to use Knockout and Knockout Components (and maybe Durandal, but maybe not). For applications targeting the "evergreen" browsers I've been leaning towards CycleJS, not just because the "Reactive" frameworks are the new hotness, but because even in my use of data-binding frameworks like Knockout I've been slowly leaning more towards the "Reactive ideal" anyway and now that CycleJS is 1.0 and stable that looks like a good place to start these days.

Just over a week ago I thought I'd ask why HN itself seems so incredibly fast: https://news.ycombinator.com/item?id=9990630 I got some pretty interesting replies (and someone from CloudFlare even checked in at one point!).

I argue that if you want to make a site that's impressive and memorable, make something that loads like "∗clic∗--kaching!" At least in my case, you'll get an immediate "Wait. What? Wow." out of me. :P

It can be done. I thought there was some secret sauce somewhere, for HN. There isn't. The pages here are, on average, <25KB - one person showed that my post, replies and all, was only 12K (compressed). That's quite impressive, and it's what makes all the difference.

Obviously, though, there is a tradeoff: you have to be really, really good at JS to get frameworkless code right, fast, without much mental effort. For prototyping and rapid development (and let's face it, rapid is the new "normal", sadly, and has been for quite a while now), using a framework is obviously the wise choice.

Looking at the problem from a slightly different angle, if you take the .NET-vs-WinAPI problem of a couple years ago, .NET slowly gained adoption and is pretty much standard now, and most devs use it for everything.

And yet you can build dependancyless ~30KB GUI applications with the standard API.

One of the big things that made .NET standard was the fact that it became a standard part of Windows. That hiked adoption up quick: suddenly people didn't have to download a 300MB support package.

But you can't "install" a support framework into the browser such that it stays put. A JS framework has to download every single time. This is so obvious it's almost a nonconsideration but I think it's worth remembering, because current mobile browser caches can decide to make themselves less than 200KB. 200KB.

I think that a "precious trusted cache" would revolutionize a lot of things, but looking at the current state of things, I doubt such a system is likely to be implemented. :(

For larger projects, or wherever you have an opportunity to slow down a little, I say strongly consider rolling your own code, so you can control everything and cut down on bloat.

If you want to go even deeper, here are a couple more links: https://news.ycombinator.com/item?id=9791606 (from a reply to my post), https://news.ycombinator.com/item?id=6825557 (from a reply in #9791606)

Reply on news.ycombinator.com