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.
I'm not sure if I'm "young" in this instance, but I'm 31 and have been coding since I was ~15 and I had the same feeling. "An ill fitting jacket" is a nice way to describe it - I can't put my finger on exactly what feels wrong but a lot of things that "magically" happen bother me.
Actually for me, React fitted me well as a jacket! Until a friend asked me why there was and advantage to spend an extra minute taking on and off that jacket instead of using a simpler jacket(vanillajs) that fitted just as well but that I could take on and off in seconds.
My conclusion today is that the massive hype around React, Angular and so on, is a similar story as The Emperor's new clothes.
Also 31, also coding since ~15, and also had trouble wrapping my head around Rails.
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 agree. I should have about the same age of cyberferret and I won't do anything serious with sinatra or padrino. Too much work to do. I don't have the time for that and my customers don't have the money. I wrote web apps from scratch in C (not ++) and Perl in the 90s but I don't want to reinvent the wheel every time, and after 10 years and many developers Rails is a much better wheel than anything I can build myself. Replace Rails with any other comparable framework, even if any other framework I've seen requires to do more work.
I don't think it is easy to dabble in React starting at zero knowledge of all these frameworks. Vue is just accessible and familiar enough to be more approachable at first. When buiding an internal app I took a long hard look at React, but ended up with Vue. I had previously used Angular 1.x.
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!
I should clarify, that my definition of 'dabbling' is usually to build an actual app with it. I will usually try and build an app that I have already done in another language, just to get familiar with the new language oddities etc.
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...
I am with you. I often want to enjoy the magic of something like React, but when your entire coding task is a man day or two it becomes really hard to justify learning React. That is my main gripe, many would just say that means "React is not for you" and technically that is obviously true. But in reality it is just the immature tooling around everything getting in the way. It is all in such a state of flux and experimentation that you can't always do things that should be simple simply. I think developers often do their own work disservice by not being a little more careful with dependencies, basically.
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.
Rails is, by design, a very opinionated tool. The focus on establishing sensible defaults as a convention is great if you can work at least somewhat within those conventions, but it can become increasingly annoying if you regularly bypass the defaults.
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.
I felt the same way at first, but I read through the rails guides and it all made sense. And for people who work on a bunch of different CRUD apps all that conformity is a big win. You can jump back into a project and already know where everything is and how it fits together.
It is sort of like Go vs Rust in terms of learning cost. Clearly, based on React's popularity the cost is worth it to many. Vue has really nice docs and is more approachable. Not a messiah but for many projects it is a great choice.
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.
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?
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.
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?
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".
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.
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.
I linked to one HN whoishiring thread in the article - 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.
I've only seen this where companies had some of their apps/infrastructure running off Rails(mostly API based stuff, minimal services etc) and were wanting to use React on the front end. I haven't seen a lot of postings either for the specific pairing.
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 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?
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-...
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.
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.
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)
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?
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.
I had the same impression about Vue. When Redux came out I tried to learn React/Redux and, although I got it, it felt verbose and I couldn't quite pass the noob phase. Maybe I din't try hard enough.
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.
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.
56 comments
[ 2.5 ms ] story [ 151 ms ] threadNice zeugma!
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.
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?
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".
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.
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?
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.
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)
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
[2] https://vuejs.org/v2/guide/single-file-components.html
[3] https://github.com/vuejs/vue-cli
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.