
Why I’m throwing out React and going back to Angular 1.x - swalsh
https://medium.com/@stevewalsh/why-im-throwing-out-react-and-going-back-to-angular-1-x-3aa2b54e907e
======
Lazare
TL;DR: Author already knows Angular 1.x, doesn't have the time to learn
anything new.

"The stack you already know" is generally a good choice, yes. But the title is
misleading and somewhat clickbait; he's not "throwing out" React; he's
_keeping_ Angular. He doesn't list any technical advantages Angular 1.x has,
and in fact he labels it "obsolete" and says using it in the long term is
"suicidal".

A better headline is "sometimes you gotta use the crap stack you have instead
of learning a new one"; nothing he says has anything to do with specific
frameworks.

~~~
frostirosti
Sounds like the typical pretentious, the world is changing and I don't like
it. Take the time to learn new technologies and adapt to changing landscapes.
Mastering the abstract ideas makes you more flexible.

~~~
coldtea
> _Sounds like the typical pretentious, the world is changing and I don 't
> like it. Take the time to learn new technologies and adapt to changing
> landscapes._

Why? Most of the times is fad. Learning some select things well is way better
(and more feature proof) than "learning new technologies and adapting to
changing landscapes" (e.g. VB in the nineties, Java/C# later, Rails after
that, Node now). One could have been a stable salaried top-end engineer in the
same, non-shifting, niche the whole time...

~~~
tracker1
JSX and Redux are going nowhere... they'll probably outlive React, though I
also think that's going nowhere anytime soon.

Redux (and similar single unidirectional stores) is a paradigm shift, but
seeing ever broadening adoption and similar ngrx/store for example in the
angular side.

JSX as a compositional representation of a component tree is just plain
useful... it's your component markup in your code, instead of code here, style
there, markup over there... it's all on concern, the component. Many newer
frameworks that differ from React on some technical reasons are using or
suggest JSX transforms.

You get that in a more stable platform with React. Add in fetch, react-icons
and material-ui you're pretty close to set... start with create-react-app and
your off and running, not much, if at all harder than getting angular1 up.

And while Node is no longer growing exponentially, it's still one of the most
prolific open communities around (including npm for client-side JS projects).

As to your list.. Java and C# are pretty firmly around today.

~~~
coldtea
> _JSX and Redux are going nowhere... they 'll probably outlive React, though
> I also think that's going nowhere anytime soon._

Let's check back in 10 years.

> _Redux (and similar single unidirectional stores) is a paradigm shift, but
> seeing ever broadening adoption and similar ngrx /store for example in the
> angular side._

And in a few years we could have another paradigm shift, with webassembly
bringing about e.g. a nicer UI stack for web work.

> _As to your list.. Java and C# are pretty firmly around today._

Speaking of Java, that I've followed best, where are Applets? Or J2EE? Or
Swing? Or JS Faces? Or that java grid API that would revolutionize computing?
Or lots of other Java-related fads du jour that history forgotten, but at the
time had loads of adoption and were touted as the best thing since sliced
bread?

~~~
tracker1
Not sure, the only things I've dug deeply into are Netscape Livewire (server
javascript), Classic ASP (JScript and VBScript), PHP, ASP.Net, Ruby on Rails,
Castle Monorail, ASP.Net MVC, Node (express, koa), Backbone, MEAN-stack, React
.. some interest in go, rust and .Net Core lately.

Of all the above, React is the first paradigm (combined with a Node backend)
that _EVER_ felt like the right way to do things... all others were "Cool",
then dig in and get really disappointed somewhere. The more I've gotten into
React... (I didn't like a lot of the early flux-like frameworks, but enjoying
Redux) the more I feel it's really close to the right way to build web
applications.

Of the above, I really disliked PHP and didn't like RoR too much, mostly
because I don't care for ORMs at all really, even Entity Framework irks me at
times, but at least it's easier to manage than others I've worked with. I've
done one-off things with other tools/frameworks, but none really felt right...
And this is in two decades of web applications development.

Mongo and RethinkDB feel close to right similarly. Postgres + plv8 feels
really close too, but for the clustering.

For now, Web Assembly can't touch the DOM. And I'm only guessing, but it's
likely the first implementations that bridge the gap will be around React/JSX
or a similar core for the communication, and representation of UI vdom.
Soemthing using the `material-ui` package could be awesome.

------
oheard
Sigh. You have limited time so get on with building your product... You're
procrastinating by writing an article about your insecurities with regards to
using old tech in search for validation. Just do it, who gives a fuck?

