Rails developers should learn React
medium.com
medium.com
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.
My conclusion today is that the massive hype around React, Angular and so on, is a similar story as The Emperor's new clothes.
Even if you don't need a view framework, do you do serious work with no libraries? What browsers do you support?
It'd get really frustrating to support even IE10 with nothing protecting you from random idiosyncrasy
At work we still support IE8 for some clients. VanillaJS? No thanks. I'll take even jQuery 1.X (2.x drops IE8 support) over vanilla.
For me I think it was mainly because with Rails, the implicit conventions are actually hidden rules, and they're not always intuitive either, which made memorizing them much harder than, say, memorizing a small set of simple functions in an actual library. That's probably also why I have so much trouble with CSS I'm guessing.
These days I maintain a Clojure web app that uses Compojure, and I have to say it's significantly easier to reason about than the iceberg Rails is.
I don't believe it has anything to do with age.
While you can optionally use the official router and state management libraries, these are completely independent and unnecessary.
I know I see this said a lot but the comprehensibility of these frameworks and tooling is borderline impossible to deal with for dabblers. Docs break almost instantly (Angular 2.x). It is hard to manage the number of small ever changing tools, even when you understand the principles.
I think if you took someone with good knowledge of C and good knowledge of Javascript (NOT web), just the base languages it would be easier getting into systems programming!
Funny that you mentioned AngularJS - I built quite a few apps using the Ionic Framework a couple of years back, and that is (was) built upon Angular 1. I found Angular quite easy to pick up and run with. React, not so much.
But its all OK. I am sure React is a great framework and all, just not my taste...
Someone spends a few days wrangling a pile of NPM packages, build frameworks, and minifiers into this magical state that lets them operate very productively, but it isn't scaleable productivity in that now you have forced the whole developer community to do this multi day learning battle. And now as your whole pile of JS evolves under you, you are committed to this stack and keeping up with the evolution of all the dependencies.
You end up with a lot of "least bad" solutions that aren't actually very good to the core problem. I see that as React's biggest problem with adoption. The core model is actually really great, but the usability is a steep learning curve.
The goal is to make development easier, but you probably won't gain those benefits if your definition of "sensible defaults" isn't compatible with the choices made by Rails. Sinatra is a very different approach, which may work better if you want minimal library that doesn't involve a set of design conventions. Both Rails and Sinatra are useful tools; use whichever is a better fit for your needs.
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)
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?
Nice zeugma!
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
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.
With Vue, on the other hand, it was easier to get started. I got a prototype working in a week with no previous knowledge of the framework. I'm avoiding the component state and using a Redux like approach using props and a centralised state, and I didn't even need to use Vuex[1].
I'm using typescript, which helps catch a lot of bugs early on, it's a little difficult to integrate with single file components[2] (which are awesome, btw), but once I got it working, it proved to be an excellent combo.
The documentation is cristal clear and very beginner friendly. If you're getting started I highly recommend using vue-cli[3] to bootstrap your project
I think Vue sits between React and Angular, being simpler than Angular, offering more features than React, and easier than both to get started.
[1] https://github.com/vuejs/vuex
Does it solve all the problems of the predecessors?
People are already starting to talk about Vue like it's the new messiah.
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.
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?
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.
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?
X - What you know
Y - Technology du jour
In my bubble everyone is still using mostly ad-hoc jquery consisting half of snippets copy-pasted from stackoverflow.
I honestly haven't seen a ton of Rails job posts over the last two years. Mostly Node or C# posts or the occasional PHP as far as backend code goes.
I like Rails too, first true MVC I used.
I want to pick up a new backend stack and deciding between Rails and Go.
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.
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".