I don't really follow many of the author's objections. I think he or she left out a lot of reasoning.
"This code reminds me of a simple server-side scripting language such as JSP or ASP that’s used to fill HTML templates with database content. These languages have their place in the web development stack — but on the server, not in the browser."
Says who? What's the rationale for where a language belongs?
"Although templating is the correct solution, doing it in the browser is fundamentally wrong. The cost of application maintenance should not be offloaded onto all their users’s browsers (we’re talking millions of hits per month here) — especially not the mobile ones. This job belongs on the server."
Again, based on what?
"My point is that I expected far more front-enders to embrace Angular. I have the feeling their number is surprisingly low — see also the problems my clients had with finding good front-end Angular consultants. "
More stuff based on feeling rather than empirical evidence. And clients have trouble finding good front-end developers these days no matter what the technology is.
"A more important reason may be pushback from the JavaScript community. Angular has evoked some serious criticism."
Find me a framework that hasn't evoked serious criticism from some corner of the Internet.
Look, I'm no fan of Angular. In fact I've never written a thing in it. It doesn't really fit my style of front-end development (and I'm a Java programmer!). I'm more of a libraries-over-frameworks guy. But this article is not very well-reasoned.
Just thought I'd add a bit of meta context: PPK (the author of the article) is perhaps the first person in the js community to catalogue detailed per-feature cross-browser compatibility tables. You could say he's one of the old timers.
PPK has a very strong background in cross browser testing and high level technology evaluation for non-techie audiences, but (from my impression of reading this article, at least), it doesn't seem like he has much experience w/ Angular per se and sounds like he is writing his opinions more based on blogosphere echo than personal time spent with the framework (clue: lack of Angular-specific terminology criticism)
Some of the criticism is valid, I think: hiring "Angular" devs is hard, partly because of the over-engineered-Java-like feel. I've seen a few times overconfident frontenders think they could pick up Angular through Google-Fu just as they picked up jQuery, and then hitting a brick wall face first, with a looming deadline to add insult to the injury. The reality is that a lot of people (especially frontend people) don't have the CS foundation to understand why and when the design patterns prevalent in Angular/Java are useful (or even what patterns exist to begin with).
@jasonwocky The snippets you highlighted do seem a bit like a "get-off-my-lawn" reaction from the author. SPA architectures certainly have their places, and it does feel like the author hasn't had experience w/ building heavily dynamic UI apps.
>> Find me a framework that hasn't evoked serious criticism from some corner of the Internet.
I think the point is that Angular criticism is much more prominent (and sometimes vitriolic) than other frameworks.
> The reality is that a lot of people (especially frontend people) don't have the CS foundation to understand why and when the design patterns prevalent in Angular/Java are useful (or even what patterns exist to begin with).
That's hardly fair. Design patterns are not that difficult conceptually and in my (admittedly limited) experience Angular doesn't really introduce anything new. It's not hard to pick up because devs are lacking foundational skills. It's hard to pick up because it's overcomplex and difficult to adopt in pieces. Despite claims that it's easy to "add as much or as little of AngularJS to an existing page as you like", there seem to be no examples of piecemeal adoption in the docs. I'm sure someone with Angular experience could plug in a bit of Angular to an existing app, but someone just starting apparently has to choose to 1) go all in, 2) spend a lot of time learning Angular, or 3) use something else. If many competent devs are "hitting a brick wall face first", that seems to be indicative of problems with the framework.
Also, this is somewhat tangential, but I'm not sure software design patterns are part of computer science anyway. They belong to software engineering, which is really not the same thing.
> in my (admittedly limited) experience Angular doesn't really introduce anything new
If one's coding experience is limited to jQuery et al, it does introduce a lot and very fast: you can't really get very far in Angular before stumbling upon IoC and services/factories, for starters. Just look at the comments for any article that talks about Angular service/factory/provider/etc to see that even the most basics of patterns are not exactly universal knowledge.
A lot of the complexity you talk about originates from other patterns. More advanced tools like parsers/formatters, interceptors, decorators are there specifically to be alternatives to procedural spaghetti code and it's hard for a lot of people to even guess that these tools exist, let alone figure out why they should (or not) use them.
To be fair, it's true that a lot of complexity is very much Angular's fault and not a lack of preparedness from developers (the directives API and the digest system come to mind).
But my point was that it's hard to find Angular devs. Around where I live, a typical non-angular frontend job pays between 60-70k (generous extrapolation from salaries of people I know) and might involve a job interview that talks about responsive design. An Angular job easily pays 90k-110k (from job interviews I've been to) and might have a job interview that talks about algorithms. Even though both are considered "frontend" jobs, the former is more likely to be filled by a self-taught person that reads html5rocks or whatever, while the latter is more likely to be filled by someone w/ a CS degree and backend experience (which, here, usually means either Java or .NET). I think we can agree that the skill sets for the two jobs don't overlap much, and the dissonance in qualifications is not merely because of the level of complexity in a tool.
> Also, this is somewhat tangential, but I'm not sure software design patterns are part of computer science
If we're going to be nitpicky and pedantic, I said knowing when and why to use them is part of a CS foundation. s/CS/software engineering/, as long you get the main idea.
My impression of Angular is that it makes simple things complex and that it's poorly designed and engineered. I think that it tries to do too much, and tries to be too clever, and doesn't try at all to be usable (beyond maybe trivial examples, which could still be simpler, honestly). It speaks very poorly of Angular that many (most?) people familiar with all the tools it builds on (CSS, HTML, JS) find it difficult and unpleasant to work with.
It may be the case that only people with deeper engineering experience can wrangle it because they have the necessary background. It could also be that people who are used to working with friendlier tools just aren't willing to put up with Angular's crap.
I didn't realize Mithril was yours. Seems nice, though I haven't used it myself.
The stuff you wrote is valid. I'm just not sure that dev ability is the major factor making it harder to hire Angular devs. Maybe I'm wrong. I'm thankfully not hiring Angular devs.
> The reality is that a lot of people (especially frontend people) don't have the CS foundation to understand why and when the design patterns prevalent in Angular/Java are useful (or even what patterns exist to begin with).
We're calling design patterns prevalent in Angular/Java "Computer Science"?
I'm not even sure they're worthy of the original terminology design patterns, and there's a pretty strong argument they're not foundational computer science at all (you can really see this by working in several different language paradigms and seeing how some problems patterns solve in some languages fall out without the pattern in others). They're aspects of industrial practice and a subset of software engineering. This isn't to say they're not useful (and some more broadly than others), but their usefulness arises in the context of the tools applied and concerns/constraints present rather than CS fundamentals.
And one doesn't have to be a jQuery hack to think that the concerns involved in dynamic single-page apps don't necessarily imply the utility of all Angular's abstractions (as I'm sure many devs who've embraced other front-end frameworks would agree).
Usually, when you detect a pattern in your design, you want to abstract it away. Design patterns are basically just data structures that nobody has really bothered to properly implement with full generality.
> @jasonwocky The snippets you highlighted do seem a bit like a "get-off-my-lawn" reaction from the author. SPA architectures certainly have their places, and it does feel like the author hasn't had experience w/ building heavily dynamic UI apps.
> The snippets you highlighted do seem a bit like a "get-off-my-lawn" reaction from the author.
New and shiny ways are not always the best. I'm still not seeing people writing kernels and device drivers in JavaScript.
> SPA architectures certainly have their places
And what areas those might be and why?
You can build heavily dynamic apps without trying to do everything in the browser.
Problem with the web nowadays is that a lot of decisions are being made for political reasons rather UX considerations. SPA architectures are appealing to front-end developers who just can't be bothered to learn how to do routing and templating on the backend or they just want to have those things in their territory.
For me UX matters more than shiny architecture. I did the experiment in Chrome where I had HTML and applied some stylings to it via the raw DOM API as soon as possible. There was a noticeable delay before the stylings got applied and this was the highly optimized DOM code with no Angular, no jQuery, no nothing. The moral of the story is: browsers are still faster at displaying HTML and CSS.
Aside from the performance failures, Angular has huge problems when it comes to writing maintainable Angular code like the scope hell, but you can find many others here: http://ihateangular.com/
I've been writing Angular on Rails for the last year. We took a bag of jQuery code which manipulated DOM for a complex single-page app. We threw that all away and replaced it with 90% less Angular code. It felt (not to trot out a stale trope) like magic and we never looked back.
It was clear to us from day one that performance would be an area of concern, as well as the overall complexity of the framework. But those can be addressed. I don't agree that using another framework would magically prevent developers from thinking about performance issues. And many modules of angular we just don't use, and it doesn't impose those on us.
On a regular basis we re-evaluate alternatives: React, knockout, backbone, and so on. I expect those might involve tradeoffs that end up being positive or neutral for us, even it just forces a re-thinking of the app architecture. But this article doesn't make any recommendation or even mention the initial problem of rich, single-page apps that create user interactivity without page reloads. And the painting of the framework as Java and Enterprise do not match our experience or use case. I'm the first in line for recommendations on how we can improve what we do, but my impression is his bias is throw away frameworks and bring back our mass of raw javascript.
I did something similar with a couple of my projects. Our apps had a soup of Jquery, Backbone, Backbone Marionette and a bunch of other libraries, and while we didn't get 90% less code (more like 70-75%), I feel it was a worthwhile migration. The overall structure of our code base is simpler.
Angular does have its annoyances and compromises, and in some areas, it's kind of a pig (i.e., ng-repeat).
Our projects aren't massive in scope (they're targeted towards small enterprise implementations), however, so I don't think Angular's limitations will really hit us hard except in certain use cases.
I think besides ng-repeat, angular is pretty much like any other two-way template binding framework. I don't know why it's really considered so radically different and special.
It's when you get controllers such as ng-repeat that Angular's digest cycle makes some difference. But ultimately you could write a component like ng-repeat yourself. As for where you place the directives -- the tag name or attributes, inside the class -- who cares? Only the {{}} in the text nodes matters strongly.
As for alternatives, check out http://platform.qbix.com . It is compatible with angular, ember, jquery etc. But it is much more straightforward, like react. You only have two concepts - pages and tools (components). And you can not only re-use a whole lot of tools from a marketplace but they all can work with a standard opensource platform of user accounts, realtime streams of data, which can distribute the social layer the same way bitcoin distributes money and contracts.
Agreed, even ng-repeat has equivalents in each framework. Migrating from direct DOM manipulation is a no-brainer, but I wouldn't count it as an advantage of Angular over the other choices.
Ending up with a code base which is 10% of the size of the original is a massive improvement, can you share some examples of what the code was doing before? Even cutting down by 50% would be impressive.
Not to discount the value added in this case, but remember that the report is possibly biased in the same way that many "We rewrote it and now its 10x as awesome as it was before!" reports are. Rewrites almost always tend to result in higher quality code, regardless of what the rewrite is to or from.
Currently wrapping up my first commercial AngularJS project - I was outsourced by a client.
Prior to this contract I had no experience with it, now I've been using it nearly every day for the past month and a half, have run through the tutorials and implemented it on a side project of mine.
All that said, I will be stripping Angular out of my side project. It is something I am glad I learned for clients that demand it, but I wouldn't recommend it.
IMO Backbone with underscore templates are much cleaner and seem to perform much faster for my needs (no benchmarks performed on my end, but as a user my site certainly felt snappier prior to implementing Angular).
"Says who? What's the rationale for where a language belongs?"
From the article:
"Unfortunately they aren’t trained to recognise Angular’s performance problems."
...
"The problem is that there is no way for Angular to discover these instructions except by parsing the entire DOM, including all text nodes and attribute values — a very expensive process if there ever was one, especially on mobile."
The author is arguing that it is bad for performance.
if Angular is truly dropping the template into the DOM and then parsing the DOM, Angular is doing something terribly wrong. Underscore (for example) parses templates that look very similar to this by parsing the template as a string (not as DOM nodes). If it's crucial to parse the content as nodes, the top element (or a wrapper) can be constructed outside of the DOM itself and parsed as nodes outside the DOM tree. I haven't looked into how Angular does this parsing but I would be very surprised if this complaint is accurate.
Hold on there, cowboy. The innate superiority of strings over DOM based templating is not universally accepted. Because it's not unequivocally proven.
In fact, a few years ago there was an obvious tide toward experimenting with alternatives to string based templating noticeable in several some high profile efforts in the client side templating space.
Most templates will typically live in separate files and be loaded and compiled when needed, of course - so not so much of a performance hit up front. But Angular still needs to know where to dump the stuff, so it needs to parse the DOM to find a node with the ng-app directive.
Also, I'm not aware of anything like handlebars's offline pre-compilation for Angular, although such a thing may well exist. There's a lot of stuff in there...
I agree, I wish the author brought reasoning to those points. I do think that it is a little odd of us to push more & more processing to the user's device, rather than doing it ourselves and purely delivering content. However, it does seem to have a net positive on server reliability, and the perceived performance & responsiveness of the apps.
It makes business sense: server cpu cycles you have to pay for, client ones you don't. (If the client is fast enough not to notice -- if not, of course, you could lose customers).
"If the client is fast enough not to notice -- if not, of course, you could lose customers"
This.
I honestly think most front end devs don't test with anything except a fast PC (or Mac). They sure don't test with last year's phones. Web pages are getting more and more sluggish (generally speaking) all the time.
It's one thing to always want to work with new technology, but devs really need to spend some time in their customers' shoes.
I've been pushing this strategy for years. It makes more and more sense to have the clients- which include phones- do the processing. They have an excess of power. And more importantly, once the app is downloaded network lag is not as big a factor (it still is, of course, for any ajax-based stuff- but we minimize this).
> "Although templating is the correct solution, doing it in the browser is fundamentally wrong. The cost of application maintenance should not be offloaded onto all their users’s browsers (we’re talking millions of hits per month here) — especially not the mobile ones. This job belongs on the server."
Agreed. I'd go even further: presentation logic, including templating, is the job of the browser. The server is the database. And I include "mobile" front-ends in this, which do all not equate to "low-powered" these days.
This is basically a +1 reply but I feel strongly about this point and wish to add my own rant.
This persistent idea that one should compile templates on the server is so mindbogglingly inefficient - compared to delegating to clients whose computing power is idling 99% of the time. Not to mention separation of UI from the core functionality and other benefits.
JS in browsers is incredibly fast nowadays. I can't remember the last time I ran into performance issues. Angular my not be the most efficient but it's a stepping stone in the direction of client-side apps + RESTful APIs which I think will be the rule rather than exception in the future.
Lots of features are in the pipeline which will make client-side apps even faster and more elegant (shadow DOM, Object.observer).
> This persistent idea that one should compile templates on the server is so mindbogglingly inefficient - compared to delegating to clients whose computing power is idling 99% of the time.
s/idling/conserving battery life/
much of the original article's criticism was aimed at angular apps on mobile devices.
Hi. So you're responsible for the increased battery usage on my mobile device. Please stop. Also, can you please test your code on a device that came out _last_ year? You know, so that you can make sure it's not sluggish and frustrating to use.
It is indeed stupid and wasteful to deliver 40 KB of framework and 8 KB of templates and 14 KB of data and 20 KB of business logic and 15 KB of CSS to the client and then make the client do all the rest of the work to "make page happen"--especially on an open platform with so few reliable guarantees about the client's capabilities and resources.
But to say templating is only the job of the server is equally myopic. Web applications--high functionality, low content (as opposed to web sites--low functionality, high content) have struggled with the limitations of the static, stateless document paradigm for years and is the real use-case for client side templating as an answer to one of the many resulting challenges.
When a page is highly dynamic in response to interaction, it is equally stupid and wasteful to perform full page refreshes. Request, server compile, download, flow, paint. Bad. Slow, discontinuous.
Someone else mentioned UX being ignored in the quest for client side templates: no, wrong. Client side templates are at least 50% about UX. We have a DOM already there, let's use it. But that is also exactly the problem with the all-client mode: it delivers something several extra steps removed from being a useful (to the user) DOM when it could do otherwise and when doing otherwise would result in a better and more universally performant user experience.
Right now, truly smart isomorphic templates are what we need. (But, then again, by the time we get them, we probably won't need them--because the goalposts will have shifted and/or we'll have a better answer.)
37signals (now Basecamp) should have a post or two about how they made a new version of the product fast. One of the points was bringing templates back to the server, iirc.
It is usually the loading of many resources (js etc) that takes time. If you just send some html (and css) to the browser it can show it quickly. But companies like Facebook and Airbnb are starting to send html first and then use javascript for everything. This makes the first pageview very fast while still keeping the flexibility and other good parts of a SPA system.
The author is fine with other browser side rendering tools. The issue is the need to needlessly render templates client side by parsing out the DOM each time. There is no need for this, and doing it is pointless. Better to have the template render in a state where you don't need to do the dance that Angular does. This consumes a lot of CPU, and a lot of battery life. This impacts performance and user experience.
Ditto - I also dislike Angular, am aware of the author's background and initially upvoted - but further reading shows this is a generic disagreement with browser-side rendering with 'Angular' thrown in for linkbait. Flagged.
You haven't actually read the post you're replying to. I do actually agree with the articles conclusion, but It has a misleading headline and my understanding is that this is exactly what flags are for.
I usually have a terrible UX with Angular websites, I don't know if the problem is Angular itself or the developers, but these are some of the problems I usually experience:
-No HTML hyperlinks. This means that I can not open pages in new tabs, which it's very frustrating.
-Slow loading times. Static websites are much faster. Even non-cached server-side dynamically generated websites are faster.
-High CPU usage. To be fare my computer (1.4ghz c2s) is almost 5 years old, but using 100% to render a very simple "About us" page is ridiculous.
-Broken style when using some add-ons. This _only_ happens with Angular.
That's bad any way you slice it, and unnecessary. Angular doesn't encourage failing to make a site accessible (Unless your accessibility requirements include "JavaScript off" for some reason)
>> -Slow loading times
I'd believe that. Angular not only is a big library by itself, it encourages putting lots of behavior client-side. That's good if you want a dynamic site, but it can be memory- and bandwidth-intense.
>> High CPU usage
That's not a requirement of Angular, but since Angular's core pattern for presentation is two-way data binding and aggressive synchronization of those bindings, it's easy to fall into a performance trap if one isn't profiling often.
>> Broken style
I'm 100% certain that it doesn't only happen with Angular (unless you can share what plugins in particular you've had trouble with). But I can think of one aspect of Angular's design that could exacerbate this sort of issue: Angular uses non-standard (but standards-compliant) HTML tags and then replaces or augments those tags with browser-consumable tags using the directive pattern. For example, if I have a toolbar that is actually a set of divs, spans, buttons, etc., I can build a directive that injects that toolbar into the HTML and declare an injection site with
<my-toolbar arg1="my custom arg" arg2="another custom arg">... etc.
If a plugin assumes (foolishly ;) ) that it knows the full set of tags that can appear in a valid HTML document, it would be more likely to fail on an Angular-targeted doc, because Angular embraces this pattern as a core tool.
An example that irritates me to no end is the Playstation store.
Opening links in a new tab/window means reloading the entire store app, usually taking at least 15 seconds.
Likely this slow load is due to the broad scope of the app. I’ve found Angular works very well for medium sized apps, but isn't it aimed at solving the massive complexity and spaghetti code of larger applications?
I’ve found that many fringe devices cannot render many Angular apps in their browsers. This includes many current/previous generation game consoles (3DS, Wii U, PS3), less capable tablets, etc. I'm not sure whether its the browsers lacking certain Javascript language features, but its irritating for a "mobile" friendly framework to not work across a broad spectrum of devices.
No HTML hyperlinks is an annoyance, especially since part of Angular is being in the DOM, but that is something that can be handled, the lazy method is to just not do it. I guess that is something I like in a framework or library, that the laziest method it promotes does the most work by default.
The point of a framework though is to remove the boilerplate, best-practices should be part of a front end frame work's default settings. The problem with Angular's popularity is that it's often used for bad purposes (including in their own guide as an e-commerce tutorial). Angular's strengths, solely IMO, play up to large single page apps comprised of many small angular apps, apps that don't use hyperlinks and aren't driven by sharing or SEO.
There's a lot of weird choices in Angular, but it's not broken though, and enterprise will still use it because it is backed by Google, only a few frameworks are backed by big companies, and it's less of a departure than the other frameworks.
React and Backbone aren't frameworks in the sense that businesses need frameworks, where repetitive decisions have conventions.
I just wish we'd stop trying to wedge these frameworks in to the wrong types of projects. Angular is great, for our authwalled web apps, from my use. I bet it would be for other people with the same needs, and wouldn't be for people who are trying to build marketing sites, blogs, or e-commerce.
I'm working on a very large, single page app in Angular. I use HTML links everywhere, and I thought that was standard. The router makes it so much easier to use regular hyperlinks for navigation.
AngularJS is a great example of over-engineering. Pretty much everything is needlessly complex and poorly designed. Learning to use it was difficult, and watching new employees struggle with it was painful. Newer libraries that take a virtual DOM approach like MithrilJS are so much nicer to work with. They are easier to understand, simpler, and faster. I wrote AngularJS applications professionally for a year at my last job, and in hindsight I wish we had spent more time evaluating the other options available at the time. AngularJS got us away from a structureless jQuery mess (not blaming jQuery btw, but technical debt from an application that grew too quickly), but what it created was a new kind of mess that is much harder to fix now that the team bought into the "Angular way".
Wasn't the point of Angular, bach in the days, that it isn't over-engineered and was put together by some guy at Google to show that it can go easier than with GWT?
I remember, 2 years ago, I was on a JS-meetup, and some guy was rambling about how Angular is the hot shit.
Funny thing was, he always said "yeah we had often the feeling, that something was fundamentally wrong with Angular, but after a few days into a problem, we found that we were wrong and Angular got it right."
His main argument was, that he uses Angular, because it feels better to use something "a guy at google did for fun"
That's my feelings exactly after using angular, just too much to wrap my head around, and I actually wasted my time wrapping my head around it.
I've since just gone back to using jQuery but mixin Bacon.js and Underscore I can write fairly minimal javascript that looks like javascript and aside from someone having to spend a day reading the Bacon.js docs anyone would be able to maintain it.
The reality is, Javascript has problems, and smart people disagree about how to solve those problems. The proliferation of frameworks is a symptom, but the frameworks are not themselves the problem. Javascript has some quirks, that is for sure, and then, independent of Javascript, HTML/XHTML has its quirks. Most ambitious sites today are trying to deliver software as a service, but HTML was conceived as a publishing mechanism for documents. The emphasis on publishing brings in some baggage that complicates any conversation about doing HTML right. Consider the holy wars that have raged regarding the word "semantic". There are many GUIs in the world that focus strictly on visual representation and programming mechanics. Think about Java/Swing, or GTK, or Flash. Swing does not aspire to be semantic, it only aspires to give us a GUI for those who would create a GUI app with Java. GTK is the same, it is for programming environments. But Javascript/HTML is given the task of being both a programming environment and also a publishing platform, with semantics and a hierarchical document object model. This is a confusing burden to put on something that most people nowadays only want to use as a programming environment.
In the short run, I do not know what the solution is. I suspect developers will continue to invent new Javascript frameworks in an effort to create sufficient levels of abstraction to ease the pain of development for the Web. In the long run, the solution for the industry will be polyglot browsers, and polyglot protocols, that can work as a runtime and thus give developers the kind of freedom on the frontend that they already have on the backend. Despite the many brilliant minds working on the issue, Javascript is never going to work as the byte-code of the Web. Something more general is needed. On the server, the JVM gives developers a runtime that allows them to use many languages, and many different paradigms: Scala, Clojure, jRuby, Jthyon, etc. We need that kind of flexibility on the frontend. And we need protocols to support that runtime.
That sounds nice on paper. But would it not be a security nightmare and result in browser fragmentation?
I rather tell my customers to embrace HTML and a concept where a URI has a main concern and if I want to see that concern, I have to load the page. I like to build web applications that work without Javascript, but enhance the page for better user experience, when activated. (Like the old (sane) times.)
It would be so nice, if I can just mail a link or make a bookmark and when I follow that link, I don't get a firework from a client-side application that tries to magically restore state.
BTW. I have JS deactivated by default and I am not the only one (security measures, privacy, insane amounts of JS loaded by e.g. news pages). I tend to be annoyed, if the page does not work without JS.
The possibility of browser fragmentation ceases to exist in a world of polyglot browsers. You would instead have fragmentation in the sense of many languages running on the runtime, and there the individual languages would presumably have their own system of managing dependencies, just like on the JVM now.
> a security nightmare
Sandboxing becomes an issue of the runtime. Assuming there is a standard runtime, then security could be managed as it is now.
> where a URI has a main concern
Those days started to end in 2004, with Ajax, and those days have suffered further retreat with WebSockets, and will likely cease to exist as people combine more data in one place. Have you seen how many Ajax calls your typical Angular app makes to construct one page? The original concept of the URI is undermined -- instead of a scalar value, most pages are now a vector of URIs.
>I tend to be annoyed, if the page does not work without JS.
My comments are only directed to those who are trying to offer software as a service. Those are services where the Javascript must be on. My remarks have no relevance for those traditional pages that you can view without JS. However, clearly, the industry is investing a great deal in sites that work as pure software -- it is for those sites that the old ideal of HTTP/HTML as a publishing platform is a handicap rather than a benefit.
As I said, your polyglot browser idea looks nice on paper. Look at the current state of browser development and how hard it is to push standards like HTML5 or Ecmascript 6 and take a look at the differences on how and when browser vendors implement those standards. And what languages should be supported? Who provides the runtime environments? What about the different devices and their capabilities?
Sandboxing is hard, very hard. You would be afraid to even open a browser window if you know enough. If you like to have a strong sandbox, you cannot use plugins. You cannot even use fonts or render images - not to speak of video. Using fancy HTML5 APIs like to access file system or device sensors? Gone. WebGL, well...
Ajax made URIs more important than ever. Everyone started to speak about APIs (first Widgets) and a dissertation of a guy named Fielding became really important, because people had to (re)learn the basics of the web (and are still learning). WebSockets are for data streams and you cannot compare that to your typical browsing session.
For me, Single Page Applications are nice for Dashboards or simply pages which federate data and are open for longer sessions. I do not condemn them. What I don't like are Single Page Applications which exist for the sake of a Fatclient-like experience. It creates so much more complexity when I have to work around the limitations of HTML. Angular, Ember or ExtJS are complex and it becomes a huge dependency/constraint. You have to duplicate so much business logic, because you cannot trust the client. You have to validate everything server-side. That's why there are approaches like Dart, GWT/Vaadin or even NodeJS.
I like it the other way around - old school. Javascript to enhance, not to enforce. Take Gmail: I like to bookmark important mails. When I open that bookmark, I like to see the message. But Gmail has to boot first. And this is really optimized compared to your usual Angular application. Why can't I just see my mail - rendered with plain HTML + CSS. And when I click one (mock) button (e.g. reply), the page becomes enhanced immediately (because it loaded the necessary script in the background). We could even be better at UIs, which do not try to put as much information on the screen as possible. Another good example is Atlassian. I really like their applications. Nearly everything can be opened in a new tab. On each page, I get the main information (the concern) first and when I need more, I can get that - even with heavy Javascript support. Everything that's important uses Javascript unobstrusively. I like that. I can link/bookmark that.
If you want people or entire businesses to share links and information effectively, Single Page Apps are not the answer.
Sandboxing is hard, very hard. You would be afraid to even open a browser window if you know enough. If you like to have a strong sandbox, you cannot use plugins. You cannot even use fonts or render images - not to speak of video. Using fancy HTML5 APIs like to access file system or device sensors? Gone. WebGL, well...
But this is the case right now with "javascript as the assembly of the web". So, nothing changes in the polyglot browser VM except that non-javascript languages can target it directly rather than go through javascript.
You're obviously not the only one who deactivates javascript by default, but a quick google brought up numbers of around 1% for users with javascript deactivated. I can see why a lot of developers wouldn't be too concerned about that 1%.
It used to be that a significant portion of that 1% (and those that also turned off CSS) were from those leveraging screenreaders some years back; with the uptake of ARIA and better screenreaders, not so much the case anymore.
So there was once a definite use case for supporting them in a B2C context, at least. You still see it in .edu/.gov/.mil quite a bit as a requirement (Sec 508, et al).
I strongly disagree the solution is polyglot browsers. This necessitates not only inventing a new web language(s), but then getting widespread adoption of them.
And IF you could do all that, what would be the end result? Fragmentation. Now anyone whose browser doesn't support your new language(s) can't visit your site. Unless you create a fallback site in HTML5/JS. So you've saved yourself no trouble and only created work for yourself.
It's ridiculous. The obvious way the web has been going for 20 years and will continue to go is refinement and improvement of HTML/JS.
I want to be able to deliver a packaged application built using a proper GUI toolkit to users with the simplicity of just linking to a URL. But we've had this ability almost forever in the form of "applets"; built with Java, Flash, or even Silverlight. Obviously no one one wants to use these plugin-based platforms anymore for very good reasons (security, performance, and usability).
The problem with starting from scratch with something new is that, today, you can deliver a "pretty good" user experience using nothing but HTML and JavaScript. And it already works on pretty much every single computing device available, without needing additional software.
Along with you I've been preaching about the disconnect between a "semantic" web document and a stateful GUI app. HTML, CSS, and JavaScript combine to make probaby _the worst_ GUI toolkit in wide use today. You can even blame Microsoft for inventing AJAX[2], laying the foundation for SPAs.
But it is getting better. I look ahead to things like Flexbox[0], CSS Grid Layout[1], ECMAScript 6, etc. The platform is maturing, enabling developers to create GUIs that feel even more native. But the packaging and delivery are still "broken".
I would love to see something like Chrome Apps[3] become a standard.
I think a lot of people would agree that being able to target a vm in the browser would be really nice. The problem comes down to getting a consensus. You run into the catch-22 of people only wanting plugin-less browser support but browser developers will only integrate it if the demand is already there.
I guess the DartVM is sort of in that direction, though I seem to remember reading that it is not a ByteCode VM.
The server doesn't need to use a JVM. You can use whatever language you want and expose it via a REST API with some JSON. Typically folks go to JVM when scalability is a problem.
Rendering on the client makes a lot more sense. By sending the user a template followed by the data necessary to fill it out you only send the structural code once. If the user views 100 pages then that's 99 times you've not had to send the HTML required to display the content. That's good news from a bandwidth point of view, an environmental point of view, and, if you're clever about how you code it, a rendering speed point of view because you only have to replace the content in some DOM nodes rather than repainting the entire template. That can lead to a faster display than swapping in the rendered content for some situations (particularly if the changes are small text elements and you have a shadow DOM available eg reactjs).
If you're doing something very complicated and your users have old or underpowered devices then rendering on the server is sensible, but in the modern web it really isn't appropriate.
> That's good news from a bandwidth point of view, an environmental point of view, and, if you're clever about how you code it, a rendering speed point of view because you only have to replace the content in some DOM nodes rather than repainting the entire template.
It's just intuition on my part, but I think the environmentally friendly option is probably actually sending a couple extra packets (server-side rendering) vs cooking the CPUs of however many clients you have with JS (client-side rendering).
Also, never experienced an application where parsing a blob of JSON and manipulating the innerText and values of HTMLElements with JavaScript was more efficient than setting innerHTML.
It's just intuition on my part, but I think the environmentally friendly option is probably actually sending a couple extra packets (server-side rendering) vs cooking the CPUs of however many clients you have with JS (client-side rendering)
The difference isn't between sending a couple of extra packets versus rendering on the client. It's between rendering on the server PLUS sending a couple of extra packets versus rendering on the client. You have to do the rendering somewhere. Assuming the code that does the rendering is essentially the same whether it's server-side or client-side, the only difference is sending the extra structural layout data when you render on the server. For most sites it'll make no real difference but if you're at Facebook scale I'd guess a couple of extra packets really adds up, especially considering you could cache the client-side templates between sessions.
I should have mentioned the assumption you'd be caching the render on the server. My bad.
So I imagined it as 1 render vs potentially thousands.
Another thing to note: You'd (probably) have to try real hard to find a server side templating solution that would render as slowly and use as much CPU as JavaScript on the client-side.
There's no magic bullet. As soon as your template references user specific (private) data, the caching advantage almost disappears, because each user requires their own cached rendering. You might as well cache it on the client and save the round-trip, and any additional network/server performance issues.
Rendering public, read-only content such as a tweet, however, makes total sense to cache on the server.
JSON is still rendered. It's not "render or send JSON", it's "render a string that contains formatted display output A, or a string that contains structured data B".
Facebook probably requires a lot of per-user effort true. A lot of sites (github for example) probably don't. It's probably limited to a couple areas of the header generally, or an A or B conditional render for an ownership page.
I don't think I agree. It's quite possible to make a single-page application with server-side rendering. Just create API endpoints on the server for rendering partials, and then the client-side router/controller need only be capable of replacing pre-rendered sections of pages with new ones. If these partials are caching-friendly, then you save a lot processing both front- and back-end. Sure, rendered partials might be more expensive over the wire than JSON, but that's pretty negligible.
I've done this. I've done Angular. I've done Ajax calls to templates on the client side. I've done Knockout.
Give me client side data binding (2 way!) any day of the week vs sending the partial back from the server side. You invariably end up with a bunch of shitty glue code that's dealing with the actions AND the display.
Using a framework (Angular, Ember, KO, Backbone) all allow you to separate this spaghetti nightmare into manageable chunks.
In enterprise Java there are quite a bit of tools/frameworks designed to do this. While I don't particularly like the one they use at my company (bloated quirky IBM code-gen tool), it makes me see the merits of this approach (everything is basically a single page app & sections of the page are only replaced as necessary -- it is a Portal solution). Between that & seeing the JSF/PrimeFaces components my friend is always messing around with, I see the breakdown as 2 camps really -- People who like to write js vs. people who don't...
For the people who do, pushing data & logic into the client is fun, working with js, working on the actual "single-page app" & updating logic/css/html simultaneously.
For people who are more into static typing / web back-end, & don't particularly like the process of writing js, there is a nice movement toward dynamic pages where the updates are concocted through data-binding & behind-the-scenes ajax (generated by the component libs...). For a lot of enterprise Java devs, the dream of having an ultimate single source of domain logic in the Java layer somewhere lends itself well to this solution. You code typical OO paradigm and just try to integrate those models naturally into the front-end binding.
I like writing JS just fine (okay, maybe not as much as I like writing Scala). And I think that doing a good server-rendered experience would likely require something at least as sophisticated as Backbone. But I just think JS should be concerned mostly with managing client-side UI and continuity.
For the project I'm working on, pages are generally comprised of large blocks of content, and to the extent that there is SPA going on, it's mostly swapping these blocks. I can definitely see the advantage of client-side rendering when model data tends to be spread out across the whole page. But there's no reason one can't have their cake and eat it too.
This is basically what I do sometimes in Rails apps backing some light jQuery frontend. They are traditional web apps with a few pages doing many front end tasks (think about adding, editing, deleting entries in an address book). They are done by sending $.ajax calls to the server. Some of them get JSON responses but some of them just get HTML and replace the DOM of some elements. That HTML is rendered using the very same partials used to generate the page when it was loaded first (think about the <tr>s in that address book's <table>). This is DRY. Obviously having all the templates in the client would be also DRY but I don't want to have some templates in the client and some on the server. It's either all or nothing and, at least for me, it's just easier to do some of those things on the server.
Doing these things on the server also allows you to take advantage of server-side caching. For some applications, you cannot do this as they are too tightly tied to the current user. However, most applications have at least some sections that can be rendered and cached across user segments.
Does this require clients of your server to all support HTML so that they can screen-scrape partials to understand the results of their operations, or does your server support two output formats?
Two output formats is a reasonable solution, but one that you don't have to maintain if you go with a framework (such as Angular) that can render JSON back into HTML. It really boils down to whether you want to support a more complicated server or a more complicated client (or drop support for any clients that aren't yours).
It's a traditional web app, so it works with HTML. We don't plan to have anything else any time soon so the priority was on the time to have the HTML ready to go.
I did a Rails app serving JSON exactly one year ago, to a small Angular front end. It's was a little disheartening to see an empty page loading and then making JSON calls and thinking that by then a server rendered page would have been already fully loaded. That's why I said that it's all or nothing: either a single page app or many html pages. A few single app pages don't do well, unless they are preloaded with server rendered content.
Sending incomplete pages means those of us that don't run javascript[1] don't actually see your site. First impression matter, and when your page is:
SomeSite
{{storyTitle}}
{{storyBody}}
{{curPage}} of {{numPages}}
...the common interpretation is "broken site". This current fad of being too lazy to implement progressive enhancement is a regression. Rendering on the server so you server up a actual page is trivial, and you can still provide javascript that loads the next pages faster. Serving up only a template (or worse: an empty body tag) is insane.
The usual counter is that "javascript is always available" not only ignores the risks, I suspect the claim is based on bad data. How do you know how many people disable javascript? We aren't going to be in most analytics...
[1] for the numerous security and privacy reasons. Running arbitrary instructions in a Turing complete language is a bottomless pit of problems, and "analytics" is still spyware. Google shouldn't get to build a log of every page we visit.
> How do you know how many people disable javascript?
In this day and age, most businesses don't care about this type of user. I have no sympathy for those who intentionally cripple the web and don't care to cater to them. You aren't worth it; progressive enhancement isn't worth the effort. It's cheaper to presume Javascript and ignore users like you altogether; don't forget this is business, our motives are profit, not doing things "right".
So so misguided - what happens when your javascript request fails? Or a broken build throws a script error? Progressive enhancement makes sure your content is accessible no matter what the conditions.
> what happens when your javascript request fails?
You hit 'refresh'
> Or a broken build throws a script error?
The same thing that happens when a broken build returns a 500---the user can't use that service until the developer fixes it.
Progressive enhancement is a theoretically good idea that---in practice---actually adds a lot of overhead to developers (because every layer of progression is its own UI, with its own user experience and considerations).
"Me" in this context is the customer. I'm talking about pages I see in the wild; when pages can't talk to their backends, they throw a "We crashed; please refresh" dialog, and I do what I'm told. ;)
Pages I write generally try their best to wrap calls that can fail in a reasonable retry envelope with some intelligent discernment of what response codes can be retried (429, the occasional 420 if someone thought Twitter was cute, the VERY occasional 500 if I just happen to know that the service in question is flaky) and only failing the error back to the user if the client can't retry it. In contrast to the non-JavaScript forms-only sites I've used, which tend to just surface their 429s and 500s straight to the user and expect them to know what a "back" button is (and whether it's safe to resend a form in this context), it's a better user experience.
(Incidentally: I do find myself having to re-invent that "retry envelope with a success handler, fail handler, and filter to determine if the response should be retried" boilerplate over and over as I move among frameworks; if anyone's built a smooth request wrapper for that, it'd be nice-to-have).
The administrator gets a report immediately. Also the server environment is much more in control. Been there, done that, the author has a lot of good points. Partial server rendering is rock solid and so much faster. Not looking back.
I use the noscript tag to tell people with JS disabled that the site requires JS, end of interaction. Enable js or go away, I have more important things to do than bother with people who intentionally break their browsers. They aren't the target market and aren't worth catering to.
This is business, not academia, right and wrong are judged by profit and loss and opportunity cost, not by what is ideal given unlimited resources. Work on feature X or double my work so a few people a day who break their browsers can still use the site... one is practical, the other is not.
I actually would like to get HN's take on this. Maybe someone should submit an HN poll. I'm still of the opinion disabling javascript is an extreme measure and those that do it need to come to terms with whatever broken internet experience they get. While I do think it's worth it to display to the enduser something like "Looks like javascript isn't enabled; you'll need to turn it on for this site", is it truly reasonable to spend development time to make your site functional without client-side javascript? Probably depends on your audience. I bet sites that are more commonly accessed through Tor have people more likely to have javascript turned off.
But yeah, anyone here work webdev where your webapp is expected to fully work without client-side javascript?
I've worked on projects where that was the expectation; I've set that expectation for projects.
The reasoning has both been concrete/practical and philosophical (but still practical):
* Mobile processing time is still costly in terms of battery life and performance. And the number of http calls (and their latency) also makes a difference in performance; SPAs tend to have smaller requests but larger numbers of them and it seems to me that's actually the opposite profile of what 3/4G cellular networks are good at. (And while this is all less true on the desktop I'm starting to find it annoying that we're nevertheless finding ways to make things choppy and slow on 2 GHz machines with operations not more complex than scrolling).
* This is more vague, but I find there's a discipline imposed in starting the conception of the app in terms of plain HTML/HTTP that seems to keep things better organized, while projects that start with a focus on a rich/heavy UI devolve into overspecific yet mixed concerns more quickly. This doesn't work for everything, since some apps just aren't about resources and media types. But honestly, your app probably is. :)
* Being able to debug/autotest with something like curl is pretty nice.
Nope. To me complaining that an app doesn't work with JS disabled is like complaining that the layout is busted with CSS disabled. It's not clear to me why I should worry about this case as a developer. You can turn shit off if you want to but don't complain that it doesn't work now.
I don't make that many web apps, mostly websites for clients, and I worry over IE8/9 users more than I do about people who turn their javascript off. It's a non-issue for us. If they have javascript turned off at such an aggressive level then they are used to things being broken all over the place.
I think it is not about web apps, more about the casual "one time visit" browsing. There is usually zero incentive to enable JS for a random website where you just want to read an article or watch images. JS there is usually (my impression) used for things that distract or try to lure me into other content. I like distraction free consumption. There is a high incentive to enable JS for a dynamic web app or site you regularly visit (eg HN) though.
Good control for JS and other requests in browsers makes this quite convenient to control as a (expert) user. I like umatrix a lot.
When I'm developing a website, if I have a time to do things the right way, I'm doing my best to present to user a usable website both without CSS and JS. Good semantic markup usually provides good user interface. And, as crawlers usually don't like JS, making non-JS version helps them to crawl the site anyway.
I browse with NoScript. Most sites are usable without JavaScript, maybe not as good looking but who cares. A few sites are not usable and I don't like them. If I really care about their content I enable some of their scripts. After a little, one gets good at recognizing the obvious candidates to enable and the obvious tracking scripts to keep disabled. This and that if I want to see videos (maybe I don't want), this and that if I want to hear audio, not that because it's the ad script, etc. If I don't really care, I go somewhere else. The same content is usually available elsewhere.
What would be better is the ability to selectively enable javascript scripts. I want the javascript for your webpage to run normally, but I don't want the javascript for that ad that moves around the screen or the one for that tracker bug to run at all. This was much easier when ads where mostly in flash.
Just FYI, Firefox has removed the setting to disable JavaScript out of its preferences dialog a while ago. Now the only way to disable it is through about:config. This means that to a second or third approximation, 100% of Firefox users will have JS enabled. I expect other browsers to follow this as well. JS is now a standard part of the web. Additionally, remember that JS is not required to track you. An invisible GIF works just as well to know which pages you visited.
BTW, how do you feel about apps running on your smartphone? Is that much different? Have you seen forecast.io? Well, probably not since you don't run JS, but check it out. Some people develop fantastic mobile apps in JS instead of Objective-C/Java and in that MO there is no option to render things server-side.
I install noscript on every firefox install that I can. Most people like that it makes a lot of sites run significantly faster.
I don't use a smartphone - they are a pathological platform entrenched firmly on the wrong side of the War On General Purpose Computing.
For the record: I do run some javascript - on a carefully selected whitelist basis. A big part of my point is that a website that works is something that I might whitelist to access better features. The problem is showing a broken page instead of showing a basic page and progressively enhancing in the fancier features.
I hope you don't drive a car either: it has many computers which are even on the wronger side of the War On General Purpose Computing.
How do people even come up with idea, that anything with CPU inside should be able to do General Purpose Computing :(
Sending incomplete pages means those of us that don't run javascript[1] don't actually see your site.
Sure, and that's a choice that every website owner has to make. Building a working no-JS app is non-trivial for all but the simplest things. Increasingly businesses I've worked with have found that "Doesn't allow Javascript" is shorthand for "Won't buy things online or share useful data due to security worries" so they're paying less and less attention to your needs. Things I build fall back to a simple no-JS version that prompts the user to phone orders or turn on JS. I would expect that to become the norm over the next 2 or 3 years.
Unfortunately, you are in the vast minority of people, probably even on hacker news (I would guess less that 1% of overall population [1]).
So the decision has to be made, just like whether you want to support IE7 users, whether or not you want to put in the extra time to support those edge cases.
And as always, it depends on the type of site you are running. If it's Amazon, that 1% matters a shit ton. If it's a side project or SaaS startup for example, it makes sense to hold off on supporting those 1% in favor of more pressing features.
You are almost alone dude. Javascript enabled users are the norm. People don't care about "Running arbitrary instructions in a Turing complete language" they care about buying things and watch videos faster.
I think it's reasonable to assume that either JavaScript is available or the user has made the conscious decision to turn off JS; if so, that user is probably savvy enough to realize the issue and decide whether to enable JS for the particular site.
Far less reasonable is faulting a JS framework for assuming it can use JS.
Still, I agree that if JS isn't essential to the functionality of the site, a non-JS fallback should be available.
Unfortunately, the problem is dynamic; any blacklist is always going to be outdated. A whitelist approach is the only blocking method that works. Javascript spyware has gotten a lot worse in the last ~year. A mainstream news site I happened to test recently wanted to issue HTTP requests to no less than 34 unique hosts, just to render a typical static news article. That wasn't the ads (adblock edge).
Not at all. Even when you are serving up an "application", sending a broken page isn't a good idea. I've written a couple very heavyweight "web apps" myself (for in-house use) and even those are careful to always send full pages even though page-rewriting was used most of the time. Given that this was easy to do in rails, I fail to see why rendering the template on the server during the first request is hard. It's pure lazyness by these newer frameworks.
If "app" means some pure-javascript game or similar, the very least you can do is provide a proper page that indicates that the game requires javascript. A warning message conveys useful information - a borken template or empty body tag conveys "bugged website".
People who intentionally disable javascript in the year 2015 should also disable css, then close their browsers, then remove themselves from the network, then turn off their computers, then go live in cave.
Most sites are not going to have users viewing 100 pages within a single session / before the cache expires. If you can reuse a template that many times then SPAs make sense certainly. But for many sites (especially content focused ones) the math is harder than that.
Enterprise developer here (well mostly). I see this in most of our apps -- the same "template" is called hundreds of times in a session. An accountant auditing invoices is a perfect example.
Now for random public website? Depends on the content. In the blogs I've administered, I feel that the first page rendering speed is KEY to keeping traffic (ie static cache the html). However, new visitors, when given a quick way to get to new articles with a minimal amount of friction, tend to stay on the site longer.
I don't know, it still feels alien to get a response from the server w/ an incomplete page and then wait for it to be completely rendered. https://groups.google.com is s a good example of this.
I wouldn't be at all surprised if the loading problems with Google Groups are a legacy of Deja News code still floating about in there somewhere. There's no good reason why a single page app has to look horrible while it's loading data - a well written app should display a nice looking holding page that gracefully adds content as it's received over the wire.
I agree with you. I hate hate hate having every single operation on a website take 1-2 seconds in good conditions, and 5-6 seconds on average conditions. I've developed a habit of tab clicking every hyperlink I think I might need just to navigate a little faster. Having the browser act like an application and then that application query data from the server fixes the performance problem... well at the least makes the performance problem fixable.
The problem is, Just because the client should download the application to work with your server, does NOT mean that the application has to be written in an insanely complicated framework with a year long spin up time and constantly changing semantics that makes it impossible to debug anything and obscures the performance of your application. Those two things are different.
I'm sure rendering on the server makes sense in some cases, but it's not as simple as you think. If you have a million users looking at the same content, you can render the template once on the server or a million times on the clients. Obviously, that's not always the case, but with things like ESI [1] the content does not have to be exactly the same to take advantage of caching (rendering the template once).
Also, keep in mind that content is compressed so the actual transfer time is often negligible, and the JS libraries could be bigger than the total html for the session.
That kind of makes sense. How often do you view Tweets on a desktop? Even when I'm actively using a desktop browser, I usually check Tweets on my phone. Why? Because that's where I get notified first. Fits the "underpowered devices" category, right?
I suppose the focus should be on who your users are, and what kind of devices they have, to help one decide between client-side and server-side rendering.
The advantage of server side rendering is only on first load of the page. Once everything is cached in the client, client side rendering is way more efficient. You only need to fetch the data you need. And if you have serverside push, all the better.
Another thing people tend to overlook about server-side rendering tends to be the battery usage on mobile involved in keeping radios alive for things that would otherwise not require it. Mobile OS's go through pains to keep battery performant by turning off hardware when not in use, but constant server-side view round-trips de-optimize that capability.
You still have a roundtrip. The question is can angular use significantly reduce the bandwidth required. In my, limited, experience of any major js rendering on the client the answer is most likely no it won't.
This article is ranting about single-page applications written with javascript frameworks. The word "Angular" was thrown as click-bait because it's the latest whipping-boy. From what I read there isn't a single valid complaint that's specific to Angular.
I think it is inaccurate to accuse the author of using Angular as "clickbait". To me that term is reserved for titles which don't match the content. Whether you feel every argument could also apply to "every" js framework, you cannot argue that this article was specifically about Angular. It included Angular code, anecdotal references to real Angular projects, and various quotes from sources all about Angular.
The one complaint the author made about the DOM parsing definitely doesn't apply to React, though not sure how Ember and Backbone handle that sort of thing.
He could have replaced the Angular code with Ember code and levied the exact same complaints. Re-read the article and try to figure out which complaints aren't also valid for other large JS frameworks. It's clear he's a libraries > frameworks guy, which is a perfectly valid viewpoint to have, but it's cowardly to frame such a debate as a thoughtful criticism of a specific framework because it won't draw rebuttals from nearly as many people who might otherwise feel the need to chime in.
He specifically mentions performance many times but has no statistics to back this up. I have created a web app with Angular and it runs fine on old Android phones and iPhones. We don't see any performance problems. Of course YMMV but he/she makes it should like the performance is a really big problem that everyone will get affected by which I thinks is wrong, most apps won't have any major performance problems.
I agree that it's a rant, and a not particularly focused rant at that, but it has plenty of call outs to Angular code, documentation, and commentary examples, so it's hard for me to agree that it only name drops Angular as clickbait.
If you look closer at them you'll notice most of those rants are "feels wrong" type rants that could be levied at almost any framework the author doesn't particularly like. The only solid complaint he has is a performance test which, again, both Angular and Ember perform poorly on, and in the same breath he admits these issues are easily mitigated but laments that they aren't mitigated by default. He uses it as an opportunity to praise Backbone which further fits his "large frameworks are bad" premise which is what the article should have been titled. But hey, based on how quickly this article shot to the top of Hacker News it appears his more link-baity title was effective.
Not at all, the author praises Backbone. The learning curve, busted syntax, and performance issues unfortunately ARE specific to Angular, that's the entire point of the article.
Backbone is as lightweight as a framework can get - to the point where one might call it a library. It's common for people who are anti-framework to embrace smaller frameworks like React and Backbone.
> The learning curve, busted syntax, and performance issues unfortunately ARE specific to Angular, that's the entire point of the article.
But they're really not. Ember has the same learning curve and performance issues that Angular has, and "busted syntax" is completely subjective.
I can't get behind the article's idea that Angular is built by people who are non-front-enders for non-front-enders. It's a bold statement that hasn't been supported.
I'm an avid user of Angular and as far as performance goes: you have to be aware of the hefty digest cycle.
We should all be well aware of the downsides of Angular. Just like any technology, there are upsides and there are downsides. When used right, Angular is a powerful tool and the downsides can usually be mitigated.
If I had to help support this article then I would restate the problem statement: the field of web development has exploded and the barriers to entry are nil. Frameworks now have to be built in such a way that they can hold up to the abuse and misuse by less experienced devs.
"Although templating is the correct solution, doing it in the browser is fundamentally wrong."
We keep forgetting that the decision of where to run the view logic depends on the environment.
We have swung between cpu and bandwidth as bottlenecks in the last decades multiple times, and that's how framework moved between server side and client side mvc multiple times.
No approach is radically different. We moved to thin client when browser were good enough; increase in bandwidth and smaller latency enabled rich client application, making the browser thick again. Handheld devices however are getting more common, so people are facing problems with all the logic and content being manipulated on the client.
It doesn't mean the thick client solution is fundamentally wrong. Also it doesn't mean we have to invent new strategies and pattern to solve this.
When you take a step back from the technology and return to the problem it was solving, it appears to me that we are just back at the thin vs thick debate, and as before this is not an issue of 'which is better', more of 'which is more appropriate to the topology constraints we have'
I've always respected the quirksmode blog, but this article is pure FUD.
Many of the criticisms are general to thick client web apps:
"I feel that Angular’s fundamental proposition blurs the line between front end and back end."
"Although templating is the correct solution, doing it in the browser is fundamentally wrong."
Others are intentional ignorant.
"Ouch. Thou shalt eat thy own dogfood."
Google also makes GWT and Dart. Should they use all three on every product? The more resources you have and the more demanding your circumstances, the less any general purpose framework will make sense.
"In other words, Angular requires you to spend a lot of time to teach yourself the Angular way of doing things."
What part of this industry doesn't? Put the logic on the server and you're learning Rails, Flask, whatever instead.
"Google will eventually stop supporting 1.x."
Yes, years after they release 2.0. They've been very explicit about that and it's a better policy than most libraries have.
I can't help but get the idea that the author just doesn't like the idea of doing things differently than he always has. Good luck with that.
There seems to be a theme in there that angular is too heavy (Java, templates, performance, time reading DOM on load) for the front-end.
There's really a false premise at play here - that apps these days are as simple as they once were. Imagine for a second that front-end applications are vastly more complex than they once were (because they are). For any of us who have built more complex front end tools, you need something to help you manage the complexity you're now carrying around.
Now the rest of it starts to make sense. More uptake from backend devs than front-end devs? The backend guys have built large complex systems in the past, they know that a tool like this can help them and it's something they're used to dealing with. Prescribed structure to your code? Yup, sounds good - I don't want to spend my day figuring out someone's callback spaghetti or DOM updating triggers from random locations. Front-end templates? If you don't need them and you're using angular you are using the wrong tool for the job.
What really annoys me is when people throw around the term "over-engineered". This is pretty much just a complaint in disguise saying they didn't understand how it works with a 5 minute glance. If you don't have at least a few 2000 line spaghetti code functions in your code base, its "over-engineered"
If you're building an app that can't be rendered on the server, at some point you've have to update the DOM - templates are one method that allows you to do that in a declarative fashion.
Sorry, I'm calling bullshit on his argument for server-side rendering for increased performance.
Consider a typical SPA:
===
In my SPA I load one large html document and javascript file in. The html document contains the 30-or-so templates my system needs to use. The script contains logic and localization data for the user.
This is all cached.
As my users use app, Angular makes calls to my REST/JSON services, transferring just the data it requires with a very efficient encoding. Some of the data is even cached in local storage.
Now, imagine that I've moved the rendering to the server. Instead of transferring a couple of KB of JSON data when a user filters a grid, I have to transfer 30k of HTML markup. My HTML could be smaller, but my designers really like to have class names on all elements. Plus the German text I see is really long.
===
In this rather common scenario the SPA vastly outperforms the traditional server-side render-as-markup sites I was making three/four years ago. Network dominates, especially on mobile. It's not your CPU killing your battery, it's the screen and radios.
If you're making a simple informational site - a newspaper, blog, marketing site - then sure your performance will suffer, but that isn't the problem. The problem is that you're using a excavator to plant a daffodil. You shouldn't even need to use a server-side framework, let alone Javascript.
Server-side templates only make sense if you assume that every user action will end up needing the DB. If what you're building is really an _app_, and not just a webpage, you can't expect to compute its UI on the server, making the user wait for a network round-trip for every action.
If your app is built around server-side templates, but your UI doesn't need the server, then you end up with a royal mess. The client has to do DOM manipulation over the rendered page, so now the templates have to include convenient hooks for the jQuery selectors your client will need. There ends up being no clear separation between the server's responsibilities and the client's. In this situation it's much better to just let the client own the UI entirely.
This article could be right; I don't know the domain enough to say. And it did clarify for me why some people find Angular so contentious: different tribes. But at a number of points where I was expecting explanation, I got bare assertions.
For example, "These languages have their place in the web development stack — but on the server, not in the browser." Why's that? Personally, I'm looking forward to seeing languages that pay little attention to the divide, so that you can easily move code from one execution context to another as needed.
Or the already noted bit about client-side vs server-side rendering.
Or "Google aims to conquer the enterprise market, and Angular is one of its tools." Do they? I live in San Francisco and know a bunch of people who work at Google, and I have never heard the notion that they are aiming to own a lot of enterprise-developer mindshare. I'm certainly having trouble seeing how increased Angular usage leads to some billion-dollar revenue stream.
Or this, criticizing Angular's origin as a prototyping too: "I don’t think that a rapid-prototyping framework should be used for complex, enterprise-level production code." This from a guy whose favorite language was created for some light mouseover animation and form validation? You could say that Rails fits his description precisely, and it seems to be doing ok in the enterprise.
So I wish this had had more meat. As it is, it seems more like a dressed-up version of "Angular does not match my tastes," than the serious examination it wants to be.
Also, fussy language note: please nobody ever say "pulled straight from the horse's mouth". If you're going to use a metaphor, use it fully and well. Pulling something from a horse's mouth is going to be a disgusting and possibly dangerous operation. One hears something straight from the horse's mouth.
All I know of Angular is the pain our JS devs have using it. If Angular 1.x was so great why is Google tossing it out and building essentially a new framework in Angular 2.0? That would seem an indication that it isn't very good.
Because the web is changing at light speed and the frame work they designed years ago requires more than a bandaid to adapt. It doesn't mean it's not "good", it's just not great. The dev world is very opinionated, if you pick the most popular framework in for any language or environment you'll find a heavy amount of "haters" and rightfully so.;
Angular is the leader, they're rewriting to address some of the haters, and are getting more hate for it.
The author hit the nail on the head for me: "The biggest problem for many front-enders seems to be that Angular forces you to work in one specific way."
I'm opposed to opinionated frameworks. which is why I don't use Rails. And why with Python I use pyramid/flask instead of django.
And with JS/node, I've found the commonJS+modules approach a far better means to structure my code than any monolithic framework.
Opinionated frameworks have their benefits. If you're working in their chosen domain, they're often pretty cheap to use. And for some teams, it's especially handy to have plenty of opinions baked in to minimize arguments over every goddamn thing.
When he wrote, "Many front-enders, on the other hand, who have worked with JavaScript and browsers for years and have developed their own coding style, tend to have their doubts about Angular," my thought was, "Oh god, imagine a team of 10 of those people."
I too have developed many style preferences over the years, but long ago I learned they don't matter nearly as much for project success as having a common style.
Exactly yhis is the point PPK is missing imo. A generic structure is offered by Angular, versus the mismatch of libraries, plugins, templating engines (all with their own bugs) that we had before.
I've built a lot of HTML5 over the years, and handing over projects that include your personal preferences and nifty things (even if it's 'Object Oriented' Mootools) can make another developer that has no prior knowledge of it decide to throw everything away and start from scratch.
At least angular provides a standardized and documented way of doing everything.
I think you meant Ember. I've seen the same thing done a bunch of different ways in Angular. They all work. That being said, my team has come up with a way to develop Angular apps. It looks little like the samples and people new to our world have to unlearn and relearn some things, but it gives us more agility and makes our code work better/simpler.
No I didn't mean Ember. Ember is even more opinionated than Angular.
You can strip it down to the metal and use pure CommonJS + npm modules for everything ng/ember/backbone would give you. Especially now with ES6 on the horizon.
I, too, avoid Rails and Django for that exact reason. The "opinions" of Angular, however, are very smart encouragements made by seasoned engineers: data binding models to UI elements, dependency injection for testability, and web components-like loose coupling of widgets. These are simply good practices.
Monolithic and opinionated, in software libraries and frameworks, will always contrast with lite an modular. Some monoliths end up long-lasting (Rails?), some perish – as always, fitting the needs of your target audience is key. “Backend engineers”, for a JS framework, is as good a target audience as any.
Adopting Angular 2.0 would require them to allocate massive amounts of budget to rewriting code that already works.
I really wish the team would rename "Angular 2.0" to
"Angular for ES6". This would make the rebuttal to this point painfully obvious - one day most ES5 code will need to be rewritten / re-architected for ES6 anyway. The cost of rewriting everything is not just for upgrading a framework from 1.0 to 2.0, but to use a (then) modern language.
Now I'm definitely more embedded in the backenders community than the frontenders, but from my perspective Angular.js has been a lot more popular than the author suggests. Of course my only metric for this is hearing other people talk about it.
When we started selecting technologies for a new frontend for our web application about a year and a half ago, I did a quick evaluation of the big frameworks. Looking at the TODO list implementations and implementing a small side project in Angular and a few others.
My conclusion was that the way angular works and how you use it was pretty horrible, and I was quite surprised to see so many so impressed and positive about it. I didn't even think about its performance (as it was promised it was going to improve as it stabilised). The whole idea of the dependency injections and factories, it just doesn't make sense. Within the company my colleagues agreed with my conclusions so we decided to pick something else.
My probably not so popular opinion on dependency injection in dynamic languages is that you shouldn't bother with it. Javascript (and Ruby for that matter) allows you to overwrite both properties and prototypes, this means that any dependency injection can be done dynamically at runtime whenever you want as long as your logic and data is nicely captured in properties. (Note that his last clause is something that often does not hold in Javascript projects as most/many authors love wrapping their stuff in functions with very harshly make lots of things private and immutable)
So designing a whole framework around enforcing this pattern, with a terrible syntax and un-fathomable semantics, on top of a dynamic language, it doesn't sit well with me.
My probably not so popular opinion on dependency injection in dynamic languages is that you shouldn't bother with it.
I heartily agree. Imagine trying to do dependency injection in a Lisp or Scheme app. It'd be like putting legs on a snake. Totally unnecessary. Now recall that JavaScript was designed to resemble Scheme with a C-like syntax.
Angular's dependency injection is very similar to AMD modules. In fact, the syntax is barely distinguishable. So if you have an issue with Angular's dependency injection, you likely have issues with AMD and perhaps javascript modules in general. I much prefer having my dependencies injected in a modular way than having to pollute the global namespace with every library and component I pull in.
Well this is exactly the point that people disagree on with me. I think your application owns the global namespace, as long as your dependencies are neatly defined somewhere there really is no downside to letting pulled in libraries 'pollute' your global namespace.
When you're working on large teams it's no longer your global namespace alone. I've worked on quite a few projects that abused the global namespace and it's very painful to try and recover from.
Well our pick comes with a big disclaimer, we chose Polymer. I am not sure if it's already a good idea to build a big consumer-facing using this tech as it's very future (modern browser) oriented.
That said, Polymer has been absolutely awesome to work with. Even though it's not so much a framework as it is an interface/wrapper around some cool new stuff that's in HTML5 we built a very light weight framework around it and that has been a great experience for us.
It's possible we did some more work than we would have to on other frameworks, but we got a lot of control back for it. I think we would've went with something light like backbone.js otherwise. And it's also possible that it would not have been a good choice if we had team members with less experience (i.e. every now again there's some advanced fire extuingishing going on).
Anyway, our audience is a low-traffic tech niche and our app is a SPA that's mostly read-only, so that's a very small target that gives us a lot of room for taking chances and picking tech.
absolutely agree. when I first saw AngularJS and read about dependency injection, I was turned off immediately, wtf?? Of course, I was not brave enough to call google guys idiots.
I can't really verify the authors thesis that most people using Angular are backend developers, but it does seem to have become the first thing everybody tries to learn after JS/jQuery. I've been interviewing a lot of entry level candidates lately, and "I've also started playing with Angular" has practically been a theme song.
Of the people dozen I know who were early adopters of Angular or do AngularJS now, only one wasn't a serious back-end developer.
I think the split may be better worded as programmer/scripter. Some of my unscientific sample were using other Javascript frameworks (Backbone mostly) but were definitely programmers, and wrote in assorted languages too.
The problem is that many back end frameworks tend to hide JavaScript, the likes of JSF and Web.Forms.
So most project managers when moving out for more lean (MVC) frameworks, tend to look for something like AngularJS and since Angular comes from Google, it automatically gets selected.
That is how we started getting Angular on our RFPs.
The problem with Angular is that it's 2005 technology masquerading as the new hotness. Angular existed in 2005 in almost the same state. Why? For people who wrote Java or PHP that didn't want to learn this "new" language, JavaScript. In fact, we had a half-dozen implementations between ASP, whatever the name of Google's solution was at the time, and the Myriad of "MooTools Helpers" and "Prototype Helpers" in PHP.
The reality is that Angular, as a framework, takes you 90% of the way there, just like any other framework, but it makes the last 10% almost impossible to do "right." This is in contrast to JS-based frameworks which don't conflate your entire application to add some questionable ease of use. ReactJS, Knockout, etc, are all superior in that they allow you to do some Angular things without getting in your way when you need to do non-Angular things.
"This code reminds me of a simple server-side scripting language such as JSP or ASP that’s used to fill HTML templates with database content. These languages have their place in the web development stack — but on the server, not in the browser."
What is the problem? I make isomorphic apps and I really like this. DRY
HTML templating belongs on the server-end? Well, that's... debatable.
I like Angular. It is backed by Google so it's less likely to be abandoned because of boredom. It ibolides the batteries; I don't have to learn about dozens of independent libraries just to get something simple together. It is fast enough. Lastly, Ionic is pretty neat.
That is not to say it doesn't have it's bad parts. I don't care for some of the boilerplate it has and how badly it fails if you screw any of it up. I am not a fan of the built in $http service. The state service and URL routing are also too confusing and often do not work correctly when doing slightly more advanced things (intercepting transitions, rewriting history). But overall, I like it better than, say, Backbone.
I'm not familiar with the word "ibolides", and a google search didn't turn up anything I could fit as something you could do to batteries. Could I convince you to explain what it means?
Lack of PATCH method out of the box. No easy way to provide error reporting to the user for some but not all requests. For example, when a user submits a form and it fails, show them a dialog, but when the app makes a background request to refresh some data, and it fails, don't bother the user about it.
It's not a huge problem, I just end up creating my own wrapper around it that provides all the necessary methods, but it could be built in.
This article is really bad. Having learned Angular and written an app in it, I liked Angular 1.x OK. I think between Angular 1.x and Ember it was mostly a six of one, half dozen of the other question. I went with Angular for my app because I thought "It's backed by Google, they'll grow it responsibly and smartly." Well, color me stupid. I feel pretty burned by Angular 2.0, now not only does the app I wrote need to be 100% rewritten, but everything I spent time learning about Angular 1.x is now wasted effort.
That is the problem with Angular. Angular 2.0. Nothing else this article talks about is really a valid criticism at all. See other comments about that.
Just a few points for me about Angular in my own experience. When I first started using it, it seemed rather straight forward and easy to use. I could use it in some of my projects, or build entire apps with it.
Then came the notice of the rewrite. At that point, I pretty much lost interest in it. I mean, if you're going to have a major rewrite and and not make any of it backwards compatible, what's to say you won't do it again in another few years? For me, this was a deal breaker. Why build apps now which be obsolete when 2.0 finally rolls around?
Also, I'm not sure why people think apps have some incredibly long life span. Almost every large enterprise app I've ever worked on only goes about a year, maybe two years before it gets a complete overhaul. Here's a good example:
Large Enterprise Healthcare App:
- First iteration which was the longest and went from 2005-2010. Built on Java and Tables in HTML. Brutal, but effective and easy for the Java guys to maintain.
- Second iteration was from 2010 - 2012. Built on Java and with mainly Javascript and the HTML is cleaned up and tables removed.
- Third iteration was from 2012-2013, Built on Spring MVC, HTML5 and CSS3 with lots of jQuery and Javascript for several interactive charts.
- Last iteration I was a part of was in late 2013 - October of 2014. Completely rebuilt with responsive design, built on Grails, with lots of CSS3, jQuery and some Ember and Backbone pieces.
Even when I left they were contemplating another total overhaul, possibly moving back to Spring, and doing more client side stuff with Angular or Backbone and possibly doing some NodeJs as well. The app basically went from 5 year re-design schedule, to essentially less than 14 months in between overhauls. I'm just chalking this up to a constant parade of contractors who come in and are using the latest and greatest stuff, and then push that for the app. When they leave, nobody has the ability to maintain it, so they just rinse and repeat with contractors and technology.
Either way, my point here is that apps seem to have shorter and shorter lifespans before being completely overhauled. It's like maintenance isn't even really a requirement anymore.
"Although Angular will run on ES 5 browsers (the current world), changes being made to the core Angular architecture will break every Angular application. See this InfoQ article for details, which include removal of controllers, current directive definition syntax, $scope, and more."
and from the Angular Team after the Euro conference:
"Our goal with Angular 2 is to make the best possible set of tools for building web apps not constrained by maintaining backwards compatibility with existing APIs."
Which is totally different than having to maintain an application over an extended period of time. They're two totally different issues.
The problem with AngularJS can be summarised thus:
"Its marketing and documentation does not correct those who believe it is suitable for web-applications more complex than simple CRUD apps."
As soon as you have an application where you have to reason about the events ocurring in your page, with AngularJS you're lost. Note that CRUD apps are a sizeable proportion if not the majority of applications, so it's brilliant for a massive number of applications.
But for anything more complicated, you're on a knife-edge of performance-problems and ballooning accidental complexity.
> Angular is aimed at large enterprise IT back-enders and managers who are confused by JavaScript’s insane proliferation of tools.
I pushed Angular for our team because it was so confining. Keep the code modularized and stick to best practices. Honestly, it's been a joy to work with. Instead of hodgepodge jquery soup, we have structured code that anyone can dive into and follow a common style.
It feels like the old guard keeps pushing back on SPA's. It is a so much more dynamic experience for the user than your typical oldschool postback driven site.
Angular was written by Google for Google products. It had a big corp audience in mind from the start. It provides developer structure at the cost of agility. This makes sense in large teams where contributors come and go and have varied skill sets. Encapsulation and isolation of scope makes limits the damage one component can do. To achieve this rigidity a lot of background enforcement is required. The result is performance decline and lots of development overhead.
It's not just Java and Backend guys, I worked with Flash and Flex for 10 years, for me Angular makes perfect sense. I know I'm not alone either. Before these great "framework wars" of Javascript, there were framework wars in the Flex world, with frameworks of varying credibility and endless haters / fanboys publicly pronouncing their butt hurt about their whims. Google any "[enter framework] sucks" and get your opinions validated.
I admit I haven't read all the comments. But what I have read from the author, in some comments here and in the follow up article, I get the impression that there get things mixed up, that actually don't belong together. In my opinion you have to distinguish between web apps and content pages.
In the first, client side templating is just fine and the right way. Everything changes and the users are making a great deal of changing the output. A round-trip here is destroying the feeling of an app.
In the second, client side templating is just unnecessary. But so is server side templating, in many cases. Taken that the pages to display are rarely changed it would be even better to have simple static html, pre compiled.
The hard task comes when we have some mixed scenarios. A CMS for example. In my opinion the content creation process is a very valid use case for client-side-rendering - an app for creating html output, if you will. But when it comes to display that content it should reside precompiled (no server side rendering) on the server. So that just plain html pages have to be delivered to the actual users.
This article is mostly BS. He's got the knack of sounding like he knows what he's talking about when he actually doesn't. Some examples:
"Angular’s ng-repeat directive will create or destroy DOM elements accordingly. This turned out to be quite expensive. ...
... what worries me is that this non-performant mode is Angular's default. Front-end framework defaults should use established front-end best practices. Angular’s don’t."
He's talking about ngRepeat's "track by" function here and clearly doesn't understand that it can't be switched on by default as the user must specify the name of a unique id used in their data models. There is no way for this to be on by default.
"Although templating is the correct solution, doing it in the browser is fundamentally wrong. The cost of application maintenance should not be offloaded onto all their users’s browsers (we’re talking millions of hits per month here) — especially not the mobile ones. This job belongs on the server."
What does that even mean. Consumer hardware contains heaps of resource for web browsing.
"Many front-enders, on the other hand, who have worked with JavaScript and browsers for years and have developed their own coding style"
Cute front-enders with their own adorable coding styles. Code is code. Patterns structure code to increase maintainability. Stop imagining there's a group of people whose work this does not apply to.
"That’s why most Angular developers come from the back-end, particularly from Java. As far as I know this situation where a front-end framework is supported mostly by non-front-enders is unique."
More of this front-end/back-end discrimination bullshit. That's a distinctly enterprise paradigm that just has to go. It's 2015
"I’d say Angular is mostly being used by people from a Java background because its coding style is aimed at them. Unfortunately they aren’t trained to recognise Angular’s performance problems."
If I follow the logic correctly--people with Java backgrounds are not trained to recognize performance problems? Quite the curious line of reasoning.
It's specific to Angular running in the browser opposed to Java running on a server. You'll certainly run into different performance bottlenecks especially in long running client side applications. What works on the JVM will be very different than what works on the browser especially across multiple vendor's JS runtimes and versions.
Angular emanated some 'project smells' that have kept me at arms length. The size of the codebase was very large compared to alternatives. Lots of add-on solutions for various problems (ng-this, ng-that) kept cropping up. Articles explaining how to do X or Y in Angular indicated things were probably not as simple as they ought to be. And, it was mainly driven by Google as opposed to a small core team of diverse individuals. The tools that have turned out to be the best in my experience have often had one visionary lead developer, a BDFL-type champion. I expect Angular to appeal more to enterprises, while the early adopters and lean startups shift towards small libraries and microframeworks. I think web components will become more and more important, and that we'll begin to see more libraries to assist specifically with data persistence and synchronization between the client and server.
The author's logic follows, the only problem is he's picked the wrong term. His argument is against using javascript and/or data-/ng- attributes to bind default data to a template. Wasted power and cpu cycles. I think we can all agree that premise is true. However, templating with binding is all about savings in bandwidth, memory, and http requests. It also keeps complexity down when done right.
So yes, quit using various unnecessary means of supplying binding references to the DOM and serve & send your HTTP correctly. But none of youo ever will.
Because it saves me lots of money since I don't need so many backend servers.
We are already offloading lots of stuff to the client already. CSS is a great example of this. We could have a server calculate the colour of some text, or just tell the browser which rules should be used to calculate that colour.
EDIT: For almost two years I've used Angular on most of our web systems at work, and also on most of my private ones where i make the client exceptionally thick and the server is just for persistence.
Most of this seems a bit personal and a bit of a surprise from PPK.
The first few paragraphs are trying to convince you that Angular isn't popular and isn't meant for cool people. You don't need to consult Google Trends to sense that there is an ego on the wrong end of a popularity contest at play, but here it is:
Poorly written article mostly. Largely just fluff and opinion, and rehashing of problems other people have mentioned. I swear everytime I read one, I expect a unique take, but they always end up the same. Two or three paragraphs hinting that it might not be performant, and another 3 or 4 paragraphs talking about how Google doesn't even use it and how Angular is somehow hard to learn. Only thing that surprised me is he didn't tell us about how great React is at the end of the blog.
"Although templating is the correct solution, doing it in the browser is fundamentally wrong."
This statement alone sounds like someone doesn't want to learn new things.
I'm sorry, but I wrote ASP.NET webforms for years and you will pry Angular templates out of my cold dead hands. Of course if you have optimizations for narrow scenarios, then by all means refactor...but most activity in a SPA is pretty simple stuff. A template and a couple of REST calls and you're set.
I think some of these front end frameworks come from developers looking the bloated mess that is Enterprise Development and they think, "Man! I gotta get me some of that!"
I don't think the author has heard of JSON,restful end points, and or design patterns, I don't understand why he would develop with the intent of rendering the pages on the server side, when the client can do that faster and you can reduce server load. Not only is that a performance advantage its a design advantage, now you can have mobile clients that render data natively and you don't have to work as hard to develop for mobile.
>The biggest problem for many front-enders seems to be that Angular forces you to work in one specific way.
I am not sure this is a weakness. While everyone protests change and all developer's heads explode when you force them to use a specific convention, in the real world a common standard of coders in one company is a good thing.
This guy would have been better off just saying "Angular 2.0 breaks Angular. The End."
They took out {{ }}, $scope, DDO, controllers, jqlite, angular.module, and are moving to ES6 when basically no browsers have even started supporting it.
Isn't that enough? Do we really need to complain about Java developers writing for the web?
It is more than obvious that the author of this article really doesn't understand Angular. Also, you can't say that poorly educated developers is a "problem with Angular", and this is essentially the author's primary argument here.
In my experience, most of what people want can and should be done server side. Instead of big frameworks, something smaller like Knockout can be useful for adding some interactive javascript in a way that is cleaner than the standard pile of jquery.
How did such a horribly written article with no substance or structure got so popular? This guy just explains how he "thinks" and "feels" with no supporting evidence.
One of his first points is:
"I feel that Angular’s fundamental proposition blurs the line between front end and back end."
Why? I feel it makes the line clearer. So there.
After I read the entire article I was still left wondering what his point was. He concludes with discussing Angular 2.0
"The 2.0 rewrite is aimed at front-end developers, but may not reach them, and in addition will turn off Angular’s current following. I don’t think Angular will survive the rewrite."
Well, no shit. Let me get this straight: a front end framework isn't going to survive because it's targeted at front end developers? Who writes this crap?
Really disappointed with the quality of this article. PPK was such a valuable resource back in the day when it came to front end development and always had great content (especially when it came to compatibility issues). I'm not even saying I disagree with him here, but this writeup seems pretty half-assed, at least for someone of his caliber.
I don't agree with this claim whatsoever - "Angular is aimed at corporate IT departments rather than front-enders"
I'd say it's the other way around, if you read "front-enders" as hobbyists, start ups and SME's. Angular is still far too new and unproven for most big corporate IT departments.
The Angular juggernaut is like the Java juggernaut at light speed for corporate IT. I'm interested to see how the Angular 2.0 risk assessment is constructed within corporate IT today. Start on a 1.2 project with, potentially, a full rewrite needed within 2-4 years? That's not typically a risk slowly evolving LoB applications take on. Good luck finding Angular devs in 5 years willing to live on the 1.2 brownfield. Until the schism around 2.0 gets resolved, I'm not sure I see this playing out well for them.
My issue with AngularJS: Debugging is an absolute nightmare, error messages are far and in-between. And when working on a 50k+ line production code-base, one single comma a in a file where it is not supposed to be will shut down the whole GUI. And occasionally, it won't even show where in the console.
In dev it will show exactly where in the console, assuming you have a sane dev environment, and if you're running a tool like jshint, you can catch any such error fast. That is a non-issue, and not even one unique to Angular.
I got my start as a professional programmer at an IBM shop on an System 38 --> AS/400 writing RPG apps with 5250 terminals. When HTTP/HTML started taking off in 1993 because of Mosaic I felt right at home.
RPG ran on the AS/400 and your DSPF (display file) ran on the terminal. DSPFs did screen layout, validation, etc...
> Despite its serious technical problems Angular 1.x is a success especially among corporate developers with a Java background. The 2.0 rewrite is aimed at front-end developers [...]
... says who? I don't know any Java developer who does Angular now, and who ever said front-end devs are the target audience of the rewrite?
> I feel that Angular’s fundamental proposition blurs the line between front end and back end.
Sorry?
> Angular is aimed at large enterprise IT back-enders and managers who are confused by JavaScript’s insane proliferation of tools.
Wait, seriously?
> When AngularJS was first created, almost five years ago, it was not originally intended for developers.
When I started using Angular 3 years ago (ver 0.9) it was already mature enough for serious web development and better (better structured, better documented, better for large web apps) than a lot of other frameworks (like Backbone). Back then it was developed by three Czech guys, that Google employed in the meantime and funded their project.
> Enterprise IT managers also like the fact that Angular closely mirrors the preferences of their back-end developers.
This just pisses me off already.
> Many front-enders, on the other hand, who have worked with JavaScript and browsers for years and have developed their own coding style, tend to have their doubts about Angular.
Yes, because their old code used to be utterly crap compared to something written in Angular. Angular does not let you write such messy code as you could without a framework.
This article is all FUD. I have never imagined that I'll ever see such a bad piece written about Angular.
Tell us more how it is better structured and better documented than Backbone and what exactly makes it better for the large apps. The size of the app will hide the size of the framework better?
"This code reminds me of a simple server-side scripting language such as JSP or ASP that’s used to fill HTML templates with database content. These languages have their place in the web development stack — but on the server, not in the browser."
Says who? What's the rationale for where a language belongs?
"Although templating is the correct solution, doing it in the browser is fundamentally wrong. The cost of application maintenance should not be offloaded onto all their users’s browsers (we’re talking millions of hits per month here) — especially not the mobile ones. This job belongs on the server."
Again, based on what?
"My point is that I expected far more front-enders to embrace Angular. I have the feeling their number is surprisingly low — see also the problems my clients had with finding good front-end Angular consultants. "
More stuff based on feeling rather than empirical evidence. And clients have trouble finding good front-end developers these days no matter what the technology is.
"A more important reason may be pushback from the JavaScript community. Angular has evoked some serious criticism."
Find me a framework that hasn't evoked serious criticism from some corner of the Internet.
Look, I'm no fan of Angular. In fact I've never written a thing in it. It doesn't really fit my style of front-end development (and I'm a Java programmer!). I'm more of a libraries-over-frameworks guy. But this article is not very well-reasoned.