Good luck.

~~~
deedubaya
> Just do it, who gives a fuck?

It all boils down to this.

------
mr_tristan
People seem to be missing that he was complaining more about the tooling
around React then issues with actually coding in React. Or at least that's
what I read when I read this:

> However the tooling is maddening. ... After I was setup (I chose the
> “stable” technologies) it wasn’t good enough. As soon as I started trying to
> bring in libraries to do what I needed, I found my chain wasn’t up to the
> task. Of course I couldn’t just follow the instructions on the CLI when
> there were errors… because there was a few levels of indirection in the
> tools. I’m losing time battling my stack. It should be helping me.

So this isn't "I hate React" it's more "I hate webpack/browserfy/babel/..." or
whatever the hell he was trying to run with. And there's some truth to this,
because the installation page of React is basically "try to get it going with
your toolchain". And then a bunch of examples of working with different
toolchains.

Basically, he probably felt the `create-react-app` approach wasn't stable, and
did a bunch of google searches to figure things out, and jumped down a rabbit
hole from a variety of blogs, etc that contradicted each other, etc. I've
experienced this frequently with anything non-trivial in jS-land.

It's interesting, but in general, I suspect the React documentation would be
better served with presenting fewer options in the early stages.
"Installation" really should be "Getting Started" and that should _only_
reference one thing, like `create-react-app`, and working with other
toolchains should probably be more clearly separated out into other topics,
like "Creating a production toolchain with webpack and babel".

~~~
tracker1
Agreed, the documentation should have a getting started, and related tutorials
working with create-react-app with more "api and tools" documentation for
working in diy toolchain setups.

Being able to expand on the toolchain is coming though... which I'm happy
for... I want all the coming soon stuff babel can give me now, as well as my
environment/test setup is different.. I want my test right next to the script
that's under test for unit testing.

------
sreyaNotfilc
The big issue with the author is having the time to build something. I
wouldn't necessarily have chosen one framework/language over the other.

The reason why is the author's current level of proficiency for building
something that he wants. For example, if he was an ace at Assembly (instead of
familiar with Angular) he could've easily wrote an article titled "Why I'm
throwing out Angular 1.x and going back to Assembly".

Its all relative. Some people can afford having the "most beautiful code", but
that also goes with a budget and a group of people who can make it work (e.g.
Steve Jobs ordering beautiful code/engineering for the Macintosh).

I would say the most logical route would be to "Build the Damn Thing".
Facebook used that notion, got the product out, got ahead, and now can afford
sound code. Heck, Zuckerberg doesn't even code on Facebook's source anymore.
No one (besides us engineers) knows or cares what Facebook is running on. Same
with many other productions (not only software) out there (when was the last
time we cared exactly how an Oreo cookie was made?).

So to answer Steve's question "What am I supposed to do?", I would say "Just
Do It! Make the product.".

Do the work and live the dream (Same with all of us dreamers).

~~~
sdflkd
> No one (besides us engineers) knows or cares what Facebook is running on.
> Same with many other productions (not only software) out there (when was the
> last time we cared exactly how an Oreo cookie was made?).

Except for the people that complain about performance?

~~~
tracker1
I tend to complain more about interactive state issues, Redux (or other flux-
like options) helps a _lot_ there. Performance is usually a little further
down, unless it's many seconds for response. Lately every time I see weird
state management issues it's almost always an angular app. And depending on
what you're doing, that can be outright exceedingly painful in Angular 1.

------
sfilargi
> I recently quit my job to start a company.

React + Redux, Go, Scala, Cassandra, micro-services, etc.. are all products
made to solve Google and FB sized companies.

If you are an one man band, starting your own little startup or project, stick
to Python or Rails or PHP or Node, jQuery and Mongo.

Your focus should be on getting something out there as soon as possible, not
writing perfect software.

~~~
tracker1
I wouldn't consider React + Redux particularly more difficult than an more
typical MVC framework + webpage + jquery + one-off scripts. You can reach
scaling (number of developers needed) issues very easily that way though.

~~~
sfilargi
In my experience React + Redux translates to 10x boilerplate. Plus if you
decide to go with React, probably means you are going for SPA, which again
means a lot of work you get for free in your typical html + jquery app.

I agree with you on the scaling argument, but the OP is a single developer
starting a new project from what I gathered, so IMHO the last thing he should
worry about is scaling.

