7 ms·

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

31 points by andrewfromx 10y ago

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.

Piskvorrr 10y ago
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 10y ago
  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.
jmcdiesel 10y ago
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 10y ago
  This isn't science, this is the proof standard of detective work or politics. Rhetoric first then proof to convince the audience.
renke1 10y ago
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.
midgetjones 10y ago
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 10y ago
  > 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 10y ago
    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 10y ago
      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 10y ago
        I think people just implicitly mean React+Redux in these cases.
      - RussianCow 10y ago
        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.
deleted 10y ago
[deleted]
pipework 10y ago
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?
sfeng 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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).
      - 10y ago
kurtfunai 10y ago
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.
nickthemagicman 10y ago
JavaScript is pretty terrible but there's no escape. Even Brendan Eich apologizes for it. Hopefully web assembly gives us options in the browser.
viach 10y ago
You missed Vue.js, it worth a try.
GolDDranks 10y ago
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.
badthingfactory 10y ago
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 10y ago
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 10y ago
  I think a lot about Elm is wonderful, but I really miss a JSX equivalent.
carsongross 10y ago
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 10y ago
> 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.

31 points by andrewfromx 10y ago

Piskvorrr 10y ago

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 10y ago
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.

jmcdiesel 10y ago

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 10y ago
This isn't science, this is the proof standard of detective work or politics. Rhetoric first then proof to convince the audience.

renke1 10y ago

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.

midgetjones 10y ago

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 10y ago
> 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 10y ago
  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 10y ago
    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 10y ago
      I think people just implicitly mean React+Redux in these cases.
    - RussianCow 10y ago
      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.

deleted 10y ago

[deleted]

pipework 10y ago

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?

sfeng 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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).
    - 10y ago

kurtfunai 10y ago

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.

nickthemagicman 10y ago

JavaScript is pretty terrible but there's no escape. Even Brendan Eich apologizes for it. Hopefully web assembly gives us options in the browser.

viach 10y ago

You missed Vue.js, it worth a try.

GolDDranks 10y ago

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.

badthingfactory 10y ago

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 10y ago

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 10y ago
I think a lot about Elm is wonderful, but I really miss a JSX equivalent.

carsongross 10y ago

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 10y ago

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