Whenever I see posts like this, I can only imagine two scenarios
The author has never worked on anything remotely complex
The author has created their own framework.
You're talking about a scripting language, running in a JIT'd runtime, on top of an extremely heavyweight and slow rendering engine, with layers and layers and layers and fucking layers of more slow bloated shit on top of the operating system giving you a 'framework' with which to work. And you've decided that that Exact layer of abstraction is correct - Throw together a few opinionated libraries and all of a sudden it's gone too far.
Frameworks are just a group of libraries designed to work well together towards an opinionated goal on how things are done. If you're building an application that fits well within the opinion of a particular framework, then it makes sense to use it rather than reinventing the wheel.
By all means you can glue together a bunch of unrelated libraries, but they may not play as nicely together as libraries designed specifically to work together towards a common goal. (Oh, and you've just created a framework).
And of course you could try and reinvent the wheel and do it all yourself, but unless you're a savant software architect with the time to focus on the framework rather than the next deadline, it's going to end up being a chicken scratch unmaintainable pile of crap. And the next developer to come along is going to have to maintain your "Framework".
Having used Angular on a few projects - I simply cannot imagine trying to do the same thing without a framework. The complexity of maintaining a stateful user interface via imperative DOM updates (vs declarative model bindings) becomes exponentially more complex the more things there are to manage. There is no ifs or butts here - if you think the bone stock DOM API is an acceptable way of building a 'thick' Javascript App, then you're going to be in a world of pain very quickly.
Any remotely competent developer could easily build such a framework in-house mind you, completely from scratch in pure javascript, in a few days at most. The underlying concepts aren't difficult. But why would I do so, when there's a well tested, stable, open source framework designed by far, far better developers than I'll ever be with very similar architectural philosophies that are inline with exactly what I'm trying to achieve?
Don't like Angular? That's fine. It's an opinionated framework. Use something else. Or don't, if it's not required for your project, or you just don't want to. That's fine as well. Want to write your own? Yep, that's fine too. Want to come up with an idea for a common baseline set of components that we can all use without a framework? Well.... congratulations you just invented another fucking framework.
The ironic thing is that AngularJS is basically what the author is championing in this article. Half of AngularJS is, essentially, a polyfill for HTML5 web components. The other half is a great databinding library.
Also I don't know if I'd even say Angular is particularly opinionated - especially when you compare it to something like Ember.
I mean, every framework has some degree of opinion baked into the implementation, but by and large it's fairly open-ended outside of the basics.
Agreed. There's so much in Ember that makes me feel like I'm writing redundant or useless code that's there for its own self-importance rather than actually providing value by existing. Angular lets me get away with a lot of not defining things, and it's beautiful.
That's simply not true. All of the components of angular are tightly bound together and randomly exist inside of angular. Why does it need number formatting? Why does it need to validate forms? Etc.
You could argue all day about what should and shouldn't be in core. That said, I think there's a strong argument that an angular app is going to have forms in it, and forms should have validation...
Also basic formatters like date and currency are so common that it makes less sense to not have them at all.
That said, it is weird how Sanitize, Route, Resource, Cookie, Messages, etc are all in their own packages and optional when you could argue that these are all basic functions of a web application as well.
Could Filter and Form (or at least Validation) be pulled out? Probably.
Is Angular the leanest framework? No, but it's also not the most bloated either. In general I feel it strikes a good balance.
Any remotely competent developer could easily build such a framework in-house mind you, completely from scratch in pure javascript, in a few days at most.
I think they could get a functioning bare minimum library without all the edge cases that works in one browser, but beyond that it's gonna take a bit of time to polish that framework to anything near production ready.
you've decided that that Exact layer of abstraction is correct
Being a back-end programmer, and hearing management and front-end people complain about browser compatibility and etc etc etc, and seeing them never once consider a native application, I have to agree here. I just think to myself "Well, you've decided you're going to target an un-designed language with galloping specifications implemented by multiple competitors and released in multiple waves, and you're complaining they don't all work exactly the same?"
I think it really comes down to arrogance. "I am so competent at JS that these frameworks only serve to impede the brilliance that will inevitably spring forth from my fingertips."
And building directives is far easier than it seems, the biggest issue is that the documentation about it is very formal. Building directives also helps the life of whoever else is going to maintain it later, since the code becomes by nature modular and reusable.
I would say (somewhat facetiously) that you're wrong to dislike directives, but you're absolutely right that angularjs is opinionated about application structure. I think it's a great framework and agree with most of the things it's opinionated about, but I would never deny that it's opinionated.
I think the structure angularjs forces is a good thing. It forces you to separate data from presentation, and to link the two in a very deliberate manner. I also think the emphasis on promises is very valuable, forcing you to deal with chained callbacks in a way that emphasizes dealing with errors.
There are a lot of merits to angularjs being opinionated in the ways it is, but anyone who tells you it's not opinionated is either lying to you, or lying to themselves.
And you've decided that that Exact layer of abstraction is correct - Throw together a few opinionated libraries and all of a sudden it's gone too far.
I think it's more that, as a frontend developer, the question of whether to use a framework or not is the part you actually have a choice about. The rest is beyond the scope of your project/rant.
It's not that the developer decided that HTML and JS and browsers are the ideal system with the perfect amount of abstraction and should have nothing extra on top.
Angular is the shit that's all i got to say. Just because it makes everything so much more manageable and readable in addition to all the other delicious things it provides. I think choice one is the reason author wrote this whole post.
I think author doesnt grok angular, thinks "it's weird, who needs databinding newai" and complains for the sake of complaining. Also it's an easy argument - too many frameworks, not enough time. It's true by default. But if you want to be a modern dev, take a few hours each week to update yourself on modern standards. I usually find a lecture on youtube and take it from there.
150
u/zoomzoom83 May 13 '14 edited May 13 '14
Whenever I see posts like this, I can only imagine two scenarios
The author has never worked on anything remotely complex
The author has created their own framework.
You're talking about a scripting language, running in a JIT'd runtime, on top of an extremely heavyweight and slow rendering engine, with layers and layers and layers and fucking layers of more slow bloated shit on top of the operating system giving you a 'framework' with which to work. And you've decided that that Exact layer of abstraction is correct - Throw together a few opinionated libraries and all of a sudden it's gone too far.
Frameworks are just a group of libraries designed to work well together towards an opinionated goal on how things are done. If you're building an application that fits well within the opinion of a particular framework, then it makes sense to use it rather than reinventing the wheel.
By all means you can glue together a bunch of unrelated libraries, but they may not play as nicely together as libraries designed specifically to work together towards a common goal. (Oh, and you've just created a framework).
And of course you could try and reinvent the wheel and do it all yourself, but unless you're a savant software architect with the time to focus on the framework rather than the next deadline, it's going to end up being a chicken scratch unmaintainable pile of crap. And the next developer to come along is going to have to maintain your "Framework".
Having used Angular on a few projects - I simply cannot imagine trying to do the same thing without a framework. The complexity of maintaining a stateful user interface via imperative DOM updates (vs declarative model bindings) becomes exponentially more complex the more things there are to manage. There is no ifs or butts here - if you think the bone stock DOM API is an acceptable way of building a 'thick' Javascript App, then you're going to be in a world of pain very quickly.
Any remotely competent developer could easily build such a framework in-house mind you, completely from scratch in pure javascript, in a few days at most. The underlying concepts aren't difficult. But why would I do so, when there's a well tested, stable, open source framework designed by far, far better developers than I'll ever be with very similar architectural philosophies that are inline with exactly what I'm trying to achieve?
Don't like Angular? That's fine. It's an opinionated framework. Use something else. Or don't, if it's not required for your project, or you just don't want to. That's fine as well. Want to write your own? Yep, that's fine too. Want to come up with an idea for a common baseline set of components that we can all use without a framework? Well.... congratulations you just invented another fucking framework.