~~~
tracker1
What work you get for free? You can reuse wrapper components... can even
tether the route and the wrapper together, so it's easier to manage your
route/component mapping...

    
    
        <Router ...>
          <DefaultPageLayout path="/" component={DefaultPage} />
          ...
    

So the templating benefits to html/jquery are a bit of a mixed bag, and if
you're doing React + Node, you can start off with your fallback route being
the app, and later add server-side rendering if in a time crunch.

I will say the initial setup can be higher, if you don't like the structure of
create-react-app, but most people new to react coming from a PHP and Angular
background probably should stick closer to as it comes in the box. Wiring up
redux is the biggest paradigm shift though... unidirectional workflows mean
much better predictability in terms of state with far fewer bugs. Most of the
times I see weird state issues in websites/apps lately they're angular 1
though.

------
raspasov
It comes down to what you are most experienced and familiar with. Choosing
based on that is fine, but you have to realize that might be a very bad
decision mid or long term. The author seems to be aware of that so all is
good. It took a few somewhat successful projects gone wrong for me to learn to
prefer objectively simpler techogies technologies even if it takes extra few
weeks to start. But if your hard budget deadline is literally within weeks it
makes sense to prioritize fast, familiar and easy.

------
sjclemmy
Sounds like a sensible choice. In the shadow of a deadline you haven't got
time to mess about with unfamiliar stuff. I've made similar decisions. After
all, if the product succeeds, you can rewrite it. If not it doesn't matter.
Either way you can throw it away.

------
jmcgough
The entire article body could have been deleted and replaced with "I'm taking
on technical debt for a higher initial velocity"

------
jorblumesea
React is a view library, Angular is a complete application framework. Two
different use cases.

React was never meant to supplant the Ember/Angular world. Sure you can bolt
on react router etc but it's Apples and Oranges. Even if he was okay with
learning a new framework under that deadline, was it even the right choice in
the first place?

~~~
tracker1
react, redux, react-redux, redux-thunk, react-router, fetch (or axios),
material-ui, react-icons are usually what I start with, for the core of the
client. Has everything I might need that angular offers, without complicated
DI and weird custom DSL templates. Now this also includes webpack, babel, and
some related bits. But that can be skilled by going with create-react-app

------
headcanon
Sure, if you know you're faster with Angular 1.x than go for it. With your
circumstances, building the product with speed should be number one priority.
Personally I'd be infinitely faster with React, but thats because I have a lot
more experience with it than Angular. Best of luck!

------
jondubois
For a small team of developers, I would agree that React doesn't actually add
any value but it makes sense for a bigger team and a more complex product.

One thing that I just can't stand about Angular 1 though, is dependency
injection (which, ironically was one of their most touted 'features') - When
working in a large team, I find that it's a hassle to figure out where a
particular service was declared because they were magically injected into
directives/controllers without any indication of where they came from; to get
this workflow right requires a lot of discipline when it comes to folder
structure and file naming conventions. I prefer to use the ES6 import
statement as promoted by React or the tag-based module import promoted by
Polymer.

------
jaypaulynice
I've used Backbone/Marionette, Angular, and React at this point. I think
Backbone/Marionette is the best framework so far maybe because it was the
first one I did a big project on. Backboe/Marionette has very clear separation
of concerns...the only true MVC framework among the 3. React is great for
reusable components, but the tooling around it is so backward...I feel like
I'm writing a java application and I need to piece things together.

Btw I'm working on a django/react application and I have yet to figure out how
to not duplicate the react routes in django. It defeats the purpose of a
single page app because I don't want to reload all the same resources because
a small piece of the app changes...how do you fix this?

~~~
tracker1
Make your 404 handler return your baseline react without preloaded state. If
you use node server-side it becomes easier to do universal rendering and state
injection.

~~~
jaypaulynice
Thanks! I don't want to hit the web app at all...I want to load all my static
files once and then it's all client side...getting data from the rest service
when it needs it...

~~~
tracker1
You can do that... if you want to handle all the routes, just make your 404
handler on the server return your base html then.

------
hyperbole
At the end of the day tech is just a collection of tools & for the most part
those who use them are digital carpenters, so if you need to build temp
scaffolding and a screw driver works better than a hammer, sure use the right
tool for the job. Unclear why this is newsworthy but let me wish you the best
of luck in your endeavors. If you are operating on borrowed time, let me
recommend editing your /etc/hosts and blacklisting hacker news, etc.

