Prolog: I’m making this a separate topic because I don’t want to be responsible for diverting any more of Chris’s valuable time - especially as the core notion of this topic isn’t actually about his work.
Conclusion for the impatient:
As mobile is becoming the primary means of consumption for web (i.e. internet accessible) content, it is becoming increasingly important for businesses and organizations to unify the means of deployment for their content. For the time being “native apps” are still seen as the superior delivery platform.
However over the long haul supporting two separate mobile platforms in addition to the desktop browser is only affordable for more affluent organizations - and likely even wasteful for them. For a minority of use cases “native apps” will always be superior - BUT for the majority of cases it is more important to have a more cost effective, unified solution for which currently the “browser-based client application” is the best candidate. That is not to say that all use cases require a fully featured rich UI - in many cases web sites which are designed “mobile first” can be sufficient.
It still is imperative that the capabilities of browser-based client applications are developed even further so that the gap to “native apps” can be further narrowed. That way the consumption platform for the majority of use cases can be unified. To that end browsers have already access to the Push and Geolocation APIs and others will likely be added in the future (Geofencing has been abandoned for the time being).
Essentially the mobile web needs to get to the point where it is no longer percieved as playing second fiddle to native apps without resorting to “hybrid” approaches. (And really that is what PWAs seem to be about).
Longwinded leadup:
The avalanche has already started. It is too late for the pebbles to vote.
My intent wasn’t to imply that whatever the “big boys” are pushing is “the best”. Far from it - they have enough resources to push sub-optimal solutions to ridiculous extremes. But I’m also not blind to the fact that technologies promoted and endorsed by them can have a foot-in-the-door with a significant segment of the rest of the industry (e.g. Go). Typically the only way they can be countered is with “disruptive” technologies - simply ignoring what they are up to isn’t going to have beneficial consequences though it is important to not succumb to their games of fire and motion.
This is what I find most disconcerting - whiplash technology choices as a response to the JS ecosystem as it exists today. The browser is an essential part of the human-facing web experience and JS is as much part of that as HTML/CSS. So it seems incredibly counter productive to develop or even nurse an aversion to any of the three. And I argue that (vanilla) ECMAScript has improved a lot in more recent years (… still not perfect, nothing ever will be).
Now a slight change in direction:
When somebody calls themself a “Rails developer” or a “PHP developer” is that a bad thing? (Deliberately sticking to “web technologies” here). In itself it isn’t, especially as long as they find themself in situations where they are handed problems that these technologies were designed to solve and as long as they stay within the design constraints of the tool. Where it gets interesting is when the tool is an ill fit for a particular problem - what will this developer do?
- Distort the problem to fit the tool?
- Declare it can’t be done because the tool doesn’t fit the problem?
- Adapt and pull in technologies from outside of the purview of “X developer” - possibly stepping outside of “X”?
To me, it’s incongruous for anyone to work with the “human-facing web” and to somehow expect to get away without JavaScript - I don’t care what “X developer” label they adorn themselves with.
Similarly we have somehow arrived at a situation where it seems justifiable to know only one of way rendering something onto a browser - it seems while one would expect “(insert your favourite framework) developer” to have some competence in JavaScript also expecting in-depth understanding of HTML, CSS, and browser APIs (and how a browser in general functions) is pushing it.
What I’m getting at is that there is a full range of implementation choices when it comes to “rendering in the browser” from static pages to SPAs. But somehow the basic static page gets mostly ignored (because it’s static) which means that people immediately jump onto some batteries included JS framework. So time is pumped primarily into tackling the framework’s learning curve while investment into learning the browser fundamentals is sacrificed.
When it comes to web technology I believe that it is necessary for implementers to have a better awareness of a broader spectrum of the different types of browser-based solutions - most of which involve JavaScript of some kind. That doesn’t meant knowing every SPA framework under the sun but knowing how to achieve “just a little bit of interactivity” with a modest amount of HTML/CSS(/JS).
Nicholas Zakas: Enough with the JavaScript Already (2013) (slides, GitHub)
That being said, do I think that browser-based client applications are important?
Yes. But that doesn’t mean everything needs to be an SPA. I’ll the first one to admit that there seems to be a void right now for anyone needing a “modestly interactive” browser-based solution. I think the JS ecosystem is suffering from “libraries run amok” - i.e. mindless library creation and use. Somehow this has lead to the acceptance of bloat and complexity - often without much value in return. But to denounce (and ignore) the importance of JavaScript because of the current state of its ecosystem is essentially “throwing out the baby with the bathwater”.
« inject above conclusion here »
By extension anyone who is betting on the web but is unwilling to “play inside the browser” (which for the time being invariably leads to some use of ECMAScript somewhere) is painting themselves (and their users/customers/clients) into a corner.
