The Web’s Declarative, Composable Future

Not at all, I just don't accept the premise that newer means better. There is more hype in the (front end) Web development industry right now than I have ever seen in any part of the software development world in several decades of working in the industry, and this is rarely a good sign.

To be specific, I think one of the things that has made the Web successful as a medium for both sites and more recently apps is its relative simplicity. This has allowed for a good degree of ubiquity and portability even when standardisation wasn't perfect. It also, importantly, made the field accessible to many new people. Even relatively non-technical folk could put together a simple web site by reading a few tutorials, and a beginner to "serious" web design/development could get up to speed within a reasonable period.

As we try to do more demanding things with the Web, some increase in complexity is probably inevitable, but that complexity has a cost. The limitations of the underlying foundations become more and more of a drag on progress for the whole industry the further we move in that direction. It will become harder and harder to change course the more people and organisations have committed to the current path. The signs are already there that even the big names can't get this right today -- try using almost any of Google's web apps on an iDevice at the moment, for example -- and it's great that there is so much enthusiasm for fixing the things that don't work well as they are. I just wish there was more interest in whether we've got the right answers to the most basic questions before we get too bogged down in relatively minor details.

You deride the use of preprocessors and such in other places in this thread, saying that there's a lot of people sinking resources into that, so I have to ask you: do you consider it a hack that you code in Clojure, or Java, or Haskell, or C, instead of coding in assembly? Is it a loss of resources that people are working on compilers for these languages? Is it a hack to code in assembly instead of directly emitting machine code? If the current web stack is the unintended result of a one-night stand between modern C++ and VB6, what is x86-64?

The biggest differences between current web technologies and the above analogies are: - Stuff built on top of current web technologies hasn't been under development for nearly as long as stuff built on top of machine code. - The basis here (HTML/CSS/JS) is actually relatively simple for someone who knows nothing about the web to get started with, to build something they can interact with quickly.

The biggest obstacles to using it properly even as a basis to build new tools and abstractions on top of have been, IMO, limitations in CSS (though with absolute positioning even those have been worked around effectively in tools like GWT) and primitive drawing, and flexbox and related developments + canvas have started to clear the most glaring of those issues up.

“You can't fix the latter using any combination of JavaScript, HTML and CSS, no matter how big a number you put after them.”

Big words. I will give you a challenge: come up with an idea, and I posit folks will come up with a way to implement it on top of these “broken models”.

In short, I have no idea how you're reaching the conclusions you're reaching, or what it is that makes what's there now not a “portable assembly language”. But regardless, without presenting clear ideas on what a better path would be, I'm concerned your complaints aren't truly useful—and are also needlessly difficult to understand. Complaints about the stack aren't new. Improvements are—and there are plenty of people making them, albeit layered on top of what's there.

But it's true -- we had nice, established patterns for client-server applications and we go through more and more hacks to give it the same usability as a VB6 app over a decade ago in twice the hours.

To be fair, people have tried to solve it. Remember applets? For some reason, they never caught on. I worked on flex apps, and the only problem was that it depended on the flash plugin, was expensive, and had some maddening incongruities of its own. Others have tried and failed as well, because the web, to most people, is good enough.

We're in a "worse is better" kind of situation now. Plan 9 may have been better than Unix, VAX may have been better, but they didn't win.

If you want to get the gist of Web Components, there's a good 30 min talk by Eric Bidelman: https://developers.google.com/events/io/sessions/318907648

> What really remains to be seen is whether this reduces or increases complexity.

One word: scoping

This is an important concept in software development that we've severely lacked on the web. We're used to creating global documents of HTML, CSS, and JS and hoping it doesn't explode. Frankly it's a mess. I'm surprised we've put up with it for so long! The technologies behind web components (Shadow DOM and Custom elements in particular) empower us web devs to be good developers. That is, we can take advantage of patterns like OOP: compartmentalize and scope functionality to a particular problem space.

CSS/DOM encapsulation is an added benefit to tell this story. As a developer, I no longer have to hunt down what CSS is effecting my page. I just look at the element's definition.

The hope with all of this stuff is that there's less re-inventing the wheel and more productivity. Scoping takes us to this happy place. Unlike most new web platform APIs, the web component APIs are purely about developer ergonomics. It's about your productivity. That makes me super happy...both as a web dev and someone who teaches web devs.

> Like Addy points out ("not a silver bullet") performance, security,...

Nothing in web development is a silver bullet :) A best practice today may be an anti-pattern tomorrow. However, with components, we have the opportunity to bake in more for free. For example, accessibility is low on people's radar. If a component set takes care of the details for me, I'm a happy camper.

Nothing changes in regards to security. In fact, the API specs leave it out entirely. When people hear "encapsulation", they automatically think security. IMO, it's better to think about components as "scopes".

> ...one of Polymer's example components was an Ajax call, which I suppose you can fire from the script. Is that really better than putting the ajax parameters in the code?

Web components allow us to rethink what HTML can be; what it can do. We have to unlearn years (possibly) decades of assuming that HTML can provide no useful API. When given a declarative vs imperative API, I suspect 9/10 developers will go the declarative route. It's unquestionably easier.

`` is a good example of providing an a hybrid. It defines an imperative API on its DOM interface and a declarative one by configuring it through attributes and listening for events. Is the declarative route better? Perhaps. The point is that it encapsulates the details of using XHR. I'm excited to never NEVER write that boilerplate XHR code again.

Ajax is also a trivial example. The cognitive load of being a web developer is oftentimes too high. You can imagine more complex APIs and libraries (webrtc, webgl, etc) being offered as declarative custom elements. A declarative option makes those underlying technologies more convenient/approachable to others.

> Does it encourage "globals"-like behavior, where hidden dependencies crop up?

Components encourage the opposite. When used correctly, HTML Imports provides the necessary dependency management. If an element requires script x and element y, those deps can be included/bundled as an Import for the component.

> Are there life-cycle behaviors to the Ajax component that might trigger the request at surprising or frustrating times?

There's nothing stopping component authors from shooting themselves (or their users) in the foot. It's my hope that well-written components will surface to the top of the stack. If a component is naughty, no one will use it.