
Ask HN: Is there a sane alternative to Angular and React? - martijn_himself
Slightly tongue-in-cheek but nonetheless serious question. I&#x27;ve recently started looking into JavaScript UI frameworks and have the uneasy feeling they are actually worse than the now defunct Flash and Silverlight.<p>Angular and React seem to be a mish-mash of proprietary syntax and technologies (AtScript, JSX, TypeScript etc.) that paper over some of the cracks in JavaScript and CSS.<p>Are these transitory technologies that will be replaced by something better in the near future? Is there a better alternative available today?
======
ZenPsycho
No, none of this platform is sane. It's not designed, it's evolved. Embrace
the madness or fail.

The web is not desktop applications. The network is always there, the network
is slow, the network is asynchronous. The network can fail. You cannot
abstract over this with a clever library. Unless you don't care about pushing
out 4mb of javascript before first render, you can't ignore it.

The front-end is not a server based application. It's relatively
straightforward to just echo out some html from a server. This works pretty
well, and conceptually it's easy. But the UI has events. Events are
asynchronous. You cannot abstract over this. It cannot be ignored. Unless all
you need is the off the shelf components and no custom interactions,
animations or logic.

Every UI framework for the front end is aimed at solving a _specific_ problem,
a _specific_ complexity. Before adopting ANY of them, you have to seriously
ask yourself if you actually have that problem before just jumping on the
bandwagon- in most cases, in my experience, you probably don't. But by
adopting some "framework" you've just added a problem. you've added a
complexity. If you had the problem, it might be worth it. You might have
netted less complexity.

But probably not.

Browsers have come a long way in 10 years, if you haven't been paying
attention. _Most_ of the cross browser problems have disappeared unless you're
using new things like web sockets, web rtc or indexedDB, or something crazy
like that. The browser is already a UI framework with all the basic widgets,
text layout, image manipulation, audio processing, etc. etc.

From a perspective of a _user of your website or service_ , ask yourself what
value something like react is really adding.

~~~
martijn_himself
This is one the most insightful responses, so much of this rings true to me.

 _It 's relatively straightforward to just echo out some html from a server.
This works pretty well, and conceptually it's easy._

