I looked deep into react, angular, riotjs, and my conclusion: js is a virus

[andrewfromx]

As great as virtual DOM is, and amazing component based UI design where components just know how to render themselves, I think the problem is javascript. Why would I want to move logic away from languages like ruby, or golang, and into javascript? I can still have components that know how to render themselves I just have more full page refreshes when a form or link is actually submitted to rails non-ajax style. But this is OK. When I need some Ajax I use jquery and do it but my overall feeling is keep javascript to a minimum. Some stuff HAS to be js, like making the textfield get focus in the first name field on a form. So I write a little js for just that and only that. But otherwise no important logic should ever go in js. Am I rite? Here is example app I started with intent to finally learn react or angular and I love where it ended up: https://www.youtube.com/watch?v=_cuhYh68vHM Notice the "add kid" button or "add co-parent" buttons just show hidden form already on page. It has that quick feel of not doing page refresh when not needed. But I don't do 100% Ajax.

[sfeng]

As a general rule things are moving into the browser because that is the point closest to the user where the most interactivity is possible. It's simply not possible to provide the desktop-like experience of a modern web app when you have to reload the page to make any change. I would actually ask the opposite question, what is the purpose of keeping your rendering far away from the user when it could just as easily be done by the high-performance engine built into their browser?

[Piskvorrr]

Yes, that is great and wonderful, allowing for things that are Indistinguishable From Magic (tm). There's a catch, though: "high-performance engine" is usually power- and memory-hungry. This means client-side bloat, which translates to: "Underpowered computer, or worse, a phone? Go away!" (Literally. Webview-wrapped apps that do nothing beyond a few REST operations bloat to hundreds of MBs, because RAM Is Cheap And It's Not Our RAM Anyway Amirite.)

So, although the client-side non-thin non-native apps (a.k.a. in-browser JS fat clients) are easy to write, nice and responsive, I'm sorely missing a way to do some of their heavy lifting server-side.

[cmoscoso]

Why do you want desktop-like experience on a browser?

[jmcdiesel]

Why not? You make the claim that nothing important should be done in JS, but why not? You established your opinion, then gave the evidence to support it, rather than the other way around. I'm curious to the actual reason you find that JS should be avoided, and what, specifically, the other languages give to the solution that JS is lacking in.

[true_religion]

This isn't science, this is the proof standard of detective work or politics. Rhetoric first then proof to convince the audience.

[kurtfunai]

If that's working for you - fantastic. It seems like the way that you're looking to build products is focused on development ease & minimizing JS usage. We also build products that way at my company, and it allows us to build & iterate quickly with few developers.

If you'd like to implement some modern front-end technologies that lend themselves to this style, you could look to Vue.js (https://vuejs.org/) paired with a technology like Turbolinks or Turbograft (which allows for partial page refreshment).

It allows you to build something that feels more dynamic but still is based in Rails/ERB templates.

[midgetjones]

If that's all you ever need to do, then sure. Not everyone has that choice, though.

I've needed to build rich, complex UIs under a deadline, and React has made that way easier and more maintainable than if I'd done it the old way.

[lj3]

> and more maintainable

React hasn't been around long enough to make that claim. Angular 1.X has and, imho, it's no more maintainable than your typical jquery program. I suspect we'll find the same thing is true with react in another 3-5 years.

[pipework]

What about offline-capable applications? If you're not sending a client that can work independent of network connectivity, I'd venture a guess that you'd use some JS or a compile-to-js language.

Have you looked into not-JS languages that eventually produce browser-runnable code?

[Piskvorrr]

Not even wrong. (In other words: "[strong opinion], am I right?" All you could get from that is dis/agreement, but I see nothing that could be assigned a truth value.)

[MrBra]

Truth values are currently accepted paradigms.

OP is questioning their soundness with not just an opinion but with an argued view.

Therefore, OP could get back other argued instances of agreement and disagreement, stimulating a constructive debate, which in turn could end up modifying paradigms and reassigning truth values.

And yeah, they could even get reassigned to OP's view.

[renke1]

Just use a compile-to-JS language if you don't like JS.

Traditional web sites don't necessarily need JS (although it often makes them better), but web application most certainly need JS.

[nickthemagicman]

JavaScript is pretty terrible but there's no escape.

Even Brendan Eich apologizes for it.

Hopefully web assembly gives us options in the browser.

[carsongross]

Calling javascript a virus is hyperbole, of course, but it is quite obvious that a lot of people find javascript subjectively objectionable, and there are plenty of objective problems with the language. Unfortunately reasonable objections are usually shouted down online by javascript fans.

Mandatory mention: intercooler.js lets you add ajax to you app w/ very little javascript.

I really didn't like javascript and thought that AJAX should work like regular old web requests and, in the process, rediscovered REST/HATEOAS. I really like it. You can use whatever language you'd like on your backend, all the communication is in HTML, as Berners-Lee intended.

https://github.com/LeadDyno/intercooler-js

[dplgk]

> like making the textfield get focus in the first name field on a form.

React et al is not for this kind of work. If you're doing things that add niceties to interactions or some basic form validation, then you do not need a framework like Angular. Use jQuery or similar. But if you need to, for example, write a very UI heavy and data intensive app, then you'll probably want to use an existing framework like React. Or you could spend 6 months or 3 years writing your own framework before getting any actual work done.

[badthingfactory]

For certain kinds of applications, I agree. If you're building a business application which requires forms, validation, searching, and some reports; server rendered apps enhanced by sprinkles of jquery is probably a better solution than js-heavy single page apps.

If you're building a more interactive app, for example, let's say Trello; Server rendered views enhanced by jquery is never going to work.

[usgroup]

I'm going to give Elm a go. I'm keen on declarative UIs , so hoping Elm delivers. Would love to know about the experience of others with Elm.

[midgetjones]

I think a lot about Elm is wonderful, but I really miss a JSX equivalent.

[viach]

You missed Vue.js, it worth a try.

[GolDDranks]

Web assembly will hopefully ease up the situation. I'm already calling some libraries from JS that are compiled from C. At the moment it's things like encoding recorded audio stuff as Opus in the browser. But it will be more.

TypeScript also helps. I've been using it for just a few months, but it has already saved my ass many times.