Ask HN: Is there a sane alternative to Angular and React? | Hacker News Reader

Ask HN: Is there a sane alternative to Angular and React?

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

Are these transitory technologies that will be replaced by something better in the near future? Is there a better alternative available today?

View on HN

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.

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.

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.

> No, none of this platform is sane. It's not designed, it's evolved. Embrace the madness or fail.

Username checks out. Thanks, ZenPsycho!

so from the other comments I understand that flash was better designed for the web.

your sentence makes no sense. You design for a specific outcome for a specific audience. "the web" is not w goal or audience

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/ https://vuejs.org/ https://mithril.js.org/ https://choo.io/ 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.

Excellent question. Turns out there is: 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

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

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.

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.

NoRedInk use it in production and are quite big advocates (having hired the BDFL) - http://tech.noredink.com/

Obligatory counterpoint: http://reasonablypolymorphic.com/blog/elm-is-wrong

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 which kinda does the same in more traditional approach.

It also works well in non npm/node.js environments.

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.

> 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

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

And Vue can use JSX.

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

Hear hear. I used Angular for about a year and tried to use React for about six months. Then I tried Vue and I couldn't not believe just how much more sense everything made. Give it a shot.

Came here to mention this one. Vue is nice and clear in all the ways React and Angular (both flavors) are not.

It's just simple and enforces "good" practices by making sense of them.

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.

I think this could be simplified a little, and still remain true:

> 'Boring' language OOP/MVC for the back end is beautiful, clean, simple, and then you can use a bit of jQuery on the front

This bit should be considered golden advice IMO:

> Don't reinvent a browser in the browser or waste more time on JS than you need to,

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.

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?

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.

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.

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), 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 - 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 - it's the same sample todo app built in a buttload of frameworks so you can compare which one you like.

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

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

If you haven't yet you must look into Vuejs as well - https://vuejs.org/

and Quasar too - http://quasar-framework.org/

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

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.

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.

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.

https://vuejs.org/ is my favorite alternative

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.

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.

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

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.

'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.

Out of curiosity, what is your niche?

Server-side JS has existed as long as JS itself. Netscape had something called LiveWire as part of their Enterprise Server in 1995.

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

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

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

Not really.

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

https://facebook.github.io/reason/

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

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=8LCmLQ1-YqQ (really bad audio, sorry)

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

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

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

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

http://intercoolerjs.org

I'm a big fan of Intercooler.

Svelte is pretty elegant: https://svelte.technology/

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.

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?

MDN is great: 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.

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://mithril.js.org/

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

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.

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

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.

Hehe, thanks for the compliment!! :)

Try AngularDart with NodeJs

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.

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.

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.

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

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) 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, something like mailchimp but faster and with less clutter.

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

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.

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

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.

vue.js ... absolutely amazing.

For java developers http://www.totalcross.com is an option.

Try Elm as an alternative: http://elm-lang.org/

Definitely worse than Silverlight!

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

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... ) 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/, and I'd encourage you to use the official Create-React-App tool ( 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... ) 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 . 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-... , 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 .

Elm

Reply on news.ycombinator.com