Since the early days of the web, large corporations have seemingly always wanted more than the web platform or web standards could offer at any given moment. Whether they were aiming for cross-platform-compatibility, more advanced capabilities, or just to be the one runtime/framework/language to rule them all, there’s always been a company that believes they can “fix” it or “own” it.
Applets. ActiveX. Flash. Flex. Silverlight. Angular. React.
I really enjoyed this interview between Drew and Chris. I love that there’s a transcript so you can read the whole thing if you don’t feel like huffduffing it.
Excellent in-depth research by Tim on how the major frameworks affect performance. There are some surprising (and some unsurprising) findings in here.
I wish with all my heart that this data would have some effect but I fear there’s an entire culture of “modern” web development that stick its fingers in its ears and say “La, la, la, I can’t hear you.”
A very welcome project from Marcus Herrmann, documenting how to make common interaction patterns accessible in popular frameworks: Vue, React, and Angular.
Dave on the opaqueness of toolchains:
As toolchains grow and become more complex, unless you are expertly familiar with them, it’s very unclear what transformations are happening in our code. Tracking the differences between the input and output and the processes that code underwent can be overwhelming. When there’s a problem, it’s increasingly difficult to hop into the assembly line and diagnose the issue.
There’s a connection here to one of the biggest issues with what’s currently being labelled “AI”:
In the same way AI needs some design to show its work in how it came to its final answer, I feel that our automated build tools could use some help as well.
I really like this suggestion for making the invisble visible:
I sometimes wonder if Webpack or Gulp or [Insert Your Build Tool Here] could benefit from a Scratch-like interface for buildchains.
Another deep dive into web history, this time on JavaScript. The timeline of JS on the web is retroactively broken down into four eras:
Nice to see “vanilla” JavaScript making a resurgence in that last one.
It’s 2017, the JavaScript ecosystem is both thriving and confusing as all hell. No one seems to be quite sure where it’s headed, only that it’s going to continue to grow and change. The web’s not going anywhere, which means JS isn’t going anywhere, and I’m excited to see what future eras bring us.
Here’s Paul’s write-up of his excellent talk at FF Conf.
Previously I’ve used the term “developer convenience” when describing the benefits of using a framework. Paul uses the term “ergonomics” to describe those benefits. I like that. I worry sometimes that the term “developer convenience” sounds dismissive, which isn’t at all my intention—making our lives as developers less painful is hugely important …but it’s just not as important as improving the lives of the end users (in my opinion …and Paul’s).
As I look at frameworks, I see the ergonomic benefits (and those are important, I agree!), but I can’t help but feel that, for many developers, investing in knowledge of the web platform itself is the best long-term bet. Frameworks come and go, it just seems to be the ebb and flow of the web, and, as I said above, they do contribute ideas and patterns. But if you ever find that the one you use no longer works for you, or has a bug that remains unfixed, being able to understand the platform that underpins it will help enormously.
This was one of favourite talks at this year’s FF Conf. But I will readily admit there’s a hefty dollop of confirmation bias in my enjoyment.
![6. You should use [insert library/framework], it's the bestestest! / Paul Lewis](https://i.ytimg.com/vi/_yCz1TA0EL4/maxresdefault.jpg)
A superb piece by Ross Penman on the importance of being true to the spirit of the web.
I was chatting with some people recently about “enterprise software”, trying to figure out exactly what that phrase means (assuming it isn’t referring to the LCARS operating system favoured by the United Federation of Planets). I always thought of enterprise software as “big, bloated and buggy,” but those are properties of the software rather than a definition.
The more we discussed it, the clearer it became that the defining attribute of enterprise software is that it’s software you never chose to use: someone else in your organisation chose it for you. So the people choosing the software and the people using the software could be entirely different groups.
That old adage “No one ever got fired for buying IBM” is the epitome of the world of enterprise software: it’s about risk-aversion, and it doesn’t necessarily prioritise the interests of the end user (although it doesn’t have to be that way).
In his critique of AngularJS PPK points to an article discussing the framework’s suitability for enterprise software and says:
Angular is aimed at large enterprise IT back-enders and managers who are confused by JavaScript’s insane proliferation of tools.
My own anecdotal experience suggests that Angular is not only suitable for enterprise software, but—assuming the definition provided above—Angular is enterprise software. In other words, the people deciding that something should be built in Angular are not necessarily the same people who will be doing the actual building.
Like I said, this is just anecdotal, but it’s happened more than once that a potential client has approached Clearleft about a project, and made it clear that they’re going to be building it in Angular. Now, to me, that seems weird: making a technical decision about what front-end technologies you’ll be using before even figuring out what your website needs to do.
Ah, but there’s the rub! It’s only weird if you think of Angular as a front-end technology. The idea of choosing a back-end technology (PHP, Ruby, Python, whatever) before knowing what your website needs to do doesn’t seem nearly as weird to me—it shouldn’t matter in the least what programming language is running on the server. But Angular is a front-end technology, right? I mean, it’s written in JavaScript and it’s executed inside web browsers. (By the way, when I say “Angular”, I’m using it as shorthand for “Angular and its ilk”—this applies to pretty much all the monolithic JavaScript MVC frameworks out there.)
Well, yes, technically Angular is a front-end framework, but conceptually and philosophically it’s much more like a back-end framework (actually, I think it’s conceptually closest to a native SDK; something more akin to writing iOS or Android apps, while others compare it to ASP.NET). That’s what PPK is getting at in his follow-up post, Front end and back end. In fact, one of the rebuttals to PPKs original post basically makes the exactly same point as PPK was making: Angular is for making (possibly enterprise) applications that happen to be on the web, but are not of the web.
On the web, but not of the web. I’m well aware of how vague and hand-wavey that sounds so I’d better explain what I mean by that.
The way I see it, the web is more than just a set of protocols and agreements—HTTP, URLs, HTML. It’s also built with a set of principles that—much like the principles underlying the internet itself—are founded on ideas of universality and accessibility. “Universal access” is a pretty good rallying cry for the web. Now, the great thing about the technologies we use to build websites—HTML, CSS, and JavaScript—is that universal access doesn’t have to mean that everyone gets the same experience.
Yes, like a broken record, I am once again talking about progressive enhancement. But honestly, that’s because it maps so closely to the strengths of the web: you start off by providing a service, using the simplest of technologies, that’s available to anyone capable of accessing the internet. Then you layer on all the latest and greatest browser technologies to make the best possible experience for the most number of people. But crucially, if any of those enhancements aren’t available to someone, that’s okay; they can still accomplish the core tasks.
So that’s one view of the web. It’s a view of the web that I share with other front-end developers with a background in web standards.
There’s another way of viewing the web. You can treat the web as a delivery mechanism. It is a very, very powerful delivery mechanism, especially if you compare it to alternatives like CD-ROMs, USB sticks, and app stores. As long as someone has the URL of your product, and they have a browser that matches the minimum requirements, they can have instant access to the latest version of your software.
That’s pretty amazing, but the snag for me is that bit about having a browser that matches the minimum requirements. For me, that clashes with the universality that lies at the heart of the World Wide Web. Sites built in this way are on the web, but are not of the web.
This isn’t anything new. If you think about it, sites that used the Flash plug-in to deliver their experience were on the web, but not of the web. They were using the web as a delivery mechanism, but they weren’t making use of the capabilities of the web for universal access. As long as you have the Flash plug-in, you get 100% of the intended experience. If you don’t have the plug-in, you get 0% of the intended experience. The modern equivalent is using a monolithic JavaScript library like Angular. As longer as your browser (and network) fulfils the minimum requirements, you should get 100% of the experience. But if your browser falls short, you get nothing. In other words, Angular and its ilk treat the web as a platform, not a continuum.
If you’re coming from a programming environment where you have a very good idea of what the runtime environment will be (e.g. a native app, a server-side script) then this idea of having minimum requirements for the runtime environment makes total sense. But, for me, it doesn’t match up well with the web, because the web is accessed by web browsers. Plural.
It’s telling that we’ve fallen into the trap of talking about what “the browser” is capable of, as though it were indeed a single runtime environment. There is no single “browser”, there are multiple, varied, hostile browsers, with differing degrees of support for front-end technologies …and that’s okay. The web was ever thus, and despite the wishes of some people that we only code for a single rendering engine, the web will—I hope—always have this level of diversity and competition when it comes to web browsers (call it fragmentation if you like). I not only accept that the web is this messy, chaotic place that will be accessed by a multitude of devices, I positively welcome it!
The alternative is to play a game of “let’s pretend”: Let’s pretend that web browsers can be treated like a single runtime environment; Let’s pretend that everyone is using a capable browser on a powerful device.
The problem with playing this game of “let’s pretend” is that we’ve played it before and it never works out well: Let’s pretend that everyone has a broadband connection; Let’s pretend that everyone has a screen that’s at least 960 pixels wide.
I refused to play that game in the past and I still refuse to play it today. I’d much rather live with the uncomfortable truth of a fragmented, diverse landscape of web browsers than live with a comfortable delusion.
The alternative—to treat “the browser” as though it were a known quantity—reminds of the punchline to all those physics jokes that go “Assume a perfectly spherical cow…”
Monolithic JavaScript frameworks like Angular assume a perfectly spherical browser.
If you’re willing to accept that assumption—and say to hell with the 250,000,000 people using Opera Mini (to pick just one example)—then Angular is a very powerful tool for helping you build something that is on the web, but not of the web.
Now I’m not saying that this way of building is wrong, just that it is at odds with my own principles. That’s why Angular isn’t necessarily a bad tool, but it’s a bad tool for me.
We often talk about opinionated software, but the truth is that all software is opinionated, because all software is built by humans, and humans can’t help but imbue their beliefs and biases into what they build (Tim Berners-Lee’s World Wide Web being a good example of that).
Software, like all technologies, is inherently political. … Code inevitably reflects the choices, biases and desires of its creators.
When it comes to choosing software that’s supposed to help you work faster—a JavaScript framework, for example—there are many questions you can ask: Is the code well-written? How big is the file size? What’s the browser support? Is there an active community maintaining it? But all of those questions are secondary to the most important question of all, which is “Do the beliefs and assumptions of this software match my own beliefs and assumptions?”
If the answer to that question is “yes”, then the software will help you. But if the answer is “no”, then you will be constantly butting heads with the software. At that point it’s no longer a useful tool for you. That doesn’t mean it’s a bad tool, just that it’s not a good fit for your needs.
That’s the reason why you can have one group of developers loudly proclaiming that a particular framework “rocks!” and another group proclaiming equally loudly that it “sucks!”. Neither group is right …and neither group is wrong. It comes down to how well the assumptions of that framework match your own worldview.
Now when it comes to a big MVC JavaScript framework like Angular, this issue is hugely magnified because the software is based on such a huge assumption: a perfectly spherical browser. This is exemplified by the architectural decision to do client-side rendering with client-side templates (as opposed to doing server-side rendering with server-side templates, also known as serving websites). You could try to debate the finer points of which is faster or more efficient, but it’s kind of like trying to have a debate between an atheist and a creationist about the finer points of biology—the fundamental assumptions of both parties are so far apart that it makes a rational discussion nigh-on impossible.
(Incidentally, Brett Slatkin ran the numbers to compare the speed of client-side vs. server-side rendering. His methodology is very telling: he tested in Chrome and …another Chrome. “The browser” indeed.)
So …depending on the way you view the web—“universal access” or “delivery mechanism”—Angular is either of no use to you, or is an immensely powerful tool. It’s entirely subjective.
But the problem is that if Angular is indeed enterprise software—i.e. somebody else is making the decision about whether or not you will be using it—then you could end up in a situation where you are forced to use a tool that not only doesn’t align with your principles, but is completely opposed to them. That’s a nightmare scenario.
I have doubts about Angular 1.x’s suitability for modern web development. If one is uncharitably inclined, one could describe it as a front-end framework by non-front-enders for non-front-enders.
The Filament Group run the numbers on how long it takes browsers to parse the JavaScript of popular MVC frameworks: Backbone, Angular, and Ember. The results—especially on mobile browsers—are not encouraging.
It’s funny: while I agree with the warning that this article provides (“rich client-side JavaScript frameworks aren’t a good fit for every site, especially content sites”), the reasons given here aren’t the reasons that I have any issues with.
I despair sometimes.
Here’s a ridiculous Heath-Robinsonesque convoluted way of getting the mighty all-powerful Googlebot to read the web thangs you’ve built using the new shiny client-side frameworks like Angular, Ember, Backbone…
Here’s another idea: output your HTML in HTML.
That solution works for machines and humans. As a bonus, outputting your HTML in HTML avoids turning JavaScript into a single point of failure.