
Rails developers should learn React - revorad
https://medium.com/@hrishio/why-rails-developers-should-learn-react-5cd651eef6db
======
cyberferret
I think I must have some sort of strange default wiring in my brain. I've
developed code for over 30 years using many different languages, but when I
tried to get into Rails about 10 years ago, I just couldn't get my head around
it. Nothing seemed to click and go into place for me.

I ended up using Ruby, but via a Sinatra based framework called Padrino. It
just seemed to make more sense to me.

The same thing more recently with React. I tried dabbling with it about a year
ago, but it just felt like an ill fitting jacket. Couldn't get the hang of it.
Now I've been playing a bit with Vue.js and seem so find that fit better for
my old brain.

Oh, did I mention that I just turned 50. Perhaps it is a young person vs older
person thing, or perhaps my synapses are just too wired in a certain way from
decades of habit? I'd be interested to hear feedback from more _ahem_ mature
developers out there to see if they experience anything similar.

~~~
eternalban
Sounds like your sweet spot is more towards the library end of library/'light
weight framework' vs the 'full blown framework' spectrum.

I don't believe it has anything to do with age.

~~~
true_religion
Except Vue is a framework but React isn't.

~~~
nogridbag
It depends what you mean by "Vue". Vue itself is just the "View" part - the
same as React.

While you can optionally use the official router and state management
libraries, these are completely independent and unnecessary.

------
mhd
If there's one current technology that I wouldn't call _omakase_ , it would be
React. I thought it would get better once redux reached a certain mindshare,
but now there's a plethora of redux helpers, "best" practices etc. (Each of
which seems to focus on a new and/or experimental JavaScript language feature)

Hey, I program Perl in my day job, but this is way too much Tim Toady even for
me.

(And if "more money" were the only reason for technology adoption, there's
probably more to be made in Enterprise Java development, at least on average)

~~~
monkmartinez
Will you explain what you mean a bit more, please? I don't understand your
analogies.

