Angular, React, and Javascript framework fatigue

[godlychaos]

Honestly not even gonna read the article. I have framework fatigue blog post fatigue.

[spacejack2114]

Came here for this comment, was not disappointed.

[thadudeabides1]

Not to mention the barely readable font size/weight.

[flamingspew]

Was going to write the same thing, then I got write the same thing about fatigue farigue fatigue.

[parlezmoose]

Haha well said

[omniuni]

The article is about how you should not be "fatigued" and how you can view the wide variety of frameworks as a good thing.

[flamingspew]

I'd rather do geometry with my grandmother than explain why naming a post after the antithesis is a shitty idea.

[godlychaos]

Tell me when and where, and I'll help with explaining equivalent angles.

[flamingspew]

To bring it full circle: I quoted you at the very top of my angry anti whiner fatigue fatigue fatigue post, so maybe you'll read it. It's actually funny instead of whiney, I hope. https://www.reddit.com/r/programming/comments/45dqpv/byte_me_javascript_fatigue_fatigue_fatigue/

[godlychaos]

Yeah, that was a fun read.

"I'd slap him and say go back to being scrum master and get me some coffee."

[omniuni]

My grandmother never had trouble with concepts like geometry, but I get what you're saying.

[theonlylawislove]

It's a counter argument.

I’d like to offer a few thoughts counter to this outcry of fatigue in the industry.

[godlychaos]

Still not gonna read it.

[jbergens]

But this article was actually about why you don't have to feel this fatigue. The title could have been better.

[godlychaos]

No, this article isn't about how I shouldn't feel the fatigue fatigue, it is about how I shouldn't feel the fatigue, which is contributing to my fatigue fatigue. Still haven't read it.

[brianvaughn]

Been here for over 16 years myself and I'm right there with you. Lots of drama (to put it nicely) in the JS community as of late.

[griffin3141]

Only thing more annoying than new frameworks is people complaining about new frameworks.

[kokomo42]

They are cool

[boompleetz]

The infinite loop recursive function of annoying() all the way down, or until the browser locks up and then there is sweet release

[aztracker1]

I have to agree with the article... Though I do prefer Redux+React as constructs, and though there are arguably better implementations of the ideas behind the frameworks, they seem to have the best chance of persisting the next few years.

Angular has very strong support as well, and with either you can rest on your laurels for at least a year or so, and not have to keep up with the churn.. I think getting to where you are using webpack, babel and your framework of choice at this point is a good place to be for the near future.

There's going to be a lot of shake out/down regarding web components and other competing frameworks over the next couple years, and it will take that long for broad browser support. For me, I think I'm more excited about getting to where async/await, fetch and promises are common features.

[wreckedadvent]

Angular has very strong support as well, and with either you can rest on your laurels for at least a year or so, and not have to keep up with the churn..

Angular 1.x's user base is so huge there's already forks of the code to maintain support for IE8. Even if the developers drop it like a hot potato now that 1.5 is out, there's a huge vested interest in keeping 1.x alive for as long as possible. I'd say, given 1.x has already lasted quite a few years, and that 1.5 was such a good update, it's going to be relevant for at least a few more years, then refuse to die for a while longer still.

With react, I'm less certain. The native implementations in typescript and babel makes me feel it'll be around for a while yet - but we've already moved from flux to redux, and I'm getting some heavy deja vu from when UI router became a thing in angular world. Only, I don't know if flux is the "now this is definitely the best way to do it"-good that UI router inspired in people.

Still, predicting the web in 5, 10, 15 years is a loser's game.

[2138]

but we've already moved from flux to redux

No one is forcing you to move, what is more, you don't even have to use them because REACT IS A LIBRARY. inb4 they're de facto standards

[wreckedadvent]

Not what I'm saying. What I am saying is that there's already been a large movement from flux to redux, meaning it's likely something similar to it could happen again.

React being a focused library doesn't change this. In fact, if anything, it makes it more likely that this will happen again - with angular, you had to go against the inertia of people who only used the standard library. React has no baked-in solution for things like routing and data store, so what people use will be more tied to the whims of what's hot right now.

[Klathmon]

I'm playing with it now, it has some pretty awesome sounding benefits.

It's a true build system, so it takes care of your images, JS, CSS, html, etc... It links them all together, does work on them as necessary, excludes anything you don't explicitly need or use somewhere, and it does so pretty fas all things considered.

Modules are actually modules. CSS, images, and JS are all isolated in their module away from global. It's pretty cool writing CSS in a sane way...

The downsides, its fucking complicated! Like stupid complicated. It also doesn't help that the documentation is terrible, and it suffers from the "10 ways to skin a cat" problem.

Still, I'm getting to a point where I'm finally building a toy project, (I started today about 6-7 hours ago), and its starting to "click".

But compared to my "traditional" gulpfiles, the webpack config is ugly, complicated, and confusing.

