I have no idea why the author tries to judge a framework by a stackoverflow post. A lot of the examples are needlessly verbose and some are even wrong, like the "providerprovider" he rightly mocks.
Well, how about we look into the actual documentation?
Next up he still does not seem to understand the difference between Services, Factories and Providers. That's cool and all and might even prompt some to, you know, investigate further and assume that maybe they haven't understood it correctly yet before clicking "must blog now" button. He jumps the shark (straight to ridicule) by making up his very own nonsense:
> Of course we we can configure providers if we need to configure our applications. How else could we configure our applications and make them configurable for our enterprise scale configurable applications.
You know, actually the distinction makes perfect sense. A provider is an object that you know you will want to configure globally before it is being used (data source providers, url routers etc.). A service sits on the other end of the spectrum and is being called freshly right when you need it (more in the direction of the pure objects he has in mind). Factories sit in between those two - they cannot be configured ahead of the application, but allow for more internal functionality instead of just returning an object.
Having the distinction helps people editing the code figure out what they want to do and others, in turn, to understand what the other programmer was up to. Yes, you can use them somewhat interchangeably, but that's life for you: things overlap. How well and strict they are used is up to the programmer.
Now, I'm not bashing plain, custom OOP Javascript - If that's your thing, by all means do it, knock yourself out! But what's with the hating on people who seem to have a different approach? Wouldn't it be healthier to first try to understand where they are coming from? Surely they can't all be totally in love with wasting their time on "ruining it".
----
In the end what this comes down to is that the author doesn't seem to have sufficient experience with the kinds of environments that make the structures in AngularJS not just pleasant, but actually a life saver. That's fine - we don't need to all have the same perspective. I just don't get this style of argumentation that boils down to "don't understand, must bash".
He also makes fun (as does one of the SO comments) of this quote from the (old?) angular docs:
> An Angular "service" is a singleton object created by a "service factory". These service factories are functions which, in turn, are created by a "service provider". "The service providers are constructor functions". When instantiated they must contain a property called $get, which holds the service factory function.
You know what? Fuck it. When I tried to understand the Servicy/Factory/Provider distinction, I stumbled upon the same SO post and you know what ended up being the perfect way of understanding it? Forcing myself to go back to that paragraph right there until I understood it.
> No, you are not reading a thesis, you are reading the angular docs apparently. If it were a thesis it would probably be trying to explain a solution to some sort of problem instead of describing a made up solution to a made up problem. (Actually, that's not strictly true because academics are in a world of their own too but close enough).
> It's okay, I don't really do enterprise any more.
I'm as sceptical as the next guy about frameworks, hate "enterprise" with a fiery passion and I escaped academia before it fried my brain.
But I don't think myself too cool to do my due dilligence before dismissing something that I very obviously don't understand yet.
I think most people here know and understand the patterns involved here: Factory and Provider Model. From this knowledge, I guess the post is easily recognizable as exaggerated. This does not invalidate the gist of his argument. What the post author complains about (and I agree with him) is:
1. These patterns add complexity from the get-go of an app. He ridicularizes, and picks both an extreme example and an extreme Angular solution, but the message is sound.
2. These patterns have failed us in the past. Anyone who has worked on large enterprise projects has dealt with the immense complexity and, surprisingly, with the lack of configurability in the end result (a failure of the pattern objective).
I'd add a last point, not explicitely stated:
3. Last, but definitely not least, Javascript does not need these! Javascript is not a classic object oriented language.
Let me try my hand at supporting my last point. Imagine you want your database connection to be globally configured. You also want code needing a connection to be decoupled from the exact implementation. Just refer to a mythical DBConnection object in the DB client code:
connection = DBConnection.singleton()
And have it so that the DBConnection object instance exists prior to being called (instantiate it in the configuration stage of the app):
DBConnection = { prototype: new PgsqlConnection(...) }
Javascript being classless[1] and supporting prototype based object inheritance invalidates many of the assumptions behind patterns in use in classical OO languages. This is even more relevant when we are talking about flawed patterns.
[1] Yes, ECMAScript 2 and beyond have classes. It's an error, never got traction in the real world, and I hope it never does.
> Javascript does not need these! Javascript is not a classic object oriented language.
No language needs these. To me the GOF patterns have always been wisdom as opposed to a solution. When you are dealing with the interaction between complex systems you can refer to the knowledge that GOF patterns provide.
GOF patterns basically say "this is one way to solve problem X." It is my belief that they never say "this is the actual way to solve problem X." In fact I've found that they are often bad solutions within the context of the problems I solve. Exact copies of them only work in rare academic scenarios.
TLDR; You'll find lots of GOF inspiration in my code, however, you'll never find a text-book GOF implementation in my code.
The message is: we cannot just take "design patterns" from one language and shove them into another. All a "design pattern" is, is standard way to mitigate a lack of abstraction. If the language itself had a way to, say, create singletons (for instance, by having a singleton keyword), the need for that particular pattern would disappear.
Likewise, design patterns for javascript should be based around the points where the abstraction is lacking. Therefore, they'll be likely very different.
Angular is being adopted by a lot of enterprise-y / small business shops, specifically because it can be used (just like typical enterprise code) to have "coders" who don't know how to code, write software.
What's that, you've never used javascript before? Don't worry, just write this one directive, and we'll have someone else test it in UAT. There, now the most harm that dev can do is isolated to one behavior on a page.
So I read this post as an indictment against that style of coding, and for someone who just escaped enterprise consulting, it rings true.
Because the truth is, between jquery / react / backbone / npm and the basic js module pattern, you really don't need angular. Angular just provides a consistent framework for people who don't want, have time, or skill to write an organized front end on their own.
And considering how fast angular is taking over the shops I've seen, the 'you killed it' message might not be so far off.
Angular is being adopted by a lot of enterprise-y / small business shops, specifically because it can be used (just like typical enterprise code) to have "coders" who don't know how to code, write software.
I've heard this claim applied to a lot of technologies, but in the five years I spent in the enterprise software world, I never once saw it happen. People might try to have non-coders write code. For about five minutes. It never lasts longer than that.
What you do see, on the other hand, are a bunch of uninspiring programmers who will find a way to write strictly procedural code in any language or framework.
edit: just realized this might have been a communication problem. I meant coders that have the resumes of programmers, but are specifically hired cheap because they aren't actually programmers, just people reaching for the salary. The kid right out of college with some vb skill. 80 people on visas from some Indian contracting company.
---
Definitely depends on the level of quality of the enterprise shop. When I was doing consulting, part of the new employee hiring process for a new developer at the client site was to open a Microsoft support ticket to help the "dev" install visual studio.
Gotcha. Makes sense that it's just a terminology problem. How uninspiring does a programmer have to be before you can no longer call them a programmer? :)
If you claim .Net programming skills, being able to install visual studio might be a good first step : D
As for a serious answer? Who knows. That said, I know some people dislike eric raymond, but I still keep a warm feeling in my heart for http://www.catb.org/~esr/faqs/hacker-howto.html, if only because its one of the first things I stumbled upon way back.
I disagree: coders who don't know how to code won't be using Angular, they'll be chopping-and-paste JQuery all over the place (assuming an application of significant size/scope)
I'm not disqualifying your post, actually. Directives are pretty horrific to write (I prefer KnockoutJS's bindingHandlers because they are so simple), but I am disagreeing that frameworks are necessary in a large codebase with lots of developers working on them. And that people's codebases are worse off for using Angular than a free-for-all nothing at all. (This comment particularly was directed at the fact that Angular actually has a lot of challenging concepts for your average web developer.)
I agree with both of your points. I was also attempting to point out that large companies with sub par programmers also use specific frameworks as a crutch in order to put boxes around how much of a code base a particularly inept programmer can screw up simultaneously. Angular lends itself to that in the js space.
It's more than "coders who don't know how to code", it's also managers who don't know how to read code or review diffs. Sadly, there are lots of experienced coders whose planning horizon stops as soon as the code works i.e., they don't maintain code or think in those terms as long as it's working. This is often why shops use these overreaching frameworks.
Systems administration is no different, which is why so many servers are now either straight-jacketed in OS packages + chef/puppet/ansible or such a mess they're the equivalent of spaghetti code.
IMO this is fundamentally a failure of higher education (EE/CS, IS ...).
> You know what? Fuck it. When I tried to understand the Servicy/Factory/Provider distinction, I stumbled upon the same SO post and you know what ended up being the perfect way of understanding it? Forcing myself to go back to that paragraph right there until I understood it.
Yeah, that paragraph is difficult if you don't actually read through it and understand what it's saying. However, if you read through it with the intent of understanding it, it makes sense. And I think that really highlights the problem: the author wasn't reading to understand. At the point he got to that paragraph, he was already frustrated or upset, or whatever, and wasn't attempting to understand anything.
Key point: don't read documentation while frustrated. Take two minutes, relax, kick back, and read it with the understanding that it can teach you something.
I'm in the position of having written frameworks. I read that paragraph and though "Exactly! This is necessary for dynamic object binding using containers" etc. Nothing unusual at all. It depends upon context. As a professional I find it odd the OP brags about remaining ignorant of a common topic in his field.
Simplicity is actually really difficult to achieve. The only anti-intellectualism is Angular offloading that burden on it's developers. There are many other binding frameworks that have put more effort into both their use and their documentation. Hell, in the time you've read this you could already be a ractive.js expert.
It's easy to not use a C-based language and forget that there are many fundamental patterns that are still applicable, even if they look different. The purpose and intent behind a pattern is generally more important than the actual name used or the code structure. The factory pattern defines what it does (essentially code that creates objects without the caller needing to know the details), not the syntax behind it.
I see this happen all the time, even in functional languages.
I don't think the author jumps to conclusion prematurely. He hates all this factory, provider, blah, blah nonsense, and I can identify with the feeling.
It seems like your response is based around "it's not easy to understand or comprehend, but can be with plenty of skullduggery". That's not what we need in the programming world. Things don't need to be made inaccessible for the sake of being inaccessible.
Hmm -- there's no indication for the author not understanding the patterns. The point is, JS does not need these patterns (which are usually imported concepts from other languages), there are unique ways to do it in JS. (Think of late binding.) The critique is, JS is becoming that enterpisey like backends used to be at the time of the dot-com-bubble. It's the framework bubble.
Developers have become used to loading several K lines of code, just to remote control quite simple tasks, that could have been done natively by a humble number of lines of code. It's high time to point out that there isn't any emperor inside the new cloths! (Just a bunch of woven code.)
...When someone has a bunch invested (time) in a thing, it's understandable (not necessarily justifiable) to be defensive about anything that challenges that thing.
And the converse of that is that when someone spends a lot of time deliberately not learning a thing (as the author of the article seems to have done), it's understandable for them to be defensive about the utility of those things.
The author makes one fundamental error, which is the assumption that any of those things are necessary. You don't need to "create a hello world service to create the hello world factory to create the hello world sercice so you can print hello world on the screen". You can just print hello world to the screen. You can do it in the template, in the console, wherever.
You don't need layers of abstraction for simple tasks like "printing hello world", but when you have things that do need those layers of abstraction, they're there, and they're appropriate. The alternative is to write uglier code, which it seems the author prefers.
That said, I don't mean to discount preference in this debate, which many seems to have done. If it isn't to the author's taste, then cool. If he'd rather write small, pluggable modules, that's cool too. Those small, pluggable modules have their limitations though, and the author either hasn't run into them, or refuses to acknowledge that, at least for some use cases, small, pluggable modules aren't actually the best choice.
You should check the background of the author, I can guarantee you that he has more then enough experience...
In most cases the necessity for factories and providers in IOC-containers are an indicator that your software is badly architected. Lots of us have walked that path in the past, and now know how to handle this.
I hate to bring you the news, but your comment might actually indicate that you are on the beginner expert level.
Well, how about we look into the actual documentation?
https://docs.angularjs.org/guide/providers
What you find is that you define a provider like so:
and then, if you want to configure it, you inject it with the suffix 'Provider' into your config function (called when launching the app): So - what's so ridiculous about that?----
Next up he still does not seem to understand the difference between Services, Factories and Providers. That's cool and all and might even prompt some to, you know, investigate further and assume that maybe they haven't understood it correctly yet before clicking "must blog now" button. He jumps the shark (straight to ridicule) by making up his very own nonsense:
> Of course we we can configure providers if we need to configure our applications. How else could we configure our applications and make them configurable for our enterprise scale configurable applications.
You know, actually the distinction makes perfect sense. A provider is an object that you know you will want to configure globally before it is being used (data source providers, url routers etc.). A service sits on the other end of the spectrum and is being called freshly right when you need it (more in the direction of the pure objects he has in mind). Factories sit in between those two - they cannot be configured ahead of the application, but allow for more internal functionality instead of just returning an object.
Having the distinction helps people editing the code figure out what they want to do and others, in turn, to understand what the other programmer was up to. Yes, you can use them somewhat interchangeably, but that's life for you: things overlap. How well and strict they are used is up to the programmer.
Now, I'm not bashing plain, custom OOP Javascript - If that's your thing, by all means do it, knock yourself out! But what's with the hating on people who seem to have a different approach? Wouldn't it be healthier to first try to understand where they are coming from? Surely they can't all be totally in love with wasting their time on "ruining it".
----
In the end what this comes down to is that the author doesn't seem to have sufficient experience with the kinds of environments that make the structures in AngularJS not just pleasant, but actually a life saver. That's fine - we don't need to all have the same perspective. I just don't get this style of argumentation that boils down to "don't understand, must bash".
He also makes fun (as does one of the SO comments) of this quote from the (old?) angular docs:
> An Angular "service" is a singleton object created by a "service factory". These service factories are functions which, in turn, are created by a "service provider". "The service providers are constructor functions". When instantiated they must contain a property called $get, which holds the service factory function.
You know what? Fuck it. When I tried to understand the Servicy/Factory/Provider distinction, I stumbled upon the same SO post and you know what ended up being the perfect way of understanding it? Forcing myself to go back to that paragraph right there until I understood it.
> No, you are not reading a thesis, you are reading the angular docs apparently. If it were a thesis it would probably be trying to explain a solution to some sort of problem instead of describing a made up solution to a made up problem. (Actually, that's not strictly true because academics are in a world of their own too but close enough).
> It's okay, I don't really do enterprise any more.
I'm as sceptical as the next guy about frameworks, hate "enterprise" with a fiery passion and I escaped academia before it fried my brain.
But I don't think myself too cool to do my due dilligence before dismissing something that I very obviously don't understand yet.