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.
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.
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 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 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.
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.
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 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.
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).
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).
"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.
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.
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).
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.
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.
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.
> "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.
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.
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.)
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/
"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.
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...
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.
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.
>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.
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.
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.
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.
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.
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.
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.
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.
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"
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 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.
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 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.
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.
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.
> 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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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).
> 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.
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.
> 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).
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 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.
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.
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 :(
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".
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.
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.
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.
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.
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.
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.
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.
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.
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...
> 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 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.
"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.
"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'
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.
244 comments
[ 5.7 ms ] story [ 258 ms ] threadI 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.
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.
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.
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.
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.
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.
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.
"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.
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.
Dang should we not flag this stuff?
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).
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.
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.
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. 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 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).
s/idling/conserving battery life/
much of the original article's criticism was aimed at angular apps on mobile devices.
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.)
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.
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.
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.
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.
A lot of the stuff I wrote there is still relevant.
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.
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).
> I think the point is that Angular criticism is much more prominent (and sometimes vitriolic) than other frameworks.
That always happens to frameworks that get widespread usage. If your framework doesn't have vocal groups of haters, it is not successful.
I suspect this happens when frameworks start to be mandatory by decree in organizations.
> 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/
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.
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...
[0] https://docs.angularjs.org/guide/bootstrap
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.
See http://modernweb.com/2014/03/24/string-templating-considered... for a recent overview that is pretty decent. Boris Moore did a lot of publishing about it, as I recall.
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.
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.
1) those who have used Angular, been burned by it and are now sour about it;
2) those who haven't used Angular but hate {JavaScript|frameworks|SPAs|the web|anything popular} out of principle.
The first category includes both those who hate it because they don't understand it and those who hate it precisely because they do understand it.
I wouldn't say I hate Angular, but I'd like to think of myself as being in the latter subset of the first category.
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.
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.
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.
I'm sincerely interested. What did you pick and for what reasons? How did it end?
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.
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.
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.
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.
[1] https://blog.twitter.com/2012/improving-performance-on-twitt...
Reminds me of this article by Joel Spolsky: http://www.joelonsoftware.com/articles/FiveWorlds.html
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
Rendering public, read-only content such as a tweet, however, makes total sense to cache on the server.
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.
There's always exceptions to every rule though.
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.
But yeah, anyone here work webdev where your webapp is expected to fully work without client-side javascript?
Good control for JS and other requests in browsers makes this quite convenient to control as a (expert) user. I like umatrix a lot.
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.
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.
1.https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
Why not block Google at your router?
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".
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).
_You_ don't, the customer does.
Would you care to name the sites you work on so I can stay away?
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).
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.
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.
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.
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 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.
Not, it's rational if your serving a web application instead of a web document. Most pages written with AngularJS are web applications.
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".
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.
[1] http://en.wikipedia.org/wiki/Edge_Side_Includes
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.
You will be surprised that difference between the two will be less than 1%.
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.
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.
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.
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.
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.
RPG ran on the AS/400 and your DSPF (display file) ran on the terminal. DSPFs did screen layout, validation, etc...
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.
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.
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.
"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'
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.