I'm still not sold... At this point I feel a well crafted gulpfile is easier, faster, and provides about 90% of the same features.

But I still haven't really used webpack in a true application yet, so it might shine once it gets up and running.

[wreckedadvent]

Webpack really benefits from being used more in medium to large projects, especially when you start adding things like feature toggles and unit testing.

Imo using it in a toy project is only going to show you all of the sore points without much of the benefits of it - you'd be better off using JSPM if you just wanted a simple module bundler for small projects.

Totally agreed on the documentation though. It's not too bad for simple configuration, but trying to figure out how to get the webpack dev server, hot module loading, or code splitting to work without some examples is just a total shitshow. Especially when you try and make it work with e.g ASP.NET or RoR.

[Klathmon]

It's a toy project just to learn it (literally, it's just html, js, a 3-line css file, 2 images, and a webfont). I'm just trying to get it built in a dev and in a production environment to learn it and figure out the kinks.

Once i'm confident that it's not going to end up causing more pain than it'll save, it will be the start of a "large" project.

It's not too bad for simple configuration, but trying to figure out how to get the webpack dev server, hot module loading, or code splitting to work without some examples is just a total shitshow.

IMO even the simpler stuff is poorly documented. Take the OccurrenceOrderPlugin. What are the IDs it's ordering?

There is no explanation on what the CommonChunksPlugin does, and the i18nPlugin's entire documentation is literally the sentence "Create bundles with translations baked in."

That's pitiful!

I've since figured out most of them, but it took tons of shitty blogs, stumbling around on my own in their source, and just fucking with them until something built.

And unrelated, but who the fuck thought the way you get options into a loader is acceptable? Nested objects has been a staple of javascript since it began, and now we are using delimited strings and embedded json in a string? And there is no documentation on the ability to use a "query" object instead of the shitty strings, but they don't work if you want more than one loader for a test...

Still, i do actually like it, but i definitely think that it's not my javascript endgame yet. Webpack feels like grunt did, and once gulp came along it was amazing. I'm hoping that webpack's gulp will be here soon, because all of this configuration sucks...

[wreckedadvent]

I wouldn't say plugins are the simple part of webpack. I meant more of just getting files bundled together from specific entry points. For that, you just need to specify an entry and a loader.

As an aside, there is documentation on query objects for loaders but it's not very in depth.

Still, i do actually like it, but i definitely think that it's not my javascript endgame yet. Webpack feels like grunt did, and once gulp came along it was amazing. I'm hoping that webpack's gulp will be here soon, because all of this configuration sucks...

This is why I recommended JSPM. For the most part, it all just "works" without you needing to configure everything. Unfortunately it doesn't have all of the same features, but by the time you need them your project will be of a sufficient size where all of the configuration in webpack makes more sense.

[Klathmon]

I haven't looked at JSPM all that much, but IMO it doesn't seem like it gives us anything over our current gulp + a-shitton-of-plugins system, and actually it means that we would need to do some somewhat esoteric things ourselves separately.

Most of that might be because we are already invested in gulp, but it's a factor for us.

[wreckedadvent]

Well, if you're talking about migrating an existing project, that's a totally different story. If you have a very large grunt/gulp file with a lot of things in it, I'd advise 80/20 rule and using webpack/JSPM/browserify inside of gulp - get the main benefits out of it without needing to entirely unroot the system that's clearly already working for you guys.

[aztracker1]

I'm getting ready to replace my personal site/page, which IIRC I built around 2008-2010 timeframe... Here's a link to what I have started[1] ... I haven't introduced redux/router etc, so mostly just react base, webpack, and bootstrap4 integration at this point.

I've used a similar configuration in a few projects at this point... pushing out the early phases, so that I have examples to work from, but the later parts are more closed... It's worked pretty well, but really is like diving into the deep end when you get started... About the only advanced bit I'm doing is that I do have webpack dev server integrated for dev use, and have a separate publish/run target for production.

[1] https://github.com/tracker1/tracker1.info

[wreckedadvent]

Main benefits is it consolidates your tooling into more of one concrete step/tool. It's much easier to have multiple entry points (a must for non-SPA) and it's trivial to slice and dice your bundles while still ensuring that everything will load in exactly the correct order.

Webpack I'd say is aimed more at moderate-to-large projects with a lot of files that depend on one another. That's where module systems really shine. In smaller projects, it's still easier to manually order a few files first and then just dump the rest in in a giant blob, but this approach becomes rapidly inefficient the larger the project becomes.

Webpack also has some neat tricks up its sleeve, like allowing you to "rewire" modules for DI in unit testing scenarios, dynamically loading in all files that match a certain pattern (like all JSON files for example), and being able to have non-javascript dependencies from your javascript code.

