
You have ruined JavaScript - PhilipA
http://codeofrob.com/entries/you-have-ruined-javascript.html
======
haberman
_What the actual fuck is this? I read this as "in order to do a hello world,
you must first 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."_

Well, you misunderstood, and now you're ranting according to your
misunderstanding.

I'm not an Angular, expert, but I'm pretty sure that the situation is this:

1\. "Hello world" does not require any dependency injection whatsoever. (ie.
it does not require services, providers, _or_ factories). Note: if this was
not true, I would agree with this rant completely.

2\. _If and when_ you decide you want dependency injection, if what you want
to inject is a simple value, you can just provide it directly, without using a
service, provider, or factory.

3\. _If and when_ you decide that you want to provide a dynamically-generated
value, you can specify a function instead which will get called whenever the
value is requested. This is called a "factory."

4\. _If and when_ you decide that you want your factory to just "new" an
object instead of running an arbitrary function to provide the value, you can
register that object type as a "service."

5\. _If and when_ you decide that you want to configure that object type
first, you can register it as a provider.

If you want to stay at step 1 forever to keep things simple, groovy.

This is a example of success, not failure: you pay for only as much complexity
as you actually want to use.

~~~
nlh
As a newbie to all of this stuff (and yet still reading through this thread
trying to keep up), thank you. This was the clearest explanation & summary
I've read.

~~~
badman_ting
Note that you'll find nothing of the sort in the Angular docs. I believe this
is at least part of what the author is really railing against. If the docs
were crystal clear as to how Angular actually works, doing stuff in Angular
would be a lot easier and keep devs from getting pissed-off enough to write
rants like this.

------
pron
Sigh. I can't say anything about Angular because I've never used it. But this
constant ridicule of "the Enterprise" is getting on my nerves. Obviously,
software design patterns change a lot over the years. Old practices are
abandoned -- sometimes more slowly than we'd wish -- and others replace them.
But much of this criticism comes from the fact that the critics 1) use
technologies that are not mature enough to have growing pains, and 2) don't
really know how software is made in the real world.

RE 1, the factory/provider/whatever pattern, comes in real handy when 2 years
from now, a crucial ODE library that your air-defense system uses, absolutely
has to be replaced by something else. And it's not like a kid could write a
quick re-implementation in Go over the weekend.

As for 2, many of these patterns have been designed for software that does not
resemble web applications at all. Just to give a sense of how out-of-touch SV
developers can be with regards to the software world at large, IBM, Oracle and
SAP combined employ more people than Google, Facebook, Twitter and LinkedIn
combined, ten times over; there are more Java developers in the world than the
_entire population_ of the entire Bay Area.

I'm not saying that the maligned "enterprise" patterns have a place in a
client web framework, or that some of them aren't dated. All I'm saying is,
stop treating some software patterns that you think are unnecessary just
because all you build are CRUD web-apps as inherently stupid. They are not.
One of the reasons people working on CRUD web-apps can "move fast and break
things", and just "rewrite the whole thing in a couple of weeks", and say
stuff like "what's wrong with a simple 'new'?" is precisely because the
software they develop is, frankly, not that complicated.

I would also like to remind the author that his beloved Erlang was developed
in the very same environment he thinks so little of.

