
Guide to JavaScript Frameworks - kiyanwang
https://javascriptreport.com/the-ultimate-guide-to-javascript-frameworks/
======
joaodlf
I come from a pure HTML + CSS + JS (mostly via jQuery) background. My career
has headed in a direction that focusses a lot less in the frontend web, but
every 2 months or so I read one of these guides and I get giddy - "Finally, I
will teach myself angular/vue/react/backbone/knockout". After about 10 minutes
I am filled with dread. I expect to learn about a specific piece of software,
instead, I am greeted with requirements of previous knowledge on a whole
bouquet of other technologies: node, webpack, babel, grunt...

It's just discouraging. This whole thing feels like a farce. I watch
colleagues investing time in this and I feel sorry for them.

~~~
yesenadam
I learnt a lot from the article _Modern JavaScript Explained For Dinosaurs_
[0] (featured on HN recently), which explains the history of developments from
vanilla JS to 2017, "a historical context of how JavaScript tools have evolved
to what they are today". I thought it was brilliant at making sense of the
jungle you describe.

I'm pretty sure it will remove the dread.

[0] [https://medium.com/the-node-js-collection/modern-
javascript-...](https://medium.com/the-node-js-collection/modern-javascript-
explained-for-dinosaurs-f695e9747b70)

~~~
vanilla_nut
Thank you for this, this is fantastic. Exactly what I was looking for (not a
dinosaur, just a back-end dev who's curious about a lot of front-end tech).

------
3pt14159
The rumours of Ember's demise are greatly exaggerated.

I have yet to hear of people making the same amount in any other framework.
Seniors are making $200k to $500k in _remote_ positions (the people I know
live in Toronto, but they could be anywhere).

It is hard to learn, and I'm far from an expert, but the highest I've heard
another JS developer who knew both Angular _and_ React completely and he was
responsible for migrating a company from one to the other and he was just
starting to get into that range.

Large SPA JS applications are easier to structure in Ember because there are
so many best practices. The problem with Ember is the learning curve because
it doesn't usually let you take shortcuts.

~~~
adjkant
I'd point out that often rare and often unused skills get higher pay due to
simple supply and demand. I've heard similar salary ranges for Assembly
programmers for example.

Angular and React are widely used, and there are many people out there that
know them. No need to pay a ton.

> The problem with Ember is the learning curve because it doesn't usually let
> you take shortcuts.

I'm guessing that's precisely one of the main why it's not used widely. Why
train an entire dev team on it only to have half leave in a year and have to
be constantly retraining on a language with a large learning curve?

~~~
HatchedLake721
It’s not a language, it’s a framework. You can take any experienced JS
developer and make them proficient in either Ember or any framework mentioned
in the article within days.

People overexaggerate how difficult each framework is. They’re all front end
frameworks made to do one job. Yes, each of them have their own nuances, but
nothing that cannot be understood spending few days coding, reading docs and
speaking with someone experienced in this particular framework.

~~~
tbranyen
Completely untrue. I was at Bocoup and we wanted to standardize on Ember. It
took weeks to get devs doing the basics in a large app. Ember isn't gone
because its misunderstood. Its gone because we can build the same apps using
more suitable libs/frameworks, in a fraction of the time, with less code, less
magic, and less upgrade burden. Ember sucked at upgrades, even though they
tried to make it better.

~~~
csallen
Ember isn't gone or anything close to it.

~~~
RobertRoberts
Not to be a jerk, but can you provide any links to large sites or apps that
use Ember? Again,this is a serious question, as I like to keep tabs on trends
for JS stuff like this.

~~~
_Tev
LinkedIn uses ember, but other than that I have not heard about big examples
either.

~~~
3pt14159
Netflix, FreshBooks, Apple Music, Square (the Dashboard), many others.

------
djsumdog
It doesn't mention [http://vanilla-js.com/](http://vanilla-js.com/)

:-P

I know it's just a joke, but maybe there should be a section about not using
frameworks at all? I'm also curious about the weight of these frameworks. Once
you minify and treeshake everything, what's the minimum you can get down to in
order to deliver an app?

Also, do any of these frameworks have a way to degrade for people without
Javascript enabled? From what I understand, the only way to do this seems to
involve some server-side rendering (and it looks like JS is still required).

I'm also really curious how heavy React/Vue/etc are compared to the original
gmail implementation back in 2004 (only of the oldest major javascript/ajax
applications that minimized page refreshes).

------
dandersh
Wow, Dojo is still alive and kicking! I'm going to have to find some time to
take it for a spin. I really like the idea of framework that looks to address
a few needs, making framework selection easier and less reliant on "Oh
Framework X is popular now? Let's use that and hire a bunch of devs for it..."

While Dojo is there, I'm surprised ExtJS is not. I haven't worked with it
directly for quite a few years but I know it is still being supported. I seem
to recall some backlash around licensing issues so maybe that's caused a dip
in market/mindshare?

I liked Elm when I played with it, especially the similarities with Haskell.
Unfortunately they had moved away from some of the Haskell like syntax shortly
after I started with it, and I didn't feel like I fully understood how to use
JSON properly.

Kind of surprised to not see Meteor on there. Haven't used it for awhile, and
iirc there were concerns around security, deployment, MongoDB lock in (which I
thought they were moving away from?) at the time. For smaller, personal use
projects I felt I got moving quicker and easier with Meteor than anything
else.

I'd love to see something like this for libraries and tooling. Really feels
like a lot of worthy choices, and therefore a lot of high-level knowledge
needed to understand which to choose and when.

~~~
rmrfrmrf
Dojo is literally Satan. Stay far away!

------
ZenoArrow
Purely from an outsider perspective, it's interesting to see all the different
frameworks out there, but for front end devs I can't help but feel that this
type of comprehensive list hinders more than it helps. One key thing JS needs
less of is fragmentation. If I were in the front end dev community I'd want to
see people making the front runners more mature and flexible, not endlessly
fragmenting just because they slightly disagree with what a more established
framework does.

Looking through a number of the entries in this list you read that it was
"inspired by React". Why not just make React more flexible so that your
alternative way of handling code fits within it? Does each of these new
approaches really require a whole new framework?

Contrast this with something like the .NET Framework (which is something I'm
more familiar with). Whilst the CLR has the potential to run frameworks other
than the .NET Framework, you don't see the same churn in frameworks that you
see with JS. I'd suggest this is due to a mixture of two things:

1\. A greater focus on getting things done over code elegance.

2\. The more mature a framework becomes, the more work is required to match
its feature set.

On this second point, if JS continues its constant framework churn, it'll be
stuck with immature frameworks. I'd suggest that JS devs should be doing what
they can to get past this stage, and if that means (for a few years) treating
new frameworks as interesting experiments rather than the next big thing, then
that may be a cost worth paying.

~~~
RobertRoberts
I actually think fragmentation is ideal, it demonstrates the failures in a
system more cleanly. For example, I started with Protoype.js many years ago,
after a bunch of research at the time. But then later switched to jQuery,
because it was simply better in every way.

There simply was no fixing the problems with Prototype.js, they were inherent
in the system.

I think when a fragmentation occurs in every framework, its for the same
reason. Consider Angular 1 to Angular 2, they broke backwards compatibility
because they had too. Angular 2 could have been called something else, and it
would be viewed as "fragmentation" not an "upgrade", but in effect, it was
fragmentation.

This is the exact reason why I think all of these frameworks will ultimatly
end up in the dustbin of history. Does any major programming language in the
last 30 years use a framework that requires multiple build systems, multiple
"dialects" of differing syntax just to do what is inherently available
already? (but just faster and easier?)

This sounds like the end result is Webassembly, not the "perfect framework".

~~~
ZenoArrow
The end result may be development without a 3rd party frameworks, perhaps in a
way that allows you to mix and match libraries without needing to use a large
underlying framework. However, as things stand now there is clearly a need for
JS frameworks. They are plugging gaps in vanilla JS.

My argument isn't that frameworks do not have any utility (right now), my
argument is, if you stick to a smaller selection of frameworks and work on
both polish and flexibility, you'll have frameworks that make people want to
develop in JS. At the very least it'll mean that the basics would be easy, and
design decisions could be deferred until later in the site design.

------
paul7986
Did you learn Jan2018.js yet?

If not your behind and your skills are outdated.....

~~~
Klathmon
I know people love to shit on JS for being blisteringly fast, but does it
really apply here?

All 3 of "the big 3" are over 4 years old, making all of them older than
windows 10...

And of the notable category:

Aurelia: around 2014

Elm: around 2013

Inferno: around 2015

Polymer: 2014

Preact: 2016

ReasonML: 2016

Svelte: late 2016

So most a few years old. Yes, it's faster than older technology stacks,
because the web is still evolving quite quickly, but it's not as blisteringly
fast as many make it out to be.

~~~
expertentipp
They appear and disappear as fast as startups and projects which use them:)

