Why I’m throwing out React and going back to Angular 1.x | Hacker News Reader

Why I’m throwing out React and going back to Angular 1.x

medium.com

51 pointsswalsh66 comments

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.

Yes, but that better headline does not have two buzzwords in it.

That headline would probably fare a lot better here, though.

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.

I mean, I do also buy the, 'change is hard, and if Cost(Change) >= Cost(Not change) + delta(x months) then it's not worth it`

I think the point of the article was that his goal is to develop his product before he runs out of money. Maybe if his business is a success he can then pursue your suggested goal of improving his abstract thinking and gaining flexibility.

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

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.

What about Polymer and web components?

I think that's the future, not React.

Web components, or something like it may well be the future... But to me the web component structure feels more alien than React.. it's almost the inverse though. Of course, that's once the browsers better support it, and ES6 modules natively is probably the biggest adjacent need, that will be some painful times during the transition.

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

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.

The vast majority of article titles beginning with "why I..." (and variation) is clickbait. I still don't get why the HN community still falls for this every day.

From this context, I guess one can surmise why his 'real' choices are between Angular, Ember, and ko (which, despite being knowledgeable and positive about Angular, I'd pick if I wanted to iterate fast), but still...not especially meaningful.

Yes, Knockout has a lot of drawbacks, but it's really good for rapid prototyping and iteration.

I thought he gave his reasons for leaving React behind pretty clearly, no? Mostly around tools and work flow.

These matter to him so I wouldn't just dismiss the article.

Angular 1: I'll just put all my dependencies in a libs folder so that I don't have to track the node modules folder in my repo.

Angular 2 + tyepescript: Nope. All must be compiled on the fly from the node modules directory. So sayeth the Google.

---

Angular 1: Oh look, stable production ready versions of all the external libraries I need.

Angular 2: Coming soon...

---

Hacker News Comments: Oh somebody prefers Angular 1 to Angular 2? Must be because they're stupid and hate learning new things.

That is not an honest tl;dr for this article. A better one would be:

"Wants to move as fast as possible, spent too much time dealing with React tooling, picked Angular 1 from among what he sees as stable options [without a clear reason]".

Or "Angular 1 - the php of javascript frameworks". :-) (Although obviously the php of javascript is jQuery, right?)

If you want to get started quickly then review the fact that you even require a SPA in the first place.

Other than that, you can get started pretty damn fast with create-react-app.

https://github.com/facebookincubator/create-react-app

Someone in the comments of the post suggested the same thing - people who criticise React (or any framework really) of "taking too long to set up" says one of two things to me:

1: they're too picky in what they want to use generators like this (or one of a billion Yeoman templates) - which then says don't complain something takes too long to set up when you're the one adding complexity

2: they count learning new methodologies/frameworks as part of the "setup"

In the case of #2, what you know is always going to be quicker than what you don't. Complaining that "it takes too long" should be rephrased to mean "I don't have the time to learn something new"

Is there an equivalent for this scaffolding app, but for server side PHP or Ruby ?

If you're saying "server-side PHP/Ruby API + React SPA frontend", you'll probably be able to find some boilerplates on a github search, but essentially they're just two separate apps at that point, so you're better off just building them that way and maybe tying them together with `make`. If you want server rendered React you can only really do that with Node.js. However the specific architectures/implementations of these apps vary enough its better to make one yourself that suits your needs. create-react-app is designed to have very minimal, bare-bones defaults so you can build whatever opinions you want on top of it.

He did choose PHP for the server-side, so there's that.

jQuery is more consistent and historically nicer to use than PHP... I think even comparing Angular to PHP is a disservice to PHP.

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.

> Just do it, who gives a fuck?

It all boils down to this.

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

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.

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

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

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.

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

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.

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.

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.

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.

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.

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

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?

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

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!

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.

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?

I agree and think Backbone/Marionette is under appreciated.

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.

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

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.

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

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

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

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

Please elaborate.

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.

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.

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.

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.

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.

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

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

Tl;dr author suffers a bit of JavaScript fatigue

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.

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.

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.

Well, some minutes with npm. With yarn, it might take a few seconds.

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.

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.

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.

Anyone know what he's building ?

Reply on news.ycombinator.com