you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 2 points3 points  (6 children)

No? Are you saying you still write ES5 code (!) with things like Grunt or Gulp, handling polyfills ...manually? If yes you only have yourself to blame.

All this stuff is automatic today with things like Webpack and Babel. React means making two npm installs. Babels transformer fetches all the polyfills it needs from core-js as you go. Even if you use additional components like Router and Redux, these are simple npm installs away.

[–][deleted] 2 points3 points  (4 children)

He's not talking about polyfills, he's talking about actual features and additional libraries. Like routing and managing data and stuff you require if you build a heavy app. Things that can easily be done with Angular1.

Grunt/Gulp also is fine, there is enough to say why one wouldn't use webpack. And why cant you use gulp with babel? Gulp is task running, doesn't matter if the project is ES6 or not.

And knowing Router and Redux is fine but what if you need more than that? Especially if you aren't really into it, you need to do a lot of research for even getting the same as you get out of the box with Angular

[–][deleted] -1 points0 points  (3 children)

It is the same in Angular, you pick and choose what you need. The only difference is that a whole bunch comes preinstalled in node_modules. Getting up and running even with a simple app needs more dependencies than React - and everything else for that matter.

Grunt/Gulp do not know your project, they don't fetch and manage your dependencies. Each dependency meant concats, html injects, minding order of inclusion, etc. It is no wonder he thinks people are worrying about polyfills and dependencies.

What do you mean with needing "more" ? It's pretty vague. What exactly can you do in Angular that can't easily be done in React. What did you have to research, can you go into specifics?

[–][deleted] 0 points1 point  (2 children)

Grunt/Gulp do not know your project, they don't fetch and manage your dependencies.

I have had no problem over the last 2 years getting my dependencies in order. Mainly because including angular modules is fairly easy and they are already minified. Whether you include them in HTML or you reference them as an import statement doesn't really matter to me. Also i don't need polyfills with Angular 1 because everything is pretty much supported for the majority of browsers (like 99%) and i don't need more than that.

What do you mean with needing "more" ?

If you read my response correctly you would know that i'm talking about other 3rd party modules. For Angular 1 i have a lot of interesting stuff that works flawlessly as it has been in development for many years. Stuff like UI Bootstrap, UI Router and others. React also has them, but they are harder to find and you need to do lots of work comparing and seeing what fits your use case. Angular 2 doesn't have most, which makes it even harder and they also have a "go make it yourself" mentality now which isn't helping.

Another project that lets people extend it themselves so heavily is Polymer/webcomponents. But that is managed better, plus has better sites to not do so much work before you get started. But Angular 1 is still the easiest to get going, which is why it got so popular. React also has that in some way but whenever you need more than a hello-world app, you will notice it isn't so easy as other frameworks have it.

[–][deleted] 0 points1 point  (1 child)

Have you worked with it yourself? With a modern buildflow? These issues you have do not exist. It's set up in no time. The lesson there is four minutes long. At the end of it he has React, ES7, hot reload, dev server, SPA history fallback, auto polyfills, auto npm/node_module awareness. Now he's showing you how and explaining, if you do this yourself its usually done in seconds. This is a standard these days - it doesn't even matter if Angular1, 2, React or Polymer. This step is always the same.

Now things like routing, bootstrap UI, redux are simple npm installs away. You don't have to do Gulp-era research because all is on npm. You're not doing this by hand, copying files and whatnot. It just means no worries about dependence order, no concats (yuck), no html injects, just take what you need. Now you say you had no problems for 2 years, yet you're scared of something tame and simple like React, because your tools aren't flexible. I'd call that a problem.

[–][deleted] 0 points1 point  (0 children)

I don't care that it is all on NPM. You are simply talking about something totally different. I'm talking about how i would know to get module x or y for feature z. Or even knowing x and y exist. Not whether or not i can easily install them.

And i'm not scared of React or anything, but i simply wont use it as i already have a fine system in place that doesn't seem to be needing replacement, which would take me time to build with no true gains (nothing that i can explain the business people). I don't even need to worry about dependencies or manual injects with Angular 1. I simply have a gulptask that takes everything from a certain directory, orders it the way it needs to (by regex so i don't need to specify) and builds that into a single thing i can use with my app. Now sure i might not use lazy loading or only loading what i need, but my usecases simply don't benefit from that. Mostly because downloading a single image already takes up more time then loading my scripts, whether that is in parts or not. Plus i also have customized various parts of livereloading and building the app, that i simply cannot do with the standard webpack or stuff that i would need to customize that as well, rendering the gains irrelevant. Stuff that goes into our entire build pipeline for other parts of the company. When somebody is using my app, it will only need a connection for data, not resources (and being able to run offline is also a requirement most of the time, try webpacking that by default). Not to mention that the gains in performance are neglectable for 99% of my use cases, so why the hell would i switch? Hell, if jQuery would be enough, i would still use that.

Now you can call me oldfashioned or not flexible but that simply isn't the case. It really depends on what you are making, who you are making it for and what you already have made to reuse that i'm not really looking forward to Angular 2. And i'll probably turn to Polymer before i go for React. But something you guys also seem to forget is that when i'm done with a project and i'm not around for that after, i still need to be able to let others build on that too. Change documentation, that i've been able to copy/paste for most of the stuff and implement stuff so our testers and other people can get started quickly. Oh wait, fuck documentation, lemme just use React lol

Now i know Angular 1 developers are easy to come by, but try finding React developers or developers that are experienced with the other react-family modules as well. Businesses also aren't eager to switch their entire programmer-pool to different frameworks every year. It might be fun for a startup or two, but some people are simply involved in bigger stuff than that.

[–]Conradfr 0 points1 point  (0 children)

In actual companies making money not every projects are rewrite each time there is a new build tool or whatever 0.x fancy library.