~~~
byroot
Omakase is in reference to [http://david.heinemeierhansson.com/2012/rails-is-
omakase.htm...](http://david.heinemeierhansson.com/2012/rails-is-omakase.html)

~~~
mhd
And Tim Today is how "TMTOWTDI", i.e. "There's More Than One Way To Do It" is
pronounced in certain circles.

------
pmontra
I think this could be right but does one person can really handle both the
backend and the frontend projects when the frontend becomes a first class
project from day 1 instead of a kind of afterthought? In other words: a single
developer can start a Rails+jQuery sugar web site in N days. Where he would be
with Rails(API)+React after those N days?

Another question. I checked those rails+react gems. The pro is that they put
everything inside the Rails project. The cons is exactly the same. Even in the
case the same person is doing both jobs, shouldn't we acknowledge that they
are two separate projects and work on them separately?

~~~
revorad
Re: the gems, you're right. There are multiple approaches. Putting everything
in Rails is the easiest to get started, but you can gradually separate React
from Rails if your app needs it. I wrote about it here -
[https://learnetto.com/blog/3-ways-to-use-react-with-ruby-
on-...](https://learnetto.com/blog/3-ways-to-use-react-with-ruby-on-rails-5)

------
midgetjones
> Learning to use React will make you more money and a better developer.

Nice zeugma!

~~~
ooqr
Thank you for teaching me what this is called. I always found it awkward.

~~~
midgetjones
No problem! And now, I shall take my coat and my leave.

------
cygned
A lot of people say, learning React makes you a better developer. I think,
what they actually mean, is functional programming.

~~~
e12e
Having glanced at react, angular(2), riot.js and vue - and being somewhat
familiar with procedural, message passing, class/inheritance OO, functional
and logic/declarative (SQL/Prolog) paradigms - I can't help but think that
many of the developers that praise react do so because react introduced them
to (a rather convoluted form of) functional programming, leveraging templates
(the php paradigm) as a form of gateway (in the teaching/approachability
sense) approach?

Because so far I just can't see react as the _best_ / _simplest_ approach to
dragging REST[1] apps into the world of GUI COD(Code on Demand)[1] apps. Vue
seems to strike a much more elegant balance, for example.

Especially in terms of life-cycle - I can't say I'd look forward to
maintaining most complicated js stacks for say five years - with a horde of
(rapidly evolving) dependecies, and often a plethora of build tools/steps that
in general all do some rather simple, but incompatible source-to-source
translation (templates to html, some js dialect to another, scss to css).

Vue certainly doesn't fix all of that - but it seems a bit more consistent and
simple IMNHO.

But maybe it's just me. It'd be interesting to hear if anyone's actually made
the jump from "react in anger" to "vue in anger" \- or vice-versa?

[1]
[http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm](http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)

~~~
cygned
React is simple while it's extremely complex at the same time; the library's
concept is actually not that complicated and the API is relatively small. A
lot of developers struggle when it comes to architecting, though. I know many
"enterprise developers" that favor Angular (and Angular 2) because of the
"out-of-the-box" character and the magic that happens under the hood.

Even with years of front-end experience I see these engineers fail at creating
a reliable, documented and structured architecture. I guess, that's because
they don't have time, budget or are no longer used to fiddle around and
explore third-party projects (which is actually sad).

That is, getting started with Angular (or Vue, I expect) is easier and you
will get something together faster. I expect the reason why React is so
popular to be the mix you describe - although "templating" is a bit off,
because JSX isn't templating in the PHP or JSF way.

From my personal point of view I can say, that I never regret the decision to
switch to React (from Angular/Backbone.js). Especially the simple structuring
(basically a component tree) is incredible simple compared to what you had in
Angular 1. I am leading two projects with six digit LOC in the front-end and
it is a pleasure to see how quickly new member can contribute, how clear the
architecture is. Because there's no magic at all.

But that's all very personal, opinions differ greatly and I even know one
developer who loves Angular 2. But he also has to work with Hibernate in the
backend and compared to that everything is great - just kidding ;)

\---

Edit: I have read Fielding's paper for my B. Sc. thesis a couple of times and
it's a great piece work. Should be a mandatory lecture for a lot of fields.

------
yannski
Rails developers, ie web developers having appetite for nice,
industrialization ready technologies, may prefer Ember...

------
mattmanser
Honest question, is it really here to stay? What's different between React
today and Backbone 4 years ago or Angular 2 years ago?

Does it solve all the problems of the predecessors?

People are already starting to talk about Vue like it's the new messiah.

~~~
kls
I believe it is, the problem with both Backbone and Angular is that they treat
UI development like it is still assembling a page and then sending it down to
the client. They encourage monolithic controllers that are not discreetly tied
to the UI. This was a natural outgrowth of web developers being comfortable
with that model in transitioning over from the server side. The problem is, it
sucked on the server side and it sucks on the client side.

In my opinion Vue does not solve the problem that react does as it does not
black box the component and define you inputs and outputs. You can still write
monolithic code-bases with it. It has a stronger component model than Angular
did with directives but that component model can be circumvented. Worse yet
two way binding is the crack of web dev. It gets you hooked on it's "easy" but
as your code-base explodes you loose all trace-ability of when and how stuff
changes and in my opinion, that is where the nastiest bugs surface.

If you actually get into the internals of react, you soon realize it looks a
lot like windows UI programming in the old days. It is a return to principals
that work when composing UI's from components. It's not a new concept, there
have been many frameworks that tried it over the years (Dojo comes to mind)
but react was the first one to hit critical mass and the first one to come
along while most of the other tool-chain was available or fairly easy to
build. The tool-chain makes it complex to get started but once you have a
project going, it is far easier to maintain, and maintenance is where you
really pay for your total cost of ownership.

Now all this comes with the caveats of project size, I personally work on
large scale replacement of traditional application with web based applications
and I think react (and it's tool-chain) is an excellent technology to manage a
large code base that business apps require. However if all you are building is
an informational website with a newsletter sign up form, it's just not the
right technology.

~~~
e12e
It's not quite the (positive) impression _I_ get from react - but then I can't
claim to be familiar with the internals.

I do think one of the reason _I_ struggle with react is because I still
believe the Web is good for REST and Web pages/hypertext - and native is to be
preffered for "applications". Conversely I think react is a pretty poor fit
for "Web".

It still strikes me as crazy complicated compared to say Java SWING driven by
a dynamic language like python (jython).

Might explain why I struggle to embrace it. I mean if you're worse than
Smalltalk or Pascal/Delphi - the stack has to be backwards crap for GUI
programming, right?

~~~
kls
_the stack has to be backwards crap for GUI programming, right?_

Right, please dont take my praise for react as an endorment that the state of
the industry is where we need to be. Rather I see it was a step forward.

For a little background I have been in the business since Tim Lee published
his first page of what would become the WWW. I would venture to say the first
webpage I wrote was in the first 100 and if not, certainly within the first
1000 pages developed. Before that I was a typical desktop developer (though I
was young, so that career was short lived). Anyways, the reson I bring up my
background is to make the following observation and that is, from the
implementation of the common gateway specification I always felt like the web
took a wrong turn. Not that we should not have an internet enabled application
spec but rather we tacked it on to a distributed document specification. That
being said, we tried and tried to build the "web" for applications but none of
them won. Meanwhile, hackers continued to deliver applications via web pages,
through ingenious hacks to the HTTP spec, CGI, and Javascript everything else
floundered with the exception of Flash and that was killed by Apple (as well
as it's abuse on web pages) and lack of open spec until to late.

So that brings us to where we are, the worst possible app UI technology won by
attrition. The people building that technology spent a generation building
entire UI's and then dumping them down to the client. When we finally broke
ourselves free of the dumb client model, that style of development persisted
as it was pervasive. Many attempts have been made to free web devs from that
mindset with some pretty good frameworks (good in web measurement) but the
build everything in one big controller mentality has been pervasive. React has
been one of the first frameworks to free web developers minds of that model
yet there continues to be efforts to go back Vue is one of those efforts. The
reality is it takes more thought to think about a UI as reactive components
that react to change as it's easier (in the beginning) to write procedural
code in a monolithic controller and if a framework allows it that is where
developers will default back to. Which in my opinion is a step in the wrong
direction. I have seen web developers almost get several times and it seems we
always regress back to controller based thinking the first to set it back was
Backbone and the second was Angular.

React is certainly not the state of the art in UI programming, but it is the
state of the art in web UI programming and knowing where we came from I am
happy for that.

~~~
e12e
My impression is that vue is one of the first sane approaches to actual simple
gui components for the web that works (delivering on the promise made by Web
components).

Do you really feel the mess of multiple files react seem to dictate is much
better? (Honest question, I haven't really used either in anger).

From what I can gather more radical approaches like elm and clojure script -
seem promising, but are ultimately (for now) let down by the frameworks doing
"too much" \- in effect working against the rich vms browsers have become.

I'd like to hear/see more of why you feel vue leads to (demands?) giant
controllers as opposed to facilitate real re-usable components?

------
miloshadzic
<X> developers should learn <Y>

X - What you know

Y - Technology _du jour_

~~~
joekrill
It absolutely baffles me that people still like to call React a "Technology du
jour". It's ubiquitous today. It's _THE_ go-to front-end web development UI
framework.

~~~
eterm
In your bubble that might be true.

In my bubble everyone is still using mostly ad-hoc jquery consisting half of
snippets copy-pasted from stackoverflow.

~~~
jrfarina
What bubble is that may I ask?

~~~
sullenpaladin
I share a bubble with eterm, in a Fortune 100 enterprise. I have heard React
mentioned once by a particularly engaged front-end developer, but everything I
know of in production is JQuery, a couple Angular 1 apps, and a whole lot of
horrible older stuff.

------
wc_cs
I'd like to know where he's getting his figures about Rails from. As someone
who left a Rails job (no React) fairly recently and has now switched to a
React-centric role, while I was job-hunting there didn't seem to be a great
demand for developers who knew React _and_ Rails. It's almost like they're
suggesting that people from a Django background will be worse off, which I
disagree with. Regardless, I do agree that Full-Stack Rails developers should
learn React.

~~~
revorad
I linked to one HN whoishiring thread in the article -
[https://news.ycombinator.com/item?id=12846216](https://news.ycombinator.com/item?id=12846216)
\- but if you look at some others, you will notice that a lot of companies are
using both Rails and React. I've seen the same on other job boards. My own
last consulting gig was at a company which was gradually porting its Rails
view layer to React.

------
nnd
Serious question: what's the advantage of using Rails for the backend/APIs
over Node or various Python frameworks?

I want to pick up a new backend stack and deciding between Rails and Go.

~~~
basch
can you go pure backend? [https://robots.thoughtbot.com/how-we-replaced-react-
with-pho...](https://robots.thoughtbot.com/how-we-replaced-react-with-phoenix)

------
throw2016
I think the technology discussed and preferred at HN is often skewed towards
heavily promoted SV based tech, large unicorn backed tech or a technology
stack that currently pays well. And often is not reflective of the actual
quality of the technology.

I don't think this is how how it should be in a tech focussed community.
Things should be judged on merit not value added to resume or potenial for
well paying jobs.

------
ungzd
Wordpress and jQuery have way more job postings.

But still React does not require extensive training, it has quite simple API
and no quirky concepts, and you can start using it right away without
"learning".

~~~
bitexploder
I am not so sure I agree. React is anything but easy when getting started. It
takes work and an agreement to learn a certain amount of "modern" JS+Web
tooling. If you come in with strong engineering and dev background, but not a
lot of knowledge about modern web libs and frameworks it can be more than a
small chore. I do agree, once you are into it, its design philosophy has a lot
of appeal.

------
Marinlemaignan
React developers should learn Rails too.. it'd make everyone's life easier.

------
MattyMc
TL;DR It will make you more money. There are many ways to integrate React with
Rails. To get started do the React tutorial and buy my book.

------
pawelkomarnicki
I noped out of React the moment they made that clear they expect me to pass
HTML as the JavaScript method attribute without quotes ;-)