~~~
Klathmon
Do you have any information or statistics or studies to add, or did you just
want to post your quippy oneliner?

~~~
RobertRoberts
I would actually like to know if there's a list of systems, apps, sites,
whatever, that are using any particular framework. Using data from
Stackoverflow or NPM downloads just isn't the same as real-world examples of
actual use.

~~~
Can_Not
Have you tried [https://stackshare.io/](https://stackshare.io/) ?

------
azangru
How did ReasonML (a dialect of a language), or Elm (a language) end up in the
list of JavaScript frameworks? Whereas ClojureScript (a language) or
Purescript (a language) didn't make it, but libraries/frameworks built on
Purescript did.

It doesn't make sense :-/

------
electrotype
I'm still using Jquery and some of the millions js libraries available only
when you do not bind yourself to a SPA framework taking control of the DOM.
And it work pretty well I must say!

My opinion is that for 80% of the websites out there, a SPA framework is not
only overkill, but is also a bad choice. Your website is probably not Gmail or
Facebook. Server side rendering is perfectly fine.

We should start a competition where any framework/no-framework could be used
to develop a project and judge the winners using metrics such as : time it
took to develop it, compatibility, accessibility, fun to interact with.

~~~
expertentipp
Web 1.0 (html and hyperlinks) is still valid and working perfectly. Web 2.0
(AJAX and DHTML) is still valid and working perfectly. Web 3.0
([MVC][MVC][MVC][MVC]) is basically a fully client side application. It takes
a professional to identify which solution will be the most optimal given the
requirements.

...and yeah - most likely you don't need React+Rxjs+Redux for a wizard-like
prev/next multi-select online-quiz, but it's me looking for a job so you're
right. Hell - let's throw in async/await as well. You'll need a space shuttle
to debug this thing.

~~~
RobertRoberts
Nope, I think regular people are completely able to judge.

Which do you prefer, Youtube from a couple years ago, where every page was a
page? Or now, where every page is 15 weird loads of something with blank
blocks and comments taking a minute or more to display?

Regular users' opinions should matter more than a developers, as they are the
ones who use it.

~~~
expertentipp
In case of youtube the clients are copyright owners and advertisers, not
users/viewers. Apparently for the former two this is the perfect experience.

------
yesimahuman
Shameless plug, but I think Stencil should be on this list:
[https://github.com/ionic-team/stencil](https://github.com/ionic-team/stencil)

It's going to be running behind all Ionic apps in the near future, that's
hundreds of thousands of apps in the app stores and the web.

Also, SkateJS is missing. Both Stencil and Skate are Web Component libraries,
"frameworks" insofar as React is a framework.

------
phillipcarter
> What is less apparent is that Vue has had roughly double the growth rate
> over the past year compared to Angular.

Given that you cannot see its growth over the past year in in the chart this
guide shows, some might say it's "not apparent at all".

------
ralmidani
I am trying to transition from Ember to React, but calling Ember "historically
significant" is odd given adoption by big name companies (including Apple and
LinkedIn) and very active development (3.0 should be out in a few weeks).

~~~
szines
You are totally right... Ember is adopted and actively used by more and more
places, people loves it and very easy to work with. Ember evolve a lot all the
time, definitely one of the best choice nowadays.

------
keithnz
I like that the only con for Vue is there's no jobs for it. Having done two
major projects in React and Vue, Vue is my preference. While vue is supposedly
faster, speed has never been an issue for either. I think the biggest thing
for me is it's just easy. While I like React, I think vue is nicer and often
more concise, and if you really want jsx, it also supports that.

I also use Bulma for the visual side which works nicely with vue.

~~~
swyx
i mean its also because the author is obviously biased toward vue. see the
other comments here for why people actively pick react over vue. dont confuse
the printed word for fact.

~~~
keithnz
also don't be confused that even when biased it doesn't change the facts.

I built major things with both react and vue, I like both, but I like vue
more.

------
LeoNatan25
The Ultimate Guide to JavaScript Frameworks: Use pure HTML, CSS and JS.

~~~
debaserab2
What is pure HTML and when does it become impure?

~~~
LeoNatan25
When you build a browser insider a browser (aka React), it’s impure.

~~~
debaserab2
So JavaScript dom manipulations are pure? but one specific technique of dom
manipulations are not?

~~~
LeoNatan25
It's not specifically the DOM modification but the way those frameworks are
designed. With React you have hundreds of dependencies, which have hundreds of
dependencies. You lost me right there.

~~~
debaserab2
React has zero dependencies to use it, actually.

[https://github.com/facebook/react/blob/master/package.json](https://github.com/facebook/react/blob/master/package.json)

~~~
RobertRoberts
Can you use react without Node or NPM or a compiler/transpiler or build tool?

~~~
debaserab2
Of course - just pop it in a script tag and use the React object functions to
render your DOM (which is exactly what transpiled code does)

~~~
RobertRoberts
I've looked into Vue.js, and they seem to indicate that it's easier to get up
an running than react (using what you describe here). Are you suggesting
vue.js and react work exactly the same?

~~~
debaserab2
I don't know because I don't use Vue. What you'd be missing if you dropped in
the react library and did no compilation at all is the ability to use JSX. I'm
guessing vue's argument is their attribute tags still work in their minimal
deployment whereas with React you'd be manually wiring up things to the React
object functions.

So, with React, instead of:

    
    
        return <div>My component!</div>
    

You use:

    
    
        return React.createElement('div', {}, 'My component!);
    

Some people like the more implicit style anyways (although I don't and I don't
know anybody who does at this point)

------
CryoLogic
Ember isn't anywhere close to dead.

LinkedIn, Apple, Microsoft Store, DigitalOcean, Twitch.tv... Still actively
developing on Ember.js. Version 3.0 is coming soon.

Unlike React/Vue EmberJS has LTS support releases as well which is less risky
for corporations.

------
JepZ
> Vue.js: Current job market is less than that for React and Angular

Sounds more like a pro to me as it is the up-coming alternative.

~~~
marsRoverDev
This is good for Vue

------
gatkinso
Choo is pretty underrated IMO. Very small and fast, vanilla js, real DOM node
diff, simple state management and routes built in. Also a very supportive
community, esp Yosh.

------
GoToRO
SEO friendly? Server-side rendering support?

~~~
chuckdries
Vue and react have SSR frameworks, as I'm sure many others do as well.

I'm not sure if it's a big enough feature to include in the tags this site
uses. ¯\\_(ツ)_/¯

~~~
http-teapot
For React, could you link a few? I am genuinely interested

~~~
chuckdries
I don't actually use any of this, so I'm not intimately familiar, but I found
a promising looking framework and a help article on redux itself.

[https://github.com/zeit/next.js/](https://github.com/zeit/next.js/)
[https://redux.js.org/docs/recipes/ServerRendering.html](https://redux.js.org/docs/recipes/ServerRendering.html)

------
netcraft
Whats the right choice for building a repacement for an existing app that has
survived for 15 years and you want the replacement to last at least another
10? Whats the long term hedge?

~~~
ggregoire
If you think Facebook will still be there in 10 years, then you can safely
pick React.

~~~
amclennon
> If you think Facebook will still be there in 10 years, then you can safely
> pick React.

At the same time, you could've made that same argument at some point with
Google and AngularJS, Dart, Polymer, etc.

Not necessarily a safe bet.

~~~
netcraft
I completely agree re: sponsoring company - although react seems to be orders
of magnitude more popular, so someone is going to have to be supporting these
apps that people are creating now you'd expect, right?

------
mhale
Ember is the PostgreSQL of JavaScript frameworks.

Similar to the way Postgres has deep roots that trace back to Ingres[1] in the
days before SQL was a solidly established standard, Ember traces it roots back
to SproutCore[2] in the JS framework pre-historic era of 2010.

And the same way PostgreSQL was seen as a second-tier or only "historically
significant" open source database, the PostgreSQL team just kept at it,
toiling away year after year, steading churning out awesome code and excellent
documentation, getting better and better with each release. Like clockwork.

In the same way PostgreSQL is now, finally, enjoying more popularity and
getting the recognition (long overdue in my opinion) for the awesome platform
that it is, I expect that in time more developers will come around to
appreciating Ember. The Ember leadership is definitely approaching the project
and the processes around it like they intend to be not just relevant but
pushing the boundaries for a long time to come.

For one example this boundary pushing, you should not miss @tomdale's talk at
ReactConf about GlimmerJS (the view layer extracted from EmberJS). It is, in
my humble opinion, simultaneously mind-blowing and and inspiring.[3]

[1]
[https://www.postgresql.org/about/history/](https://www.postgresql.org/about/history/)
[2] [http://yehudakatz.com/2011/12/12/amber-js-formerly-
sproutcor...](http://yehudakatz.com/2011/12/12/amber-js-formerly-
sproutcore-2-0-is-now-ember-js/) [3]
[https://www.youtube.com/watch?v=nXCSloXZ-
wc](https://www.youtube.com/watch?v=nXCSloXZ-wc)

------
Tehnix
Starting from fresh, I would honestly recommend PureScript or Elm (and
eventually Haskell/GHCJS when that moves to WASM).

The benefit you get from the amazing type systems and compilers these have, is
worth so much when it comes to refactoring, and later on boarding new people,
giving them the confidence to make changes thanks to the help of the
compilers.

~~~
ggregoire
If you want type-checking, going with React + Flow/Typescript is a wiser
decision than choosing Elm. Better support, better ecosystem, much bigger
community by a huge difference.

~~~
scns
If you want strong static typing on par with haskell, check out reasonml.

------
wetpaws
Here is a guide: All of them suck (with the exception of react which is not
actually a framework). Wait for 10 more years.

------
watty
What are the "clear best practices" for Angular? I'm just starting in Angular
5 and I'm starting down the ngrx path. From what I can tell there's many
different ways to structure the project and ngrx is in version hell - the
current docs on master reflect an unreleased version.

------
bcit-cst
Honest Question. What is breakdown of market share angular versions market
share? does anyone have these stats? I know not a lot of new projects are
being done in angular 1 but I am under the impression that majority of jobs
are still for angular 1.

------
owlfarm
domvm is the most underrated in this list. one of the fastest and smallest out
there that's dependency free.

[https://github.com/leeoniya/domvm](https://github.com/leeoniya/domvm)

~~~
jim_combinator
I concur! I've been going knee deep in experimenting with this over the
weekend. I like the ala carte approach if that's the right way to describe it.

------
dsego
Since when does a small library or even a single function count as a
framework? Shouldn't a framework provide some sort of structure and I just
plug in my app-specific code?

------
tenaciousDaniel
Today I was playing around with a webpage, and realized it was the first time
I had directly touched the dom in like a year and a half. It was so simple and
joyful. I miss it.

------
tomkinson
I'd like to see pro and cons for all the lower 'smaller' frameworks and
methods. Maybe we can contribute? I have used many of them. Seems like the
ones with pros and cons, React, Vue, Angular etc everyone already knows. I
think there is opportunity here to give more depth to lesser known frameworks.
The top 5 are pretty well discussed at this point.

------
arvinsim
What do you think is the long term prospects of frontend development?

I have come to terms with continuous learning in frontend but I can't help but
feel that I am standing on unstable ground. That one day, all the knowledge
that I have accumulated would become irrelevant.

I have come to the point that I am learning backend using Python just to have
a fallback.

------
lmiller1990
Not really sure I get the constant Vue v React debate. They both do basically
the same thing and each support almost all the concepts the other does. Both
are great, neither is significantly better (after about a year full time with
both in various projects).

------
pdm55
[https://jrsinclair.com/articles/2018/react-redux-
javascript-...](https://jrsinclair.com/articles/2018/react-redux-javascript-
architecture/)

~~~
pdm55
That link was recommended to me as a simple, clear explanation of React. I'm a
real minimalist - just plain vanilla Javascript serves my purposes - but I'm
glad I read parts of that explanation, as I got familiarity with the term
"render" and could see that React is the go-to framework for mobile.

------
tw1010
Yes, it's a lot. But imagine the opposite. Imagine nothing new came out, and
everything just stagnated. Evolution, experimentation, testing things out,
this is a _good_ thing.

------
davedx
Read with interest to see what it said about Vue: better performance than
React and Angular. Is this true? Any real world benchmarks to back it up?

~~~
ricardobeat
Linked at the top of the article: [https://rawgit.com/krausest/js-framework-
benchmark/master/we...](https://rawgit.com/krausest/js-framework-
benchmark/master/webdriver-ts-results/table.html)

------
andrew_wc_brown
Come on. Where the heck is Mithril.

------
ausjke
to me the war is already over, for new projects, just start with react, react-
ecosystem probably will become the dominant framework from 2018 on.

------
bricss
Mithril is a good one

~~~
pdfernhout
I second Mithril as a great choice. Two things I wrote in it:

[https://narrafirma.com/try-narrafirma/](https://narrafirma.com/try-
narrafirma/)

[https://github.com/pdfernhout/Twirlip7](https://github.com/pdfernhout/Twirlip7)

Combining Mithril ( [https://mithril.js.org/](https://mithril.js.org/) ) with
Tachyons ( [http://tachyons.io/](http://tachyons.io/)) or a similar CSS
approach is also a great option to avoid having to write that much CSS. That
way almost all your code can be in one language and easy to refactor --
especially if you use TypeScript.

------
patientplatypus
Reasons why Vue will rock your socks off

\- Don't need to know jsx!

\- Sane way of scripting puts the script in an object and each component is
<template>html</template> <script>javascript</script> <style>css</style>

\- Event buses allow sharing of variables between child components without
either redux or pushing variables down one child at a time (finally!)

\- v-for looping is saner than reacts mapping

\- v-if allows v-if statements without renderIf component or multiple render
statements in react (antipatterns boo!).

\- two way data binding with vue-model

\- native vuex with an index file that holds state sanely, rather than just
having state held in each reducer as done in react

\- Great documentation!

\- Yay !

~~~
mlsarecmg
The points you've listed are the very reasons why i would prefer React
actually ...

\- JSX _fixed_ all the templating issues from 10 years ago, i see no reason to
go back to dependency injection, scope loss, arbitrary code-in-html expression
and a semi-javascript accent

\- Presentational view logic belongs to the controller while business logic is
elegantly abstracted in React: view=fn(state). There's no point in ripping
view creation from the presentational layer.

\- Context and higher order components. Can't have those in an imperative
architecture.

\- v-for is not sane to me. Also odd, being forced to mix-in extensions for
the simplest basics that go beyond the few presets Vue provieds:
[https://github.com/Krizzu/vue-for-range](https://github.com/Krizzu/vue-for-
range) A React user doesn't solve problems by searching the internet for
framework specific solutions, they import _ from 'lodash' and use _.range,
like everyone else does.

\- {condition && <div>hello javascript</div>}

\- We have suffered through two-way data bindings with Angular already

\- Vuex is not native. It mutates state by aggressively transforming state
into setter/getters, with nasty edge-cases. Once Vue switches to version 3
using proxies, you'll maintain two incompatible codebases. React has Mobx,
even though Redux is great. Also lots of lean and promising alternatives like
Unistore.

\- Knowing React you don't rely on documentation (though official docs are on
point). It is simple enough to grasp it after looking at a view examples once.
The api surface and cognitive overhead of React is a tiny fraction of Vues.
Coming from Angular it is amazing that one month of learning and half a year
of consulting docs turned into a week and a couple of months consulting with
Vue. Yet, you can learn React fully in the shortest amount of time while
simply remembering the few things you'd need to know. A generic round-trip,
for instance the one at egghead, costs you 60 minutes total.

\- [http://www.npmtrends.com/angular-vs-react-vs-vue-
vs-@angular...](http://www.npmtrends.com/angular-vs-react-vs-vue-
vs-@angular/core)

~~~
hungerstrike
These are exactly the same reasons that I think React is the best. Vue looks
like it's going backwards compared to React. Furthermore, you get native
mobile apps for free with React Native. Also, React has a much, much bigger
community and bigger companies supporting it.

~~~
mlsarecmg
Not just mobile apps:

Windows: [https://github.com/Microsoft/react-native-
windows](https://github.com/Microsoft/react-native-windows)

Macos: [https://github.com/ptmt/react-native-
macos](https://github.com/ptmt/react-native-macos)

Linux (Qt): [https://github.com/status-im/react-native-
desktop](https://github.com/status-im/react-native-desktop)

AR: [https://github.com/HippoAR/react-native-
arkit](https://github.com/HippoAR/react-native-arkit)

VR: [https://facebook.github.io/react-vr/](https://facebook.github.io/react-
vr/)

TV: [https://github.com/react-tv/react-tv](https://github.com/react-tv/react-
tv)

Shell consoles: [https://github.com/Yomguithereal/react-
blessed](https://github.com/Yomguithereal/react-blessed)

Word: [https://github.com/nitin42/redocx](https://github.com/nitin42/redocx)

Pdf: [https://github.com/diegomura/react-
pdf](https://github.com/diegomura/react-pdf)

3d: [https://github.com/Izzimach/react-
three](https://github.com/Izzimach/react-three)

Sketchapp: [http://airbnb.io/react-sketchapp/](http://airbnb.io/react-
sketchapp/)

Keynote:
[https://twitter.com/nishb1/status/913744410537537536](https://twitter.com/nishb1/status/913744410537537536)

Hardware: [https://github.com/iamdustan/react-
hardware](https://github.com/iamdustan/react-hardware)

Samplers:
[https://twitter.com/GabeRicard/status/911989894267973633](https://twitter.com/GabeRicard/status/911989894267973633)

And so on ...

Finally being able to transfer knowledge and code, and due to the generic
nature of React in some cases even everyday eco-system packages can be
applied. For instance: [https://github.com/gaearon/react-blessed-hot-
motion](https://github.com/gaearon/react-blessed-hot-motion) (native console
app using plain react-motion to move stuff around).

~~~
buoyantair
wew dude o.o

------
ebbv
One non-trivial thing my team has experienced using Angular over the past
year; the decision to abandon version numbers makes searching for answers or
documentation a nightmare. Ironically the company that should understand
search the best hobbled the ability for developers to search for answers.

TypeScript is nice. Actually writing code in angular is a fine experience.
It’s all the stuff around that which isn’t great. We recently upgraded our app
from Angular 4 to 5 without much fuss and that was nice. But the team should
really go back to using version numbers. They exist for good reason.

------
JohnMunsch
"Polymer is a Google-backed libary focused on Web Components, a proposed group
of technologies that are currently not well-supported in browsers."

Ha ha ha ha ha ha ha. Wow.

~~~
Fifer82
I gave up on Polymer. I can't really explain it well but nothing worked as you
expected it to. v2 was just hacked v1 (hybrid?) and so trying to actually
figure out how to use v2 was impossible since every major custom element was
hybrid. The documentation was bad, and the things you might want to use were
somewhat depreciated, but you had to figure that out on your own. Then the
standard glacial pace of development means that v3 was announced over half a
year ago and as far as I can see, nothing has happened.

------
madmaniak
It's lacking the best - Imba. The rest are just funny toys. Sad it's lacking
documentation. Hope it will change soon because it kills with performance and
developer experience.

~~~
burlesona
Hmm, “lacking documentation” and “great developer experience” seem mutually
exclusive to me.

~~~
madmaniak
Some people read documentation, some tests (lol) to know what's going on. I
read code - and Imba has really nice code to read. Also they are responsive on
Gitter. But as I said. It's a pity.

------
mstijak
Author of CxJS here, which is also missing from the list. Please consider CxJS
if you're looking for an enterprise-grade framework with ready to use form
elements, form validation, advanced grid (data-table) control, navigational
elements, tooltips, overlays, charts, routing, context-sensitive layouts,
theming, drag & drop, culture dependent formatting and more.

[https://cxjs.io](https://cxjs.io)

[https://github.com/codaxy/cxjs](https://github.com/codaxy/cxjs)

