
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:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=_cuhYh68vHM Notice the &quot;add kid&quot; button or &quot;add co-parent&quot; buttons just show hidden form already on page. It has that quick feel of not doing page refresh when not needed. But I don&#x27;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.

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

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

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

~~~
Piskvorrr
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".

------
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/](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.

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

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

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

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

