

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

If you begin a new front-end-heavy app today, what is your stack of choice?<p>The front-end world is changing at a dizzying speed, and it&#x27;s making me nauseous. I&#x27;d love to adopt React, but I&#x27;m curious how other people are using it as part of a complete production-ready 2015 web app.<p>* 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&#x27;t yet converged on any one choice.
* Are people successfully using Rails with their flux implementations in production?
======
trcollinson
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.

------
WorldMaker
I've been heavily leaning towards Cycle.JS lately
([http://cycle.js.org](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.

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

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

------
mwhite
React, react-router, Backbone models, [https://github.com/magalhas/backbone-
react-component](https://github.com/magalhas/backbone-react-component),
systemjs, jspm

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

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

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

------
gradschool
What does anyone think of Aurelia? ([http://aurelia.io](http://aurelia.io))

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

------
i336_
Just over a week ago I thought I'd ask why HN itself seems so incredibly fast:
[https://news.ycombinator.com/item?id=9990630](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](https://news.ycombinator.com/item?id=9791606)
(from a reply to my post),
[https://news.ycombinator.com/item?id=6825557](https://news.ycombinator.com/item?id=6825557)
(from a reply in #9791606)