I remember reading an article recently (I can't find it) that argued that the
human readable part of the web should have been just this, a place for static
pages to render and be read. The reason it works so well is because that was
what it was designed and build for. So it has basically just completely
escalated by its attempt to replace native applications. Except it is and
always will be worse at everything a native application does.

 _You have to seriously ask yourself if you actually have that problem before
just jumping on the bandwagon._

I suppose that is sort of complicated by the fact that every framework out
there tries to sell itself as the best thing since sliced bread, except
advertising what is _for_.

 _Browsers have come a long way in 10 years, if you haven 't been paying
attention._

It is absolutely amazing what has been achieved.

~~~
ZenPsycho
To clarify, when I said "the web is not desktop applications", I meant that
you cannot program a "web app" as if it's a desktop application. The
assumptions are all different. The entire execution model, and the way modules
are included is different. You can achieve things very much like a desktop
application, as far as a user is concerned. But: The network will slap you if
you ever decide it's something the compiler is taking care of for you.

------
awjr
I cannot fault the communities around React and Angular and the support that
they give to each ecosystem. I would say that the React community seems to be
'stronger' these days.

I note some people are mentioning other JavasScript frameworks (e.g.
[http://aurelia.io/](http://aurelia.io/)
[https://vuejs.org/](https://vuejs.org/)
[https://mithril.js.org/](https://mithril.js.org/)
[https://choo.io/](https://choo.io/)
[https://svelte.technology/](https://svelte.technology/) ) They ALL have their
merits, but it all comes down to the development community around them, and
for me, the jobs out there.

Recently somebody asked in our local JS group what framework to learn and
everyone responded with React. The jobs are there, the dev community is
strong, and more importantly the learning curve is good, particularly with the
hand holding create-react-app now does. Yes, down the line, you will have to
learn react-router and maybe redux/mobx, but all in good time.

------
elviejo
Excellent question. Turns out there is: [http://elm-lang.org](http://elm-
lang.org)

Is a Haskell inspired programming language that makes developing front end a
delight.

It helps to build Reliable front ends. Watch this conference to get a sense of
what Elm does. Making the Backend Team Jelous[1]

Plus the Elm architecture makes everything orderly and easy to understand.

Quite a change from the mess of react components and Angular rewrites.

[1] [https://youtu.be/FV0DXNB94NE](https://youtu.be/FV0DXNB94NE)

~~~
martijn_himself
This looks great, and thanks for providing the links. Is Elm production ready?
Have you used it to build any apps?

~~~
lisardo
I talk about my experience. I deployed Elm to production in several projects
for the biggest group fitness company in the US.

It's incredible. Compiler errors are incredible. No undefined bullshit. It's
purely functional, so the code you need to understand at the same time is
always gonna be inside 20 lines. And you can use it with javascript if you
want too.

You will learn a lot using a pure functional programming language. Programming
is about transforming data, so even if I go back to any OO language I learned
that state can cause several problems.

~~~
martijn_himself
That sounds great. Did you have to convince anyone to adopt Elm or were you
free to pick your language of choice? Using a pure functional language appeals
to me as well.

------
dz0ny
Vue.js is saner because it does not have that JSX nonsense and you can still
write most of the code however you like, and later upgrade to babel,typescript
etc. Particularly I like component structure
[https://vuejs.org/v2/guide/single-file-
components.html](https://vuejs.org/v2/guide/single-file-components.html) which
kinda does the same in more traditional approach.

~~~
heidar
The main reason I didn't consider Vue was because I like coupling HTML and JS
like React does. But this seems like a much nicer way of doing it than JSX.
I'll have to give Vue another chance.

~~~
masklinn
> But this seems like a much nicer way of doing it than JSX.

Note that there is no requirement to use JSX, JSX is just syntactic sugar for
the underlying function calls which you can use directly:
[https://facebook.github.io/react/docs/react-without-
jsx.html](https://facebook.github.io/react/docs/react-without-jsx.html)

That's useful when you don't want to add a local compilation file when
developing/debugging.

~~~
dlwdlw
This argument doesn't make sense because doing it like that is even worse that
JSX.

------
CosmicShadow
ASP.NET MVC for the back end is beautiful, clean, simple, and then you can use
a bit of jQuery on the front or use Knockout JS if you want to do data-binding
with MVVM and not have to learn with or deal with all the other crap of those
frameworks mentioned as that is what MVC already does for you.

Don't reinvent a browser in the browser or waste more time on JS than you need
to, you'll feel so clean separating things.

~~~
n0rm_
Please don't.

I already have a really hard time communicating reason to m$ people. They get
these ridiculous ideas from the likes of you, and waste countless hours
beating a dead horse.

There will be no servers to configure in the future. We will be spinning up
containers in a swarm, and communicating with those services via de-
centralized lambda function pools. Bulk of future devs will spring up in
frontend. m$ lost its monopoly in backend to AWS and the likes. Do you think
they started OSS because they are nice? They are desperate and throwing money
at the problem.

> jQuery on the front or use Knockout JS if you want to do data-binding with
> MVVM

I'll say the same thing to someone who tried to make a case for PHP; you are
doing a disservice to the clueless reader (likely a new grad). Kids, listen to
me; don't ever say that in a job interview. You'll be politely rejected, and
never hear from them again.

If you __started __to use jQuery after 2016, just keep that to yourself. It
shouldn 't matter that much, but it does. It signals you are comfortable with
being mediocre.

> waste more time on JS than you need to

Again; just don't. Just because your past 10 years of acting "1337 programmer"
through drag-n-drop some VC (nuget?) modules vanished doesn't mean future
programmers need to go through that soul crushing m$ travesty.

What is the UNIX philosophy? What is m$ (still) trying to do? Do you think
those guys don't know how to pick successful ventures? Think. You are up
against a company here, not a friendly group of developers.

Not that you can really resist the change, mind you. I'm not asking you to
stop peddling your inferior wares because I'm afraid you might stop progress.
I'm _suggesting it_ because you will be left holding the bag when m$ finally
starts chopping bits off the MSDN network, and Oracle silently discontinues
Java after v9.

Try to advance, not defend your crumbling castle.

p.s. Had to create a new account just to reply to this. Hadn't logged in in a
couple years.

------
taude
Server-side rendering with partial views?

You're never going to get something as simple as Flash, with a write-once
works everywhere. But your user's aren't going to be annoyed at the crappy UX
that Flash (or Flex) applications brought us.

EDIT: I'm dead serious about this, with the concept of isomorphic apps, I'm
not convinced building thick Javascript-based clients is necessarily the way
to go for a lot of use cases, including the traditional business information
worker-type of application. With these modern JS frameworks working on the
concept of rendering virtual DOM diffs, why not just render the partial diff
on the server and swap out the specific DOM on the client page?

~~~
ooqr
The application I've inherited and support is a Rails app that does this. I
hate this pattern. It's very difficult to change things and burdens the
backend developer with the responsibility.

~~~
fanpuns
I'm pretty new to Rails, but I'm implementing something very similar to this.
Is there's any open source mature Rails app that might demonstrate what your
seeing/maintaining? I'd be curious to see how this pattern looks as it grows.

------
fiiv
Both TypeScript and JSX are optional, you don't have to use either with them.

There is a ton of different choices out there to choose from if React and
Angular are not your thing.

One example: Ember.js recently moved their rendering into a standalone library
called Glimmer ([https://glimmerjs.com](https://glimmerjs.com)), which is a
bit React-like in its approach but nonetheless different. They advocate
Typescript as well but don't require it.

Elm seems like a thing people like as well, check it out here: [http://elm-
lang.org](http://elm-lang.org) \- but it's a js compiler so it's also what you
might classify as a "proprietary" tech.

If you haven't already, check out [http://todomvc.com](http://todomvc.com) \-
it's the same sample todo app built in a buttload of frameworks so you can
compare which one you like.

~~~
martijn_himself
It is interesting you are the second person replying in this thread to point
to Elm. I must check it out!

I suppose both TypeScript and JSX are optional but they are symptomatic in a
way in that their existence suggests the alternatives are sub-optimal (i.e. a
combination plain JavaScript or a clear demarcation of markup and styling).

~~~
ooqr
Elm is neat but definitely goes against the very properties you're looking
for. But if you want to take a peek down that road:
[http://mutanatum.com/posts/2017-01-12-Browser-FP-Head-to-
Hea...](http://mutanatum.com/posts/2017-01-12-Browser-FP-Head-to-Head.html)

------
subsidd
If you haven't yet you must look into Vuejs as well -
[https://vuejs.org/](https://vuejs.org/)

~~~
idkfa
and Quasar too - [http://quasar-framework.org/](http://quasar-framework.org/)

------
coldtea
> _Slightly tongue-in-cheek but nonetheless serious question. I 've recently
> started looking into JavaScript UI frameworks and have the uneasy feeling
> they are actually worse than the now defunct Flash and Silverlight._

Angular, at least up to 2.0 which I've checked, it's a conceptual mess.

React, on the other hand, is conceptually better than Flash and Silveright,
and even has more powerful abstractions in several areas.

The problem is that React handles a small part of the logic that Flash and
Silverlight do (or, something like Flex would), and does so at various levels
of the whole stack (some low level like diff-ing repaints, others at higher
level like component nesting), and all the wiring and extra handling is left
to the programmer to handle.

For all the progress with React and co, it's still the wild west as far as
programming efficiency is concerned. Elm is not much better either.

------
Marazan
React is, in many ways, a take on Flex's excellent MXML updated for a JS world
that understands that 2-way data binding is the devil.

It is very sane.

~~~
taude
I agree, I feel React, much like Flex's MXML forces the developers to
componetize the entire UI as part of the development process in a way that
feels natural.

------
borplk
As someone else said the platform itself is not sane.

However on the scale of things that we have, React is pretty sane.

I have never seen someone who spent significant time with React and thought it
wasn't sane.

There are some people who are stuck with some 2005 MVC jQuery PHP AJAX mindset
repeating worn-out lines like "don't mix logic with views". All their alarms
go off when they see JSX.

I don't for a moment think any of this crap that we have is "elegant".

I hate TypeScript/Javascript/React/Redux/Webpack/JSX/Yarn/NPM/Node etc... and
I also love them and use them.

Those things that I listed in 2017 enable a class of web applications to be
created that is simply not practical to build with send-html-from-the-server-
and-sprinkle-jquery-event-handlers-on-the-client technologies.

At this point it's Javascript vs everything else.

I used to build applications with PHP/Laravel/Django/Flask/Sinatra etc... now
I don't consider them anymore for web applications (still ok for content
sites, not complex applications).

The smooth robust magical UI/UX that I can achieve with TypeScript/React is
miles ahead of all other options, it's still full of crap, but still miles
ahead of other options.

Again I re-iterate my main point, which is things have now changed in such a
way that the competition has become Javascript/TypeScript vs everyone else.

If you are going to build HTML in a string on the server and sprinkle some
javascript on top it doesn't make that much difference whether you use PHP or
Python.

------
roro5678
[https://vuejs.org/](https://vuejs.org/) is my favorite alternative

------
seangrogg
React does not require JSX; it is just a sugar over React.createElement. By
way of example:

<h1 className="title">Hello World</h1>

React.createElement('h1', { className: 'title' }, 'Hello World');

A very contrived example but it's pretty simple to see that if you're coming
from a background where you previously used a lot of "JavaScript in HTML" and
aren't used to "Markup in JavaScript" it makes for a good middle ground. As
well, as you can likely infer from the example, when you start dealing with
various nested children the pure JavaScript solution can get somewhat
unwieldy; though that comes down to taste, mostly.

While I empathize with your position (I'm not a big fan of the transpilation
trend) I do find React to be much more sane than Angular 1.x was and much more
relevant to what I build than jQuery.

------
levosmetalo
Since I discovered Clojurescript using reagent, re-frame and figwheel it is
hard to go back to any JS framework, or JS itself. The feedback cycle is so
short that it feels like doing Smalltalk properly.

Now I wish I could use similar combo for mobile and desktop development.

~~~
bschwindHN
> Now I wish I could use similar combo for mobile and desktop development.

Check out "re-natal". That at least gets you mobile, and perhaps desktop once
react native has a good desktop story.

------
Clownshoesms
This whole JavaScript "revolution" seems surreal to me. I still can't believe
they snuck JavaScript onto the backend.

Edit: Angry is a better word.

~~~
nebabyte
'Angry' will be me once they start publishing metrics on how optimized JS (or
what, webASM or something?) beats out native.

Oh, I'm sure it's being done already. At this point I'm just back in my
comfort zone. Let them battle it out for a few more years, I can probably make
my peace with whatever's left over or stay in my niche.

~~~
martijn_himself
Out of curiosity, what is your niche?

------
carsongross
If you wish to stay with the thick client model, Vue.js appears to be the
simplest alternative.

If you are willing to consider returning to the original RESTful architecture
of the web, intercooler.js will dramatically simplify your application:

[https://github.com/LeadDyno/intercooler-
js](https://github.com/LeadDyno/intercooler-js)

------
cies
Let me take your question apart a little...

> Angular and React seem to be a mish-mash of proprietary syntax and
> technologies (AtScript, JSX, TypeScript etc.) that paper over some of the
> cracks in JavaScript and CSS.

They are not "proprietary", but such they are partly an attempt to overcome
"some of the cracks in JavaScript and CSS".

> Are these transitory technologies that will be replaced by something better
> in the near future?

I do not think so.

> Is there a better alternative available today?

As you mentioned JS (and to a lesser extend CSS) is the problem. A problem
that Angular and React do not fix. People in this thread will mention Vue and
Svelte as alternatives to Angular and React, but these also do not fix the
underlying problem: JS.

TypeScript and Flow fix some of JS's problems. But a real next level approach
that is available today is given by real compile-to-JS languages: Elm,
PureScript and ReasonML.

It deserves to be mentioned these are all primarily "functional" languages.
And not for no reason, FP is kind of the best option we have to avoid the
OO/imperative-dramas we become tired of.

And Reason is particularly interesting as it can also compile to native
(PureScript as well but not very mature in that regard), it is backed by
Facebook (25% of messenger.com is ported to ReasonML already) and thus has
well supported React bindings (allowing interop with the React ecosystem).

~~~
a-saleh
I have been playing around with PureScript (more for the fun of learning
interesting FP concepts than creating anything useful) and really liked the
Purescript Book [0]. Is there something similiar for Reason as well?

[0] [https://leanpub.com/purescript/read](https://leanpub.com/purescript/read)

~~~
cies
Not really.

This you've probably seen (the home page):

[https://facebook.github.io/reason/](https://facebook.github.io/reason/)

This is also quite nice (see the example app section at the bottom):

[https://github.com/vramana/awesome-
reasonml](https://github.com/vramana/awesome-reasonml)

Also these talks are interesting (but nothing close to the format of the book
you mentioned):

[https://www.youtube.com/watch?v=_0T5OSSzxms](https://www.youtube.com/watch?v=_0T5OSSzxms)

[https://www.youtube.com/watch?v=8LCmLQ1-YqQ](https://www.youtube.com/watch?v=8LCmLQ1-YqQ)
(really bad audio, sorry)

------
rlp
I think React is actually quite sane to use now. However, if you're looking
for the future, you may want to check out Web Components and Polymer:
[https://www.polymer-project.org](https://www.polymer-project.org)

~~~
coldtea
Correction: if you're looking for what was once touted as the future, but
never came to be and probably never will, and has been surpassed by React
(and/or Angular), check Web Components and Polymer.

It's a committee driven over-engineered spec that's not going to be any more
succesful than XHTML...

~~~
ergo14
Yeah, sure that is the reason lots of big enterprises adopted it for their
front facing products :-)

------
leke
VueJS is kinda got parts of both, but is entry level friendly. I'm probably
not the best to give this advice though.

------
pcardoso
[http://intercoolerjs.org](http://intercoolerjs.org)

I'm a big fan of Intercooler.

------
robinhouston
Svelte is pretty elegant:
[https://svelte.technology/](https://svelte.technology/)

------
daleholborow
[http://aurelia.io/](http://aurelia.io/)

I am a backend guy with some experience in Angular 1.5, Backbone etc, but
currently dabbling in the front end again, and Aurelia looks pretty cool. It
seems like the least "learn our custom syntax and voodoo" option, so I'm going
to give it a spin.

------
nottorp
Speaking of sanity, I've heard that somewhere under these hundreds of layers
of libraries that you're supposed to mindlessly install there is a "native"
javascript API inside the browser.

Is there any comprehensive documentation resource online or offline that
teaches you how to use _that_ in a modern browser?

~~~
mcintyre1994
MDN is great: [https://developer.mozilla.org/en-
US/docs/Web/JavaScript](https://developer.mozilla.org/en-
US/docs/Web/JavaScript)

If you're more of a "show me 30 cool things I can do with none of that
baggage" person, I found javascript30.com really fun.

------
mb720
You can use Scala.js[1] to transpile your Scala code to JavaScript and have
type safety between client and server. You don't need to use any frameworks if
you use Scala's features on the client well.

[1] [https://www.scala-js.org/](https://www.scala-js.org/)

------
skl_
[https://mithril.js.org/](https://mithril.js.org/)

------
obsurveyor
Ractive[1] is pretty good imho. Development runs hot and cold but I've found
it a joy to work with. Documentation could be a bit better, especially when it
comes to components.

[1] [http://ractivejs.org](http://ractivejs.org)

------
citrusx
So, one might ask, "Why do we have these frameworks, anyway?" Well, they're
attempts to _introduce_ sanity to the discordant relationship between HTML/CSS
as a "Read a remotely stored document" system, and the desire to make the web
browser into a fat client for every type of network-distributed application.
Ever since "Web 2.0" was a thing, we've been trying to fit this round peg of
delivering complex apps into the square hole of the web browser. Sometimes, we
do a decent job. But, as we try to handle more total stuff, all of the moving
parts overwhelm us.

With all that in mind, I think that we shouldn't blame "insanity" on the very
tools that have been employed to control insanity. If anything, such a
viewpoint tells us that maybe the attempts of today aren't the full answer, so
there will be more tries tomorrow.

I'll leave you with these things: 1) If the only thing you're doing is
creating a web page that serves as a thin visual layer over REST- or CRUD-
based services, consider going back two generations to Backbone. Seriously. It
does a few simple things for you, and lets you handle the rest in any way that
you see fit. Those simple things may be the only thing that your app does. I
suspect that this would be true for half of Silicon Valley. But, it goes
against the constant pursuit of the new and shiny.

2) If your browser does _more_ than just send a few CRUD commands from the
user to a server, then maybe it's time to look into what's good about these
frameworks, instead of just considering them "insane". Everyone has their own
good parts and pain points to be addressed, and all these tools were built
with the best of intentions, to solve specific classes of tough problems,
which may happen to be yours. Look at the success and failure stories, and see
who's happy with their decisions about their tools, and which problems were
solved with what framework.

3) For those people telling you "just use vanilla JS", I'll leave you this:
Any sufficiently complicated vanilla JS program contains an ad-hoc,
informally-specified, bug-ridden, slow implementation of half of Angular or
React.

------
dotdotcommadot
Being both a TypeScript and Google Dart developer for a few years now (and a
former Flash/Flex developer, and still missing lots of aspects of it), I can
say:

\- On browsers: it is what it is. Neither React nor Angular will fix this for
you. You're going to have to work with all existing browsers and their issues
(which are quite a lot, especially when you want to go little 'deeper down').
\- On styling CSS: Either use a framework like Bootstrap or Material Design
Lite, or try to use a pre-processor like SASS. LESS and Stylus, also 2 pre-
processors, are losing a bit on popularity, or so it seems. SASS is a good
'safe bet'. There's lots of documentation and fairly decent frameworks were
made around it.

\- React and Angular are both really good, have amazing documentation and
tutorials. But for me personally, React translates really well my experience
from Flash/Flex. Angular is also a very nice framework of course, but it feels
to me like it is still more something I would use to make webSITES in, instead
of webAPPS (although I'm building a huge app in it right now), since it is not
as 'fast' and 'snappy' to create components and an architecture as it is with
React. (I'm talking development wise, not performance)

\- On dependencies: I really dislike the entire dependency hell I always end
up in when starting a JavaScript project. Since both JavaScript and TypeScript
use NPM (at least, that's the current de-facto standard), TypeScript does not
solve this for you. For instance: how do you manage your dependencies? NPM,
Nuget or Yarn? What's the difference, and do you have a day to look it all up?
How are you building your project and your .sass files? Gulp, Grunt, Webpack,
NPM scripts, or just vanilla commandline? If you're creating a new class, how
are you going import it in your consumer class? Declare all external JS files
in your index.html? Or maybe you prefer CommonJS, RequireJS, UMD, SystemJS or
ES2015(=ES6) native modules? And what if one dependency uses another system
than you do?

\- On languages:

TYPESCRIPT: it's a very nice and powerful language, but like I said, it hooks
into the standard JavaScript ecosystem. On top of the dependency hell, you'll
have to use a lot of JS interops (to be able to use existing JS libraries),
which aren't always that well maintained.

ES6: You could use the ES6 version of JavaScript. You'll need Babel to
transpile to ES5 JavaScript, so your code will run in all browsers. No
problems with JS interops here, but dependency hell and ecosystem problems
will stay.

GOOGLE DART: Also an amazing language, written by Google. You can discuss on
what's the better language (TypeScript or Dart), but the advantage here is the
ecosystem. You build with Pub, you manage your dependencies with Pub, and
there's only one way of importing external classes. A lot of modern API's
you'll need, like Futures (kind of like Promises), and Streams (like
Observables) are built in the language itself, meaning they are maintained and
tested by Google. I've been using AngularDart (a Dart-based Angular) for over
6 months now, and it's going really well.

So for me, this results in:

\- JavaScript ES6: \+ Simple and fun language \+ Close to old-skool JavaScript
\- Too limited in OOP features \- Inconsistent and way too fast changing
JavaScript ecosystem (dependency management, build tools, importing external
libraries, ..)

\- TypeScript: \+ Very nice language \+ Projects like Angular and React are
written in it, so it's easy to find tutorials in TypeScript \+ Popular, and
well documented \- Inconsistent and way too fast changing JavaScript ecosystem
(dependency management, build tools, importing external libraries, ..) \- Had
a lot of bullshit with JS interops (Both with finding good interops for JS
libraries, as with creating interops myself)

\- Google Dart: \+ Very nice language (very close to Java and C#) \+
AngularDart is fun to work with \+ Very consistent eco-system \+ Really well
documented \+ Good support from Google and community members on Gitter chat \+
The most common API's you'll need are either included in the SDK, or written
and maintained by Google themselves. \- Third-party libraries are not always
that well documented \- The community is not (yet?) as big as the TS or JS
community, so obviously it's a little bit harder to find code examples etc

Conclusion:

\- React is awesome, but being dependent on TypeScript (or ES6), you'll spend
lots and lots of time on managing your dependencies when your project grows
even the slightest bit

\- Google Dart is awesome, but AngularDart, although it's a lovely piece of
software, is still no React.

But for now I choose AngularDart. Perhaps in the future I'll choose for
React+TS again. But I'll continue hoping for a real ReactDart. :)

~~~
martijn_himself
This is a fantastic response, thank you very much. It's a shame I can't up-
vote more than once. I remember watching some Dart videos in the past and
being really impressed by the language so I will revisit it as an option to
pursue along with AngularDart.

~~~
dotdotcommadot
Hehe, thanks for the compliment!! :)

------
ergo14
As few others mentioned here - look into Polymer. I used all three Angular,
React and Polymer - and for me it feels very natural way to build
applications. Companies like MCDonalds, General Electric, IBM, ING, USA Today
(gannet), Electronic Arts, Coca Cola, (and obviously Google) and others
adopted it too.

The 2.x version is quite nice, especially since it uses ES6 by default.

------
buchanaf
I don't really know what you are trying to get at. Almost every front-end
framework is going to have some type of "proprietary syntax" \-- that's
basically what a framework is. Even backend templating languages have custom
syntax that must be learned.

Otherwise, I guess there is jQuery or web components if you are only
supporting modern browsers.

------
joelhooks
React is excellent. I've been building UIs for 20 years and it is by far the
best development experience I've ever had.

Watch out for contrarians and purist wonks. Set aside your preconceptions and
bias against new things you don't understand.

Embrace reality with an open mind.

Fighting it and wishing for an alternate reality is not the path to happiness.
I know that much.

------
loftsy
Dart is a sane language with great tooling. It has its own version of Angular
which works great. It is available today!

------
leftrightupdown
i asked myself the same 2 years ago when my team was deciding if we need all
of that javascript framework madness. In the end we built whole product based
on dartlang ([http://www.dartlang.org](http://www.dartlang.org)) which
compiles down to javascript. We used only Dart language and no frameworks and
best thing that came out of this is that we don't feel bound by restrictions
of some framework but add stuff as we feel like. What we did is email
marketing app [https://www.listshine.com](https://www.listshine.com),
something like mailchimp but faster and with less clutter.

------
kozak
You can also use just the JSX without React (using
[https://www.npmjs.com/package/nativejsx](https://www.npmjs.com/package/nativejsx)
or similar) to combine parts your own way.

------
RUG3Y
I've been dabbling with Riot.js and it looks promising. It's very lightweight
compared to Angular / React and I was able to get going with it in ~30
minutes.

------
Bubb_A
For a more functional/reactive approach, there is CycleJS
([https://cycle.js.org/](https://cycle.js.org/)).

------
bwackwat
All you need is vanilla JavaScript! Seriously. Email me at
john.has.come@gmail.com I will be glad to discuss my approach to completely
avoiding these frameworks.

------
unherd
vue.js ... absolutely amazing.

------
cguedes
For java developers [http://www.totalcross.com](http://www.totalcross.com) is
an option.

------
usgroup
Try Elm as an alternative: [http://elm-lang.org/](http://elm-lang.org/)

------
PaulHoule
Definitely worse than Silverlight!

------
jonmann
Polymer 2.0 is much closer to just writing vanilla HTML, CSS, and JS

------
acemarke
I'll semi-answer your question by giving you my standard set of advice and
resources for learning React.

The article "A Study Plan to Cure Javascript Fatigue" (
[https://medium.freecodecamp.com/a-study-plan-to-cure-
javascr...](https://medium.freecodecamp.com/a-study-plan-to-cure-javascript-
fatigue-8ad3a54f2eb1) ) is a great place to start. It gives an excellent
series of steps for tackling modern Javascript concepts one piece at a time:
Javascript, React, ES6, and state management.

On that note, definitely don't over-complicate the learning process by trying
to learn many different things at once. Some people will say you should use a
"boilerplate" to learn React, and they're wrong - boilerplate projects almost
always come with too many pieces configured, and are confusing for beginners.

Instead, the best advice is to focus on learning React itself first. Once you
have a good understanding of how React works, you will better appreciate why a
state management library like Redux can be useful, and you can learn about
other tools later.

You should start out by reading through the official React docs and tutorial
at [https://facebook.github.io/react/](https://facebook.github.io/react/), and
I'd encourage you to use the official Create-React-App tool (
[https://github.com/facebookincubator/create-react-
app](https://github.com/facebookincubator/create-react-app) ) for setting up
projects. It creates a project with a solid build setup, with no configuration
needed on your part. There's an excellent post called "Simple React
Development in 2017" ( [https://hackernoon.com/simple-react-development-
in-2017-113b...](https://hackernoon.com/simple-react-development-
in-2017-113bd563691f) ) that gives some more specific instructions on the
actual steps to follow.

Past that, I keep a big list of links to high-quality tutorials and articles
on React, Redux, and related topics, at [https://github.com/markerikson/react-
redux-links](https://github.com/markerikson/react-redux-links) . Specifically
intended to be a great starting point for anyone trying to learn the
ecosystem, as well as a solid source of good info on more advanced topics. It
includes links for learning core Javascript (ES5), modern Javascript (ES6+),
React, and much more. I also published an "Intro to React (and Redux)"
presentation at [http://blog.isquaredsoftware.com/2017/02/presentation-
react-...](http://blog.isquaredsoftware.com/2017/02/presentation-react-redux-
intro/) , which is a good overview of the basic concepts for both React and
Redux.

Finally, the Reactiflux chat channels on Discord are a great place to hang
out, ask questions, and learn. The invite link is at
[https://www.reactiflux.com](https://www.reactiflux.com) .

------
kirankn
Elm

