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

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?

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.

Power and memory hungry web apps are usually the result of sloppy coding or a lazy architecture. Web apps should solely be responsible of rendering a view based on state and allowing for interaction with the state through the view. Any heavy lifting can (and should?) still be done by a backend.

In my experience, there's a significant overhead even before anyone can apply their sloppy coding skills - and scaling, oh boy the scaling (super-linear, more likely exponential). "Clientside filter works great for 10 items, and sort of okay for 100 items, ship it!" (And becomes unusably slow at 1000 items).

That is true, though I think it is becoming a problem of the past. What you're saying originates from the jQuery days, when suddenly a magic band-aid appeared that could seemingly fix previously difficult to achieve features in a nutshell (ofcourse, at the expense of performance). Libraries like Vue and React make it easy to create high-quality maintainable code.

I do remember jQuery 1.0. And I do remember what was before it. That time is now called Browser Dark Ages - for good reasons.

Your description of "magic band-aid at expense of performance" is IMNSHO unfair - before it became a huge golden hammer (and long before small replacements like Zepto), jQuery brought usable, cross-browser scripting, with features that the browsers themselves did not have (We're talking IE6 here, remember?). This allowed robust coding, and it was actually more optimized for common operations than a naïve "pure" JS implementation.

This is indeed becoming a problem of the past, precisely because browsers started to implement those features natively - but the choice of features was often driven by "oh, and jQuery does this, it would be nice if we didn't need a library for it".

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

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.

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

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.

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.

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

I don't think that's true. Angular isn't very maintainable because its architecture encourages you to write spaghetti code with implicit dependencies. React, on the other hand, encourages a much more explicit data flow, so I would guess that React apps, all else being equal, are much more maintainable than Angular apps.

(Standard disclaimer about how you can write maintainable code in any framework and this isn't necessarily a rule.)

To be fair, you should compare React+<state management library/framework> with Angular because a lot of complexity in the frontend comes from dealing with state. Sure, you can just use setState and go with React only, but not many people do that (for a reason).

I think people just implicitly mean React+Redux in these cases.

That's true, but even only using setState and props, the data flow in React is much more explicit than that of Angular. My point was that React encourages more maintainable code by default, even without other libraries.

angular, in my opinion, is pretty horrible from the get-go. It seems to want to proxy logical routes via the DOM rather than have the DOM be the result of the logic.

Four years isn't enough? I'll be honest, I'm not sure what longevity has to do with maintainability.

I'm sure it's totally possible to write unmaintainable rubbish in React, just as it is in any language/framework/library, but I found it much easier to write idiomatic, maintainable code than the wild west of jQuery.

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?

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

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.

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.

JavaScript is pretty terrible but there's no escape.

Even Brendan Eich apologizes for it.

Hopefully web assembly gives us options in the browser.

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

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

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.

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.

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

You missed Vue.js, it worth a try.

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.