One caution since you seem to have fallen into the trap of not experimenting
nor venturing out of your comfort zone -- it's a surefire way to learn nothing
from this experience including what tools make you more productive...

Good luck

------
frandroid
Has this author not heard of create-react-app? It gets the stack things out of
the way.

~~~
amadeusw
The stack is not stable and surprises keep popping up in development, after
bootstrapping a new app.

~~~
hackerboos
The only project I've found to be more stable than create-react-app is Ember.

Please elaborate.

------
partycoder
The costs of taking decisions like these (e.g: using old or proprietary
technologies) are:

\- Career growth: your team will be accruing experience in a technology the
market does not need. That is not in their best interest, and they will not
feel happy about it.

\- Hiring: It becomes difficult to hire people when you decide to move away
from what everyone else is doing.

\- Sunk cost: As more code using old libraries is added, migration becomes
more expensive.

~~~
scarface74
Honest question. Could the same be said about using a technology that is not
old or proprietary but not the most popular?

I'm thinking in particular about Ember. I'm leaning toward Ember for our web
apps because in some of our apps, any full framework is overkill and we are
going with a combination of Jquery + Handlebars, but other times, we may want
to use a full framework and Ember uses Handlebars for templating.

I'm not seeing any jobs for Ember.

~~~
partycoder
Some technologies are not used by the vast majority of people (e.g: Erlang,
Oz, Haskell, Prolog) but working with them will always offer you a valuable
lesson if they teach a different _paradigm_.

e.g: the actor model, dataflow concurrency, logic programming and so many more
stuff. Those are extreme examples of different paradigms.

So, the question now is: are you cultivating skills related to an obsolete
paradigm, or a skill that you cannot trade in the market? If so, that's not
good.

------
iLemming
Good that most of us don't have that attitude - otherwise would be still
patching and perforating punch cards. Angular 1.x made sense in 2009. If your
job is to cut down trees and you still insist on using a hand-axe instead of
learning how to operate a chainsaw, well... What can I say? "Don't stay too
long in 18th century", I guess.

------
tracker1
TL;DR; I don't have time to learn something new, sticking with what I know.

This wasn't a choice for any competitive reasoning... purely panic driven. As
for fast react scaffolding, it doesn't get much easier than create-react-app,
or whatever the angular2+ equivalent is.

------
jennytodavchych
Yea, here is also one good article where you can read about both
[https://thinkmobiles.com/blog/angular-vs-
react/](https://thinkmobiles.com/blog/angular-vs-react/)

------
par
Honestly I didn't find React too hard or arduous to implement anything in.

------
uhryks
Tl;dr author suffers a bit of JavaScript fatigue

------
notliketherest
This guy makes his situation sound pretty fucking dire and then blames react
for slowing him down? It takes awhile to learn any new technology. So he goes
with what he knows. How is this React's problem? I worked with React for a
year and know well enough to get a brand new app up in less than a day. So
it'd make sense for me to choose React. I don't understand why this guy is
blaming React.

~~~
kerryritter
I am also a React fan but phrases like "I worked with React for a year and
know well enough to get a brand new app up in less than a day" make me kind of
sad. The cost just to get up and running with a JS framework these days is
kind of painful. CLIs are doing a decent job resolving this, though.

~~~
headcanon
With create-react-app, it takes less than a few seconds, if you're fine with
their defaults. If you need to mess with the webpack config it will take a bit
longer but once you do it the first time its not a big deal. Putting
everything together from scratch would take awhile, but that's the tradeoff of
having a really flexible modular system.

~~~
tracker1
I usually count on a week to boilerplate a new application. I find that
spending that time to do things in a more hand-crafted way is made up for my
having a consistent implementation where the structure and code make sense.
Glad to see more projects moving away from `./test, ./scripts, ./views,
./styles` structure.

~~~
headcanon
that's fair - I built a react app for my company's website which is statically
generated (a twist on server-rendering), and that took about a week to
boilerplate. Next time I do it though it will take no time at all.

~~~
tracker1
True, as long as you're using the same versions of the tools... I find that
even after a year, if I'm boilerplating something out, even if similar, it's
still about a week. The tools change, and APIs between versions break. I had
to deal with a react-router change between the last beta and the final 4.0.0
just yesterday (this.context.router.push vs this.context.router.history.push).
I tend to mostly lock down my versioning on things to a large extent as a
project matures... but even keeping up is more organic.

Starting something new in a year, or 18 months can be dramatically different
than the previous start.

------
kapauldo
Anyone know what he's building ?