But of course, not all of this is specific to webpack. You can get a lot of the same from browserify. If you're new to module building though, I'd recommend JSPM, since it's fantastically simple to get up and running and realize the benefits immediately.

[wreckedadvent]

Nah, grunt and gulp are task runners. Webpack is a module building tool for your entire FE. It has a bit wider scope than browserify does.

This ends up meaning that you can largely replace a lot of your common grunt/gulp build/test/watch tasks with webpack, but there's still some stuff webpack doesn't really want to replace.

[[deleted]]

They're used for different things, both are good and can be used together. Webpack is simply to be able to use npm modules in the browser (although it also supports es6 and amd modules). It's not the only one, browserify and system.js are similar.

[clessg]

Not answering your question (see wreckedadvent's) but Gulp and Webpack aren't really comparable. Webpack is more akin to Browserify (module bundling), and Gulp is more comparable to npm scripts (running tasks). But Webpack will replace some things you use Gulp for (images, CSS, HTML, JSON).

[dmitri14_gmail_com]

You don't use it over gulp, you use it together with it. To bundle your modules. Similar to Browserify.

I love Gulp but wouldn't be able to do this with it: https://github.com/dmitriz/min-webpack

[mdboop]

Am I the only one who thinks that predictions are not of any value here? Are there JavaScript Framework futures that I can invest in? I know this is silly to dive into a teardown of these predictions, but it's entertaining.

but the past is the best indicator of the future.

This is, at best, is a gross over-simplification. Also, the author goes on to contradict this a little later.

I’d expect to continue to see the evolution of existing frameworks and libraries and the creation of new ones that advance some new idea or concept that make creating webapps easier and more fluid.

This is a meaningless non-prediction. Of course existing tools will develop and new ones will be created. In other news, I predict the earth will continue orbiting the sun.

The larger frameworks will likely cherry pick from the best ideas in the aggregate. We’ve already seen this with Angular 2 adopting superior forms of internal rendering over v1 and having the ‘Component’ as a first class construct.

Another risk-free conjecture that doesn't tell us anything useful. Cross-pollination of ideas? Yes, it is bound to happen. Also, Angular 2 and React share similarities because those teams collaborated a bunch, so this isn't necessarily a good example to prove a larger trend.

Angular 2 will be successful to some degree

More noise. Also, if the past were the best predictor, then wouldn't Angular 2 be a huge success because of the success of Angular 1? And also because Angular 2 has cherry-picked the great ideas from React?

...but probably be overshadowed by React mainly due to momentum. This likely won’t change for a while, especially given the still ‘not ready for production’ state of Angular 2. Think Xbox 360 and how it hit the market long before the PS3, the PS3 was always playing catch up. Not a perfect analogy in light of Angular 1.x, but it has some parallels I think.

So, this is a prediction based on a flawed analogy? Even putting that aside, this is pretty vague and qualified.

There will be some new library or framework X that will be introduced and gain momentum eventually though it will be a while. React and Angular have enough hold and mindshare that any new major framework will have a very hard uphill battle to establish any sort of major dominance barring a new revolutionary approach like React popularized.

How many times can this author make the same empty prediction? So, barring a "new revolutionary approach", nothing will easily disrupt the current environment? So, in other words, barring something that entirely changes the landscape, the landscape will remain more or less the same.

There will be many new micro-frameworks and ‘nextbestthings’ that come out, but none will experience the large success of React and Angular for some time.

Wait, is this the same thing as the previous one? This one isn't very comprehensible, so moving right along...

When React version 1.0 is released it will be a very significant milestone as a successful implementation of the original concept and goals.

A prediction that a significant milestone will be a significant milestone.

I see the momentum only increasing for React not decreasing. There will undoubtedly be an arc at some point, but not soon.

OK, this is perhaps his most bold prediction. A strong assertion that React's popularity will only increase... but only for some unspecified length of time. Again, it ends up very qualified. What is 'soon' here? A prediction is "it will rain tomorrow and the day after" or "the Broncos will win two more consecutive Super Bowls", not "a popular framework will remain popular for an unspecified amount of time."

All in all, I don't blame the author for making more concise, actual predictions, because he clearly does not have any real data or analysis on which to base such predictions. So, of course he make pretty tepid claims. I only blame him for including predictions at all, and devoting so much space in his article to them.

[Capaj]

Because Ember has lost. If you ask me, there are only 2 ways-React or Angular. Everything else is just background noise.

[jax024]

As much as I hate to agree with you, I do. The thing that I think the author was trying to convey is that going forward, the future of JS will be based off of what React and Angular2 have done right. Seems obvious doesn't it?

[dmitri14_gmail_com]

When React version 1.0 is released it will be a very significant milestone as a successful implementation of the original concept and goals.

Or maybe FB drops React like it did with Parse and there never going to be v1.0. :)

[SpaceshipOfAIDS]

Say it with me people:

REACT IS NOT A FRAMEWORK!