~~~
bananas
Engineer and architect of large enterprise products here (2 million line
Java/C# behemoths that do all sorts of weird and complicated financial shit).

Reality is actually as follows. Not joking I've done this job for 15 years and
worked with several large companies including one you mention. Perhaps your
experience is in the 1% of "enterprise" companies who have clue but this by
far is the majority:

Bold statement here: 99% of the use cases of all these patterns are totally
pointless and a waste of money and time. The add nothing to the product, they
increase complexity, decrease performance. It's cheaper and more reliable to
chop your product up and write each chunk in whatever separately with no
official architectural pattern usage system-wide.

Typically in the real world, you're going to end up with:

1\. Literally tonnes of DI/IoC code and configuration for an application with
an entirely static configuration. This is either in XML or DSL form using
builder patterns. Consumes 30 seconds or more to start the application up
every time. Aggregate over 50 developers is 16 hours a day pissed out of the
window.

2\. Proxies for anaemic domain models that are fully exposed. Consumes 30
seconds to generate proxies that do sod all. Aggregate over 50 developers is
16 hours a day pissed out of the window.

3\. Leaky broken abstractions everywhere actually destroying the entire point
of the abstractions. Makes refactoring impossible and maintenance hell. It's
better in some cases that they are not even there and that basic savvy is used
over COTS patterns.

4\. Acres of copy pasta. Why bother to write a generic implementation when you
can copy the interface 50 times and change the types by hand?

5\. Patternitis. So we need to use the BUILDER pattern to write the query to
connect to the DOMAIN REPOSITORY for the AGGREGATE to call the CODE GENERATOR
that fires up the ADAPTER to generate the SQL using the VISITOR PATTERN which
farts out some SQL to the database PROVIDER (and a 90 layer stack dump when it
shits itself). This is inevitably used in one small corner while everyone in
the rest of the system hits a wall in the abstraction and says "fuck it" and
writes SQL straight up and skips the layers of pain and because there are no
code reviews (because people are all sitting there waiting for their
containers to start up whilst posting cats on Facebook).

LINE 10 (remember this)

These things are never rewritten or refactored. They slowly evolve into a
behemoth ball of mud which collapses under its own weight to the detriment of
customers, a team of enterprise architects (usually from ThoughtWorks etc)
usually appear at this point then attempt to sell outsourcing services who
will "fix all the shit" for a tiny fee, leave a 200 page powerpoint (with
black pages just to fuck your printer up). The company struggles on for a few
years and is saved at the last minute by a buy out by a company at an early
stage of the cycle who slowly port all the customers and buggy shit to their
product platform. Then the team either dissolve and knowledge is lost or they
take a cash sum from the sale and start up some ball of shit company that does
the same again.

GOTO 10.

That's enterprise 101 because the people that have been hit by the clue sticks
know better than to subject themselves to this and do work in SF and SV and
London. Me: I'm a masochistic crazy person who wonders every day why I don't
just go and write web sites for half the cash or flip burgers because it's
less painful.

~~~
zoomerang
I agree with you for the most part - what you're describing is rampant abuse
by cargo-code programmers that don't know better.

This doesn't mean GoF design patterns are specifically wrong. It's just that
they are misused and applied in places they don't belong. When done properly,
they should emerge organically as you code without you even realising it (That
is to say good design patterns are emergent phenomena in good code, not the
other way around).

It also doesn't help that the entire software industry is fixated on single-
inheritance OO languages, which tend to encourage ridiculously bad designs.

> It's cheaper and more reliable to chop your product up and write each chunk
> in whatever separately with no official architectural pattern usage system-
> wide.

This nails good software design on the head. Don't write large software, write
small independent reusable components and combine them together.

 _This_ is what dependency injection solves well - When done properly. (If it
involves XML or config files it's not done properly).

~~~
agentultra
I think, as Peter Norvig once pointed out, that design patterns are a symptom
of an anemic language design. They cost us time and complexity for their
benefits. Java wouldn't need half the patterns typically employed to work
around the limitation that there are no first-class functions.

Eich himself admitted to avoiding adding classes to Javascript in his
interview with Peter Siebel for _Coders at Work_ :

    
    
      SIEBEL: So you wanted to be like Java, but not too much.
    
      EICH: Not too much. If I put classes in, I'd be in big trouble. Not that I really had time to, but that would've been a no-no.
    

It's a really good interview and I recommend the book. It seems like
Javascript was supposed to be an Algol-syntax over a non-pure Scheme inspired
core... but due to constraints was thrown together like most code is when
there's a looming deadline.

------
pilif
It's the same pattern that repeats itself all over the place. We've seen it
with Java, with Ruby, heck, even with PHP. And now with JS: As applications
grow, we tend to search for tools to help us cope with the growth.

After doing similar (but still slightly different) things over and over, we
start building abstractions and with every thing our abstraction can't deal
with, we make them more complicated.

Whether you use the official name of your thing ("factory") or you just run
with your own idea and term - the outcome is always the same.

As a library, you feel the need to be abstract enough to cope with every
feature request ever asked from your library and there will be tons of feature
requests and tons of little parts people want to customize.

And honestly, don't we all prefer using some public API of a self-contained
library to patching said library (think of the maintenance as that library
gets updated)?

This isn't about ruining a language. This is about making the right choice of
library or about the decision of building your own little customized thing
that exactly fulfills your requirements (and nothing else), but as your
requirements change, you're going to add abstractions yourself and suddenly
you're back at the AbstractSingletonProxyFactoryBean, though you might have
chosen a different name that nobody but your team understands.

As a library author, try to resist the feature creep; try to be opinionated
("I'm really sorry, but logging isn't pluggable. You want to log to your XML
based logging server? That's fine, but you'll have to build your own thing or
use a different framework") then you remain accessible and buzzword-free, even
though that might cost you some users in the short term.

Language has nothing to do with this.

~~~
anon4
An abstraction is not useful, in fact it's downright harmful, if it does
exactly the same thing as what it abstracts over, but more verbosely.

A lot of these patterns you're used to seeing in Java stem from Java's static
nature.

Here's a car factory in javascript:

    
    
      function makeCar(dealerName) { return new Car(dealerName); }
    

And here's a configured car factory:

    
    
      var myCarProvider = makeCar.bind(null, "my dealer");
    

It makes precisely zero sense to create abstractions that reimplement core
language features. That would be like writing a C function to add two
uint8_ts, or a macro that expands to inline assembly to convert a float to an
int32_t. You already have these things built-in, you don't need a gorillion
enterprisey patterns.

~~~
haberman
_Here 's a car factory in javascript [...] And here's a configured car
factory_

Great, now where is the part where the code that provides the "my dealer"
string can be completely unaware that makeCar() exists?

Oh, it doesn't exist? That's the problem that Angular DI is solving.

~~~
klmr
Here:

    
    
        var factory = makeCar;
    

The whole point of having first-class functions is that you can assign them.
The problem a factory solves is precisely the lack of this assignability
(which is why a constructor function is wrapped in a class).

~~~
haberman
Please put in the effort to understand at least the basic idea of dependency
injection before deriding it in favor of "simpler" solutions that do not solve
the same problem.

The specific pattern DI can solve here is:

\- one module provides some capability by name

\- another module makes use of that capability by name

\- the two modules have no knowledge of each other, and no higher-level glue
code is required to connect them together (and construct the appropriate
objects at the right times).

Your "solution" does not satisfy the requirements because it requires you to
manually construct the objects in the correct order. DI on the other hand will
automatically analyze the graph of dependencies, invoking the appropriate
factories in the right order.

~~~
masswerk
Sorry to say, but klmr is right. Since functions are first-class objects and
references are evaluated late, these issues are already managed by JS and
native scopes. There's no need to recreate this functionality in a framework.
You might just want to consider the entry point to your code.

~~~
masswerk
P.S.: What this really is about: Unit tests originally designed to go with
C/C++ do not work well with late binding. In fact this is a concept totally
foreign to these languages. It's essential to understand that these kind of
frameworks serve in the first line the purpose of test suites and only in
second place the needs of developers. (Developers should not mistake
themselves for test suites.)

------
protonfish
It makes me so happy so see some hate for Angular. I decided to specialize in
front-end web development a few years ago because the state of back end
frameworks was so abominable. I escaped to HTML, JS, and CSS so I could
quietly develop in peace. Now we have Angular, Knockout, Bootstrap - please
for the love of all that is good, just stop. This nonsense is nothing but
mountains of technical debt. When I tell this to framework fanboys, they
counter with "But you can get things running so quickly using frameworks."
This is the definition of technical debt (doing things fast now at the expense
of doing things slow later) but it is also complete nonsense. I challenge
anyone to a contest to create a quick font-end site where you can use as many
Rube Goldberg contraptions as you like and I only use jquery. So then when
they back down because they know they will lose their excuse is "But Chris,
you are just so smart - the average dummy developer can't do what you do." My
final rebuttal is "If you agree that I am such a genius, why won't you listen
to my advice?"

~~~
jordanthoms
We actually did this - we built our entire app using just jquery - and then we
spent a month tracking down issues with applying state changes to the DOM
before we gave up and rewrote the thing in Angular. We had a few bugs at first
but they were quickly fixes and then we had had a much more solid application,
since we only had to worry about keeping our data structures straight and the
two way binding would take care of showing/hiding the elements, updating
values, etc. Whole classes of bugs we were spending ages tracking down before
which happened after a particular sequence events just couldn't happen
anymore.

If you are doing something simple and quick by all means just use jQuery or
plain JS - the advantage of the more powerful frameworks comes into play when
building bigger things with complex scenarios happening. The challenge to make
a quick front-end site is meaningless - the more meaningful challenge would be
to write a complex real time application with both and compare, which of
course we have already done.

~~~
protonfish
You built a poor application, then rebuilt it - one would expect the second
one to be better no matter what frameworks you used. I still believe I could
do it faster and end up with a more maintainable code base.

The tools I use to keep my code maintainable are good practices, frequent
refactoring, and clear thought. No library can replace those. Why do you need
a 2 way binding to take care of showing and hiding elements? Only a 1-way
binding is required. I am currently working on an app that uses Knockout and
we are having horrible performances issues - all of these 2-way bindings are
checking for everything all the time. There are fixes for this - fixes that
would not be needed if we didn't build it with duplo.

------
Drakim
I keep reaching the conclusion that frameworks are evil and libraries are
awesome. Frameworks promise to organize your code and keep things structured,
but the inherent verbose nature of JS frameworks ends up harming more than the
structure helps.

Ultimately, if naked JS is too difficult to manage due to the lack of types
and interfaces, I much prefer to use another language that translates to JS,
rather than attempting to force it onto the JS language, because it always
becomes messy and half-baked.

~~~
Touche
Please name a UI platform where you don't use frameworks.

Android activities/fragments = a framework.

WinForms = a framework.

ncurses = a framework.

Unity / Unreal3 = a framework.

~~~
simias
I'm not familiar with your other examples but I object to ncurses being called
a framework. In my understanding of the word a framework defines to some
extent how your code needs to be organized and architectured, I don't think
ncurses fits this description. It's more like a terminal-based drawing
library.

~~~
yoklov
Thats what people typically market it as, but when you use it, it has mor in
common with various GUI toolkits. Lots of windowing, and the like, but not
much drawing.

Not sure if that makes it a framework, though.

------
PhilipA
The author might be confused by AngularJS, but all of the projects I have
converted from simple JS to Angular have more than halved the amount of code
needed, and made the applications much more easy to maintain.

~~~
bsaul
i completely agree. I'm 100% against bureaucratie , but accusing angular of
being bloated is a bit unfair. It does has its weird part (like the
service/factory pointed in OP) but in general code is much much lighter using
the framework.

As opposed to , let's say, spring, which transforms a simple project into a
gigantic mess of configuration files and abstract annotated code.

------
mercurial
I can sympathize with the article, but on the other hand, when you reach a
certain level of complexity, OO kind of forces you to use dependency
injection. Which means providers and factories of some sort for short-lived
objects, at least if you want to have testable code. I don't know if it's
"enterprise hand-holding bullshit", but having seen code with and without DI,
the DI one is definitely easier to work with and refactor. This doesn't mean
Angular is not over-engineered, since I don't use it I have no opinion on the
matter.

~~~
chmod775
Yeah. You're pretty much right.

The solution is to not use OO. JavaScript is not that good at it anyways.

~~~
jimmaswell
I really am not seeing a problem anywhere. OO and the structure that follows
from it, which is what ends up being seen in this instance, seems like a
perfectly reasonable way to write these programs. Programming in an inherently
object-based thing like the DOM without objects.. why?

~~~
zoomerang
Saying "OO is Evil" is the flavour of the month. Functional Programming is the
new cool kid on the block. This would, in theory, be a good thing.

Unfortunately legions of Javascript fanboys have recently noticed that they
don't have the keyword 'class' in the language, but they do have functions and
have decided this means that it's a functional programming language, and they
knew better than everyone all along.

They'll then follow it up with some perfectly nice procedural code and tell
themselves it's functional with a nice little pat on the back.

~~~
nobleach
I don't know if any of the "cool kids" believe Javascript is a functional
language. Can one write code in a functional STYLE in Javascript? (can they
write higher order functions, can they write functions with no side-effects,
could they build monads) Sure, it's entirely possible - just like it is in
Ruby, Python, and pretty much any decent language. I think what some of the
push is, is to write javascript in more of a functional style as they feel
it's more elegant. (I could be way off base though... I haven't been "cool" in
years)

------
cs702
This reminded me of "Why I Hate Frameworks," a great post from 2005 in the
Joel on Software forums:
[http://discuss.joelonsoftware.com/?joel.3.219431.12](http://discuss.joelonsoftware.com/?joel.3.219431.12)
\-- my favorite quote from it:

 _" I'll get around to building [it] one of these days, as soon as I've got my
factory factory factory all up and running."_

Frameworks often _are_ helpful, but as project complexity increases they tend
to make it harder to get things done.

------
fauigerzigerk
It's even worse. In Java the whole factory/provider approach was down to a
limitation of the type system. Yes they (we) went completely overboard with it
and the ridicule is deserved.

But what on earth is the justification for using that pattern in a dynamically
typed language that lets you tack anything onto an existing object without
controlling its creation?

~~~
Bahamut
I too was interested in what decisions spurred this design with application
using Angular at one point, and there is a talk from ng-conf by one of the
core developers of Angular that I think illuminates this:
[https://www.youtube.com/watch?v=_OGGsf1ZXMs](https://www.youtube.com/watch?v=_OGGsf1ZXMs)

It boils down to managing complexity in complex web apps.

~~~
insin
So it's a ComplexComplexApplicationComplexityManager.

------
bitL
Is actually anyone considering JavaScript not to be "ruined" by default in the
first place?

~~~
edwintorok
One of the LibreSSL blog posts linked to this rant about JavaScript, it goes
quite nicely with the AngularJS rant:
[https://www.usenix.org/system/files/1403_02-08_mickens.pdf](https://www.usenix.org/system/files/1403_02-08_mickens.pdf)

~~~
guard-of-terra
Thank you, an awesome read!

------
rafekett
I feel like these articles come up every few weeks. people don't understand
angular (particularly why DI is useful) and criticize it for being verbose or
confusing, usually using the provided sample code -- would it hurt to spend
some time actually trying to understand the framework than to dismiss it on
face because it looks kind of like something people don't like in Java?

~~~
davexunit
"Dependency injection" is just a silly term for formal parameters. Wow, we can
make a function more generic by minimizing the number of free variables! Who
knew?

~~~
seanmcdirmid
Dependency injection is more like dynamic scoping, whereas most formal
parameters are lexically scoped.

~~~
davexunit
Fair point, but that makes DI a really poor implementation of dynamic scoping.

------
thruflo
I switched to angular explicitly for the dependency injection. Registering a
singleton so it can be passed in to other functions and mocked out easily in
tests is something I find extremely useful.

Whether the framework should provide three different ways to register the
object is another matter (a design decision along the harder-to-grok vs
accommodate-variety axis) but, frankly, if you don't like factories, don't use
them.

------
taude
I don't really agree with the sentiment. I think JavaScript is being pushed
harder and in much larger apps these days, which is why these frameworks and
design patterns have cropped up. Try getting a large team, building a large
app writing cohesive code without some of these patterns. It's true, though,
maybe Angular takes it a little too far...but maybe not, I don't know, each
project is different in size, scope.

At first, we rewrote an app using mostly just JQuery, but it quickly turned
into spaghetti. Then we added four more devs to the team because it's a pretty
large project and this is when you need to start reeling in peoples coding
style, and applying some design and patterns so that when a new person comes
along in 8 months, they aren't totaly WTF?

The author sounds like he's working on a small team (maybe just with himself,
since he's writing bot the video streaming/encoding backend along with the
front-end), and therefore his style of coding while effective for a team of
one or two, likely won't scale up.

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

[https://docs.angularjs.org/guide/providers](https://docs.angularjs.org/guide/providers)

What you find is that you define a provider like so:

    
    
        myApp.provider('Car' //...
    

and then, if you want to configure it, you inject it with the suffix
'Provider' into your config function (called when launching the app):

    
    
        myApp.config(["CarProvider", function(CarProvider) { //...
    

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.

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

~~~
taude
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)

~~~
ep103
yup, directly into directives, and it'll be a nightmare, because that style of
software development is a horrible bane on the industry.

But I don't think that disqualifies my post at all.

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

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

------
pavlov
So much of the bad stuff in enterprise-style web frameworks is basically a
software reinvention of classic bureaucracy. Concepts like inversion of
control are meaningful, but applied in accreting layers they turn APIs into a
re-enactment of Kafka's _The Castle_.

The application developer is left holding the receiver of the telephone that
supposedly allows him to receive calls from the Castle. If only he can get the
right person at the other end of the line, then everything will certainly be
sorted out! The Castle is there to serve the developer, so of course there is
someone at the Castle who cares: it must be that he just hasn't got the word
yet...

 _" My dear Land Surveyor," replied the Superintendent, "how on earth should I
know all the sons of all the under-castellans?"_

 _" Right," said K., "then you'll just have to take my word that he is one. I
had a sharp encounter with this Schwarzer on the very day of my arrival.
Afterwards he made a telephone inquiry of an under-castellan called Fritz and
received the information that I was engaged as Land Surveyor. How do you
explain that, Superintendent?"_

 _" Very simply," replied the Superintendent. "You haven't once up till now
come into real contact with our authorities. All those contacts of yours have
been illusory, but owing to your ignorance of the circumstances you take them
to be real. And as for the telephone. As you see, in my place, though I've
certainly enough to do with the authorities, there's no telephone. In inns and
suchlike places it may be of real use, as much use say as a penny in-the-slot
musical instrument, but it's nothing more than that. Have you ever telephoned
here? Yes? Well, then perhaps you'll understand what I say. In the Castle the
telephone works beautifully of course, I've been told it's going there all the
time, that naturally speeds up the work a great deal. We can hear this
continual telephoning in our telephones down here as a humming and singing,
you must have heard it too. Now this humming and singing transmitted by our
telephones is the only real and reliable thing you'll hear, everything else is
deceptive. There's no fixed connexion with the Castle, no central exchange
transmits our calls further. When anybody calls up the Castle from here the
instruments in all the subordinate departments ring, or rather they would all
ring if practically all the departments -1 know it for a certainty - didn't
leave their receivers off. Now and then, however, a fatigued official may feel
the need of a little distraction, especially in the evenings and at night and
may hang the receiver on. Then we get an answer, but an answer of course
that's merely a practical joke. And that's very understandable too. For who
would take the responsibility of interrupting, in the middle of the night, the
extremely important work up there that goes on furiously the whole time, with
a message about his own little private troubles? I can't comprehend how even a
stranger can imagine that when he calls up Sordini, for example, it's really
Sordini that answers. Far more probably it's a little copying clerk from an
entirely different department. On the other hand, it may certainly happen once
in a blue moon that when one calls up the little copying clerk Sordini will
answer himself. Then finally the best thing is to fly from the telephone
before the first sound comes through."_

~~~
danford
Franz Kafka - _The Castle_ is in the public domain and everyone should read
it. IMHO it's his best work. [http://www.24grammata.com/wp-
content/uploads/2013/07/frans_k...](http://www.24grammata.com/wp-
content/uploads/2013/07/frans_kafka_castle-24grammata.com_.pdf)

(not sure how good this translation is, was the first pdf when I googled for
it)

~~~
levosmetalo
Don't know about this link, but I read a translation of The Castle to my
native language, and it was clearly his best book ever, although it was not
finished. However, it always confused me why it didn't have more rightfully
deserved attention.

------
denibertovic
This article really hits the nail on the head. In the comments, many people
confuse layers of indirection with dependency injection. Those are 2 separate
things, you can have dependency injection and not have 100 layers of
indirection that confuse the hell out of people.

And while we're at it. Why the is there a term "Dependecy injection"... it's
freaking argument passing to functions, and it's been around a really really
long time. I'd expect this kind of crap from the JVM and other OO only worlds,
but JS is more functional then it is OO, you have higher order functions...why
the hell would you want to think in OO terms?

------
julius
For me, the most helpful feature of AngularJS is the separation of DOM and
data.

If you just want to use that feature, but you do not want all the framework
stuff, you actually can. Here is my way of doing it:
[https://github.com/julius/AngularLite](https://github.com/julius/AngularLite)

Disclaimer: I actually like the framework stuff. I just made this to use it in
an existing project (which is too big for a total conversion into the
framework structure).

------
antocv
For all the negative comments about FactoryProviderBeanCreator whatever style
of enterprise-programming: There is a point to it all.

The point is software exists mostly within its socio-economic context -
software is mostly made for people by people and will be used by people.

The SingletonProxyFactoryBean enterprise-programming tries to solve people-
problems, it tries to waddle through dependencies between libraries,
frameworks, language specifications, implementations, organizational structure
and various teams within an organization.

This angular.js enterprisy-feel tries to do the same - push responsibility
onto the others, or separate responsibility down (separation of concerns)
where nobody actually has to do anything but "configure". Or "run" it. Or just
"buy" it.

Thats the ultimate goal of enterprise and this style of programming - which
eventually leads to somebody being required to know a language on top of a
language on top of a language to adapt it to the business needs.

Its the same reason why abominations such as SAP and Microsoft Dynamics (or
basically any closed source very expensive suite of software) exist - those
products are on the altar of Enterprise, they fit well to the organization and
culture of capitalism. They fulfill the goal of "just buy it" or "just install
it" and it will do _everything_ a manager or team thinks of. So the
programmers make it so - sure the program doesnt actually do anything without
the correct set of configurations and options, but now its not an application
thats developed inhouse, its a product we buy and can get support for, kind
of.

~~~
tomp
I think there is a different point to it all: Java doesn't have first-class
functions.

In OCaml (and without doubt other programming languages as well), you can use
a function to make "objects"/"values" that you want made ("constructors"). If
you want to parametrize the function ("factory"), you just partially apply it
to some arguments. If you need to make other objects before you can make the
desired object ("dependency injection"), you pass other functions as
arguments. If you want to do something else instead of creating a new object
(e.g. "singleton pattern"), you write a different function.

It's just functions, all the way down.

~~~
antocv
Its not a Java problem as this JavaScript demonstrates.

Its not a language feature X problem.

There is something which drives people to make a factory for a dynamic and
another static language. Instead of writing the thing they want they write a
thing to give them what they want.

------
brudgers
Screw the technical merits of arguments for and against frameworks in general
or Angular.js in particular - that's not really the point. By internet
standards, it's a great article because it has an interesting topic, personal
narrative, a strong opinion, a bit of humour, consistent tone, and a
reasonable style. In the tradition of wistful paeans - the author is longing
for a more wholesome past when JavaScripts roamed unfettered by barbed wire
across a pastoral landscape of virgin DOM's [yes, intentional] and free of
proletarian factory classes.

It's entertainment not evangelism. Nobody whose work-a-day problems are
soothed by Angular will go native because of it. It's sermon about 'those
people' and the choir's Schadenfreude...and then once the act writing this
comment hit 'Schadenfreude', I had to ask myself is it a good article by HN
standards?

Empirically, probably yes. Theoretically no. The problem with Schadenfreude is
that it comes at the price of another's misfortune, and that is a route to the
meanness that both entertains the internet and harms StackOverflow. Telling
people that you are laughing at them is the hell of junior high bullying -
it's just that cool kids get paid to do Erlang and the kids in Toughskin
dungarees are getting mocked for using JavaScript boiler plate.

It dawned on me that the best HN articles are written in the spirit of mudita
- finding joy in the good fortune of others, not their misery unless our humor
is black and shares their burden.

[http://www.paulgraham.com/hackernews.html](http://www.paulgraham.com/hackernews.html)

------
zoomerang
Another case of "I don't understand something so I'm going to just say it's
too complex and stupid". The author completely misses the point of service
injection in Angular, and then goes on to offer a simpler "solution" that
doesn't even remotely do what service injection is trying to do.

Here's the thing - Inversion of Control exists for a reason. Once your
codebase gets to a certain size it becomes far, far more manageable to work
with loosely coupled components that have no direct knowledge of each other.

These abstractions are a _good_ thing. Lord knows how many projects I've had
to fix because some idiot decided that "Architecture" was just some silly
crusty of enterprise thing, and "Frameworks" are too opinionated - so instead
they decide to ignore 50 years of industry conventions and write a spaghetti
code pile of shit (But at least there are no factories!)

Whether you're using procedural, functional, or object-orientated style - A
large codebase is still going to be unmaintainable if you don't understand how
to write loosely coupled components. (More specifically, don't write a large
program - write lots of small ones and compose them together).

~~~
CHY872
You may be confusing abstraction and indirection. Of course writing large
software is hard, and of course we want to make it easier. The real question
is whether we want to do it the same way in Javascript that we did in Java,
and the answer's probably no.

Also, a large codebase can be very easily maintainable with tightly coupled
components. The only reason you would want to loosely couple them is if you
have a reasonable belief that you might want to swap out the implementation at
some point, and even then you can usually do it fairly transparently by adding
the indirection when it comes to it.

~~~
zoomerang
> Also, a large codebase can be very easily maintainable with tightly coupled
> components

Agreed, but having worked on large codebases it's usually easier to plan ahead
and decouple from the start - it can be hard to decouple components later when
you didn't plan for it. It's also much easier to properly unit test when you
can trivially inject a mock.

Of course this is only relevant if you're building a large project. The
typical web app just doesn't need it.

------
mmaldacker
This is just the same rant as the classic "Why I hate frameworks"
[http://discuss.joelonsoftware.com/?joel.3.219431.12](http://discuss.joelonsoftware.com/?joel.3.219431.12)

but applied to Javascript instead of Java.

------
marknutter
I wish a more thoughtful criticism of angular without all the vitriol was
getting up-voted to the top of HN rather than this drive-by blog post. It's
clear that anti-framework people are up-voting to validate their own world
views.

------
boobsbr
This type of writing is getting really tiresome.

"Enterprise sucks, frameworks suck, X language sucks..." You don't like, but
other people like it, get over it. Just don't use them and stop complaining
all the time.

~~~
coldtea
> _You don 't like, but other people like it, get over it. Just don't use them
> and stop complaining all the time._

Yes, it's like there's these things called "opinions" and people are posting
theirs and trying to compete for mindshare.

Instead everybody should just do whatever thing he prefers, and nobody should
attempt to convince others that this or that way is better. We are all unique
snowflakes, after all, and it's not like an industry or profession needs best
practices...

/s

~~~
slavoingilizov
Everything is an opinion. Instead of dismissing it because it is not
universal, you can think it through, take the good stuff and compare it to the
good stuff from opposing opinions. Then you find the middle ground that suits
your context best. That's how people learn - they read and study all extremes
and then make decisions. The post is very useful, even if only for making the
Angular community stop and think twice about stuff.

~~~
pessimizer
>Then you find the middle ground that suits your context best.

You've already presupposed that a middle ground would suit your context best.

------
ses
This indictment of angular and 'enterprise' frameworks is pretty one-sided and
self-righteous. I hate the bureaucratic and restrictive nature of some
frameworks too, but you can't dismiss the entirety of them and the problems
some of them solve because of it. It's very easy to criticise without
suggesting or showing any better alternative. For example... if you are a
software manager with the 'power' to choose an entire stack for a new product,
what would be your choice and how would you justify it on criteria such as:
availability of documentation, developer skillset, testing, security,
performance, platform compatibility, time to market etc?

Unfortunately all this type of 'boring' shit that enterprises deal with, they
have to deal with for a reason. If you don't like that then you have a problem
with the structure of the economy, larger businesses, and their politics as
well as the technology.

------
jebblue
Good article, I do a lot of Java coding that isn't complex at all, the stuff
he shows in the article looks like the EJB people got hold of JavaScript and
went wild. That's sad because I'm getting back into the front-end more and
finding jQuery has stood the test of time and is actually fun to use.

------
swalsh
I loved Angular when i first stumbled on it. Binding was cool... the rest of
it, i'd throw away and be really happy.

~~~
jiaweihli
You may want to take a look at knockout.js then.

~~~
slowmotiony
People tend to overlook knockout, but it really is great at what it does.

------
Cthulhu_
I think the OP and some of the people in the comments thread just don't have
the kind of experience needed to realise why Angular is the way it is. The OP
does not seem to be a JS developer, definitely not with experience in larger
applications or in larger / multiple teams working on the same codebase.
Checking his profile, all I'm seeing is short weekend projects and a small
(code size based) library; definitely not the kind of thing where using
AngularJS would help out with.

Just saying; if your only experience is small solo projects (instead of >10K
loc, team-based projects etc), then yes, AngularJS will quickly smell of
enterprise and eww, especially if based on just that one SO post from a long
time ago.

If however you've trudged through unmaintainable jQuery code, wrote >30K
multi-team BackboneJS applications, etc, then angular is a relief. It allows
you to stick to patterns, to isolate your logic, to not have an excuse to not
write unit tests anymore, and to actually write an application instead of
struggle with your framework or how your views get rendered and when.

------
ColdHawaiian
> Start thinking for yourselves, ditch this shit before it’s too late and
> learn how to write some actual fucking code. The information is out there,
> you can do it. If you need handholding with factories and providers and
> service provider factories then consider that the world doesn’t need your
> bullshit code and go and get a job you’re actually good at. Stop ruining it
> for the rest of us.

It's unfortunate that this post was written in a provocative manner with a
very inflammatory tone, because once you look past its rant-y nature, I think
it raises an interesting argument.

From what I could tell, the gist of the post seems to be that instead of
relying on someone else's pre-made, out-of-the-box general framework solution
(which you have to heavily configure to your specific needs, and is so
complicated that you end up needing to hire highly trained consultants), you
can create simpler, more elegant solutions simply by writing them yourself
from scratch.

I'm not going to agree nor disagree with that argument, I'm only trying to
state what I think the gist of it is.

------
epayne
Thank you Rob. Although there are perhaps some things to nit-pick about your
post, I think you have expressed something important about recent changes
(last 5 years) to attitudes in the JS community.

------
rquantz
This is silly. It basically amounts to "waaaah I don't know angular!" because
they saw funny words I a stack overflow example.

Factories etc., in angular are not the same as the Java equivalents. And
you're usually not going to be using providerProviders in your application
code, that stuff goes in libraries that, yes, need to be configurable.

Angular is a boon for writing testable, changeable javascript apps. Just
because one of the features happens to use words you don't like in java
doesn't mean JavaScript is ruined.

~~~
heidar
I don't think unit tests should dominate the architecture of your
applications. I hear this a lot from the angularjs crowd.

I also disagree with architecturing your applications for things that might
need to be changed in the future (but probably won't). That is something from
enterprise and Java world and a lot of people including myself dislike it. I
know people who love it though and that's fine, as long as I don't have to
work with them. :)

~~~
rquantz
Yes, most of the code will never change. But some of it will, and it's
sometimes hard to predict what that will be. So, to an extent, all of your
code needs to be written so it's changeable in the future. It doesn't have to
be enterprise java style to be flexible -- just well encapsulated, and
testable code helps with that.

Also, it seems like people in this thread who haven't used angular see that
word -- factory -- and think of endless crappy java abstractions. You are
overestimating the overhead that angular is bringing into your application in
this case. A factory is just a component that can be shared between
controllers. It's a singleton, like a lot of sharable components in vanilla
Javascript applications, just with a defined way of being injected into the
controller, and a way of declaring dependencies.

If your problem is with object oriented programming in general well... I can't
help you there.

------
joekrill
This is just plain absurd. We are not in a one-size-fits-all industry. Far
from it. Just because you don't quite understand the benefit of a very
specific framework (that, incidentally, you know virtually nothing about) does
NOT mean it is not useful, or that it has "ruined" anything. We pick the best
tools for the job. In some cases that actually IS Angular. In many cases, it
is not. But to make broad generalizations like this does nothing but show a
lack of understanding.

------
ulisesrmzroche
When was the last time ya'll went 'hell yeah' when you saw the team you joined
was a) was not using a framework or b) built their own?

You're just begging to be swirlied, my dudes.

------
sklivvz1971
It's not the language, it's the people... Most developers are... not very
good. It's a fact of life. Abstractions are a phase in learning how to code: I
am not surprised that people reinvent the wheel in [insert-currently-trendy-
platform].

I am surprised that people think that a LANGUAGE can make any difference.
Languages are tools, stop pretending they make any difference and fix the
people :-)

~~~
CHY872
No. The purpose of a programming language is to remove the incidental
complexity leaving only the intrinsic complexity of the task. All languages
have the same expressive power in principle, but it is intrinsically easier to
perform certain tasks in certain languages.

------
facorreia
For the application I'm developing I've decided to keep it simple. Instead of
relying on a complex framework with a lot of abstract concepts and layers, I'm
using jQuery Mobile, Riot.js events and Handlebars templates. The actual
application code is plain old JavaScript and I can actually understand what's
going on at any given time.

------
colemorrison
Angular can be confusing, but the speed of development you can achieve with it
has helped give me back many hours of my life.

~~~
rbanffy
Caution: do not underestimate the problem the extra complexity added creates.

------
nakovet
This post just remembered me of this question:
[http://stackoverflow.com/questions/245062/whats-the-
differen...](http://stackoverflow.com/questions/245062/whats-the-difference-
between-javascript-and-java)

------
taude
The OP got a two-fer: mixing the arguments for/against Angular and the
arguments for/against JavaScript frameworks in general. I think they are
separate conversations, which is evident below (or above) depending on which
threads your read.

------
Zelphyr
Came here expecting to be annoyed at yet another post suggesting we use yet
another framework. Pleased to see to see a reasonably cogent (if not a little
overly antagonistic) example of why all these frameworks are crap.

------
outside1234
One word: Ember.js

I can't for the life of me understand the popularity of Angular.js.

------
CmonDev
It's like a decorative tuning of a broken car. But it was already broken to
begin with. The problem is that everyone is too familiar with how to drive
that specific brand of broken cars.

~~~
VMG
If you actually read TFA it's more like using an airplane as tractor.

~~~
fnordfnordfnord
You might find this amusing.
[http://www.airtractor.com/](http://www.airtractor.com/)

------
KhalPanda
Sorry, you only get 9/10 from me, not enough swearing.

------
kuchaguangjie
Jquery & extjs is just enough, things like Angular are too complex and
abstract, make programming no fun any more.

------
inglor
What's the fuss? JavaScript attracts people who complain about solutions to
problems they don't understand

------
weavie
Factories are singletons. Services are not. Providers let you configure stuff
before they are invoked.

~~~
camus2
are you sure? i thought the 3 apis provider/factory/service return only one
instance per application.

~~~
weavie
Darn it, you are right. Not sure how I'd come to that conclusion. Thanks for
putting me straight.

------
jimejim
Can we all just agree that premature patterns is similar to premature
optimization and move on?

------
ilaksh
If you think AngularJS is too complicated, I agree. Check out Polymer and web
components.

------
justinhj
This web page is one of those that is just unreadable on mobile.

------
flyworldhan
I totally understand the point. You only need to do is choose the right
'framework' for your work. Dont make it angryler.js

------
ff_
The only thing I'm able to say after this piece is: "WOW."

------
michaelochurch
I've come to the conclusion that this non-programming programmer "design
pattern" fad is a way of obfuscating mathematical and computational concepts
while making them no less hard (as we see by them often being poorly used) but
seem less hard (and, paradoxically, more intelligent due to buzzword
compliance) to the businessmen who, because of programmers' weak professional
identity, call the shots.

Curried function? Too mathematical. Let's call it a _Factory_.

Tree-walking algorithm? Let's call it a _Visitor_.

Sinusoidal curve? Again, too mathy. Let's call it the _Vibrator_ pattern.

Lots of words get spilled, mediocre employees remain employed, good people
leave or get fired while trying to fight the current of stupidity, and nothing
gets done. Brilliant! Now, you can go a step further by creating a system to
monitor those mediocre employees, making them basically employable while
bringing down the top, and call it "Agile" when it's the exact opposite of
agility.

~~~
Dewie
For all the talk of _abstraction_ by so many programmers, I wonder how many of
us just really want _metaphors_. Ways of organizing and relating to code that
are at least vaguely familiar.

But then some programmers start talking about abstract math and category
theory, and many people recoil because it is _too_ abstract, or because it is
so abstract that it is more general than the most immediately obvious
_metaphor_ ( _Functors are kind of like boxes, but not always. You should
think of them like computational contexts instead_ ).

Of course metaphors have their place; there is no need in making things less
relatable just because. But at some point you may have to abandon the comfort
zone of trucks being a specialization of a more general car blueprint.

~~~
brudgers
I think it's more concrete. FactoryProviderProviderProviders provide a common
set of procedures for programmers to provide programs [sorry, second cup of
coffee]. All that framework makes the landscape familiar and allows the
procedures which worked for generating Java code to work when a person wants
to generate JavaScript. It provides space for algorithms for writing programs.

The tradeoff is that it will never be done in a way that optimizes on logical
insight. Simple currying would be simpler but the boss still might not
understand it, and it's better culturally if the boss doesn't understand sixty
lines of boiler plate than twelve lines of mathematical reasoning.

The advantage is that the programmer can know, if I do these things I will get
close to the result without worrying over much about the degree to which I
might lack deep understanding. On HN there are plenty of people comfortable
with the idea of factories as curried dispatch constructors. But that's not
the typical case.

~~~
kyllo
_Simple currying would be simpler but the boss still might not understand it,
and it 's better culturally if the boss doesn't understand sixty lines of
boiler plate than twelve lines of mathematical reasoning._

That's the whole problem, the notion that "the boss" needs to understand how
the code works. OOP patterns are designed to "model" real-world business
objects and processes so that they can be documented on a UML diagram that
business analysts and managers can look at to grasp how the software works
without having to understand how computers work. This is a big reason why the
software gets unnecessarily complex--the real world is infinitely complex.

Most of the time, what you actually need the software to _do_ is not nearly as
complex, though, so it would be better to just write simpler code that _does
the thing that needs doing_ rather than _models all the things_. But in that
case it's harder for the non-technical boss to understand the logic without a
handy metaphor.

The layer of abstraction that seems to be most frequently violated in
enterprise contexts, is the software developer's job itself.

~~~
brudgers
For whom is the idea that the boss needs to understand the program a problem
and why?

The typical answer is for programmers and because then the boss might have
specific technical input rather than requirements and under bad management
that could be a problem - i.e. keeping the boss from understanding the code is
a defence to mitigate bad management which has the added benefit of UML
diagrams a likely first place for a bad manager to cut costs.

Much of the last 40 years has seen software engineers exchanging the human
parsablility of Cobol for the utter impenetrability of regex's - culminating
in Perl which was so impenetrable to even programmers that Java had to be
invented. Anyway, the idea that a computer language should allow an
intelligent lay person to follow an algorithm written in it died with Cobol.
It - the idea not Cobol - might be worth revisiting in language design.

Of course the idea I was trying to express is that the boss will feel better
at not understanding 60 lines of boilerplate javascript than not understanding
a dozen lines of elegant Haskell.

~~~
kyllo
It's bad for everyone involved because the programmer loses the ability to
make decisions about how to structure the program he/she is working on, and
the manager and/or business analyst waste lots of time worrying about
intricate technical details of someone else's job, when they should be tending
to their own responsibilities. It's a violation of separation of concerns and
a disrespect for the software developer's domain expertise.

The trend I have seen in enterprise software is that, because good software
developers are expensive and in high demand, the business attempts to
commoditize them by having lower paid, semi-technical staff (like business
analysts) do everything except for write the actual code, limiting the
developer's job description to simply translating a diagram and a list of
features and business rules into Java--like some sort of human compiler.

That approach is doomed to produce terrible software forever, because you
can't write good software without thinking deeply and understanding both the
problem to be solved and the tools available to solve it. And you just can't
commoditize a job that requires that much thinking.

On the other hand, I do agree that software development needs to be made
easier than it currently is. It is currently very hard because the current
tools we have are built on layers upon layers of leaky abstractions that still
require a highly trained and experienced individual to understand first, in
order to be productive. Making programming languages more easily
comprehensible to humans, is a big part of that. Programming languages are for
humans, after all.

------
guard-of-terra
I still write inline javascript blocks in my internal /admin service. Who
wants to touch me?

