The Web’s Declarative, Composable Future

The scoping and the interface-definition are certainly the most promising aspects of this. I'm still very skeptical of using the DOM for non-UI purposes, but it could work out and that would be great. But even if not, even if it's just for GUI tasks, it's a win. I know bootstrap's components make life much easier in the common cases, and the concept is similar (but cleaner) here.

5. Where in npm (I've no clue what that is) can I find: 1. a calendar widget to put on my page? 2. an email, password, confirm password form to put on my page?

You're not getting his point.

Yeah, you can make some pretty amazing applications with HTML/CSS/JS, but it's unnecessarily hard, you have to fight against the platform constantly, and the only reason why we do it is because we currently have no good alternative. Don't let the status quo blind you to the possibilities of how much better portable networked applications could be.

I don't want to bore everyone with some huge post, but among other things:

1. It's full of awkward edge cases. (See the 'Wat?' talk for numerous examples.) This is bad generally, and terrible if you want to use the language as a least common denominator foundation on which other languages and tools might be built.

2. It has little if any meaningful support for things like modularity, composition, separation of interface from implementation, and other basic software development good practices.

3. It is highly dynamic. This is good for prototyping and small, quick enhancements to web pages, which is what we used to use JS for. However, it is not good for building stable, robust, secure, large-scale systems that will be built and maintained by lots of people over extended periods, which is what we (reportedly) want to do with the Web now.

4. It doesn't work like any other major programming language. Hardly anyone seems to use prototype-based inheritance well, and most of those who do are probably experts working on libraries rather than everyday web developers. It seems more common for people to try and use class-style OO with JS, first resulting in a lot of ugly hacks, and I gather soon resulting in various syntactic sugar being built into a future version of the language, making this area not just esoteric but also more complicated. Don't even get me started on function-based scoping rules, whose primary functions in JavaScript appear to be being abused to make up for the lack of any sane module system and causing frustration to JS beginners whose loops don't do what they "obviously" should (and would in just about any other mainstream language).

With custom elements, we can extend that simple language to our liking. There are no bounds anymore.

Not really. You can add new vocabulary, but you can't change the grammar. In particular, you're still essentially assuming that the application is built around one big hierarchy of elements in a DOM. Except that then we get to Shadow DOM to try and work around that. And now we're back to trying to do modularity, but making what should be a trivial and widely used concept absurdly overcomplicated. Again.

Problem? We write in Sass/Less/Stylus/etc. which are capable languages that are continuously improved.

Sure, and so do I. But no matter which preprocessing tools we use, CSS is still woefully underpowered for designing even moderately complicated web pages, never mind full-on user interfaces, and while SASS and the like are great for things like shorthand notations/macros, they ultimately still get turned into CSS and rely on its limited/broken models.

At least these days we can use box-sizing to fix one of the long-standing headaches, but we still rely on abuses like combining floats and negative margins to set up layouts. You still can't specify even very simple dynamic layouts that adapt to the actual size of content; a lot of Web developers still think a concept as simple Responsive Design is clever, because in Web world it is, but UI designers building native applications have been working around similar problems for several decades.

For that matter, a bunch of awkward dependencies still exist between CSS and the order of elements you give in HTML, so you can't fully separate content from presentation and keep your layout away from the content you put in it. Consider the impact of order of mark-up on how floats are rendered, for example, or the need for extra wrapper elements so you can set position:fubar on things to get your latest layout hack to work. Web Components offer various tools for hiding some of this, but the same junk is still happening under the hood, and it's still creating complexity for both those who develop the components and those who write the browsers.

What do you mean? You can separate [content, presentation and behaviour] just fine.

No, you can't. You might think you can, but every now and then you run into the kinds of examples I mentioned above, which you can't fix because the underlying HTML and CSS models were designed for a different purpose and are broken for what you want to do with them. Then you have to resort to JS to work around the problem, which is time-consuming and gives up the whole idea of specifying a layout and then putting the content into it in the way we're usually trying to.

npm is full of tools for this. You can have modularity in your source code and rely on tasks to package it for production.

But npm doesn't run in browsers, so now everything is complicated by yet another up-front build tool, which seems to be the modern web developer's answer to everything. And sure, it works, as long as someone is wasting huge amounts of time writing and maintaining all those tools, and as long as the tools always work properly, and as long as everyone knows how to use them, and as long as everyone agrees on which "them" to use, and a whole bunch of other overheads that are a systemic drain on the efficiency of the entire development process.

The thing is, I shouldn't have to rely on a bunch of infrastructure to do something as simple as writing modular code for a large-scale application. It should be a completely stable, simple, universally applicable feature in any serious programming language, and doing things like making code available as a module with a clearly defined interface or accessing code from somewhere else via that interface should be one-liners. JavaScript, and the numerous related tools from npm to RequireJS via who even knows how many others now, aren't even in operating the same universe as I'm describing.

Also, please note that I wasn't just talking about JavaScript there. Both HTML and CSS have related problems, and again, while there are some changes in the works to help work around these issues, the basic models are fundamentally broken. Why should any serious, large-scale application start from the idea that a single page of mark-up/single DOM should be the foundation on which everything else, including any code and stylesheets and other HTML/DOM data for different parts of the system, should be found? The entire premise is kind of absurd, if you stop and think about it, but because the Web offers us no real alternative today, the average Web designer/developer doesn't get that far or just resigns themselves to dealing with it anyway...

Edit: I see the parent post has grown some more questions while I wrote this, but this post is way too long already so I don't think I should extend it any more.

And that in itself is great. But the applicability of that encapsulation seems very limited in the current proposals. Effectively, everything is still tied back to the DOM, but there is a lot more to serious applications than drawing stuff on the screen, so unless we're going to keep doing all of that server-side...

Also, you need two key things for modular design to work: ways to build modules, and controlled ways to connect them together. I'm rather sceptical about whether Web Components are going to live up to the hype in this respect, because while you might have a new tool for encapsulation to help with the "building" part, you're still ultimately relying on JavaScript to connect up the behaviour for these new components and on CSS to connect their visual appearance to the rest of your design, with no new composition tools to make like easier in either case.

I can understand the motivation for some parts of Web Components, such as the Shadow DOM, but a lot of it just feels like a marginal improvement on things we already have. After all, it's not as if I can't Google 47 different libraries that will turn a <div> into a set of tabs or a carousel right now, and they all come with a handy JS interface for connecting the rest of my code into the behaviour of that page element, and they all come with styling hooks or theme builders for me to configure the aesthetics. Am I really going to achieve some huge productivity or maintainability boost if I use a custom element instead of a <div> and I read the docs on that custom element's JS and CSS hooks instead of the ones from some UI library like the ones we've been building for the past 5-10 years?

I've waited a few years for the HTML5 app platform future to arrive and I've realized two things. First, it isn't happening, at most someone is going to build a new app platform partly out of old bits and pieces and that will have questionable uptake. Second, as far as we do get there the result will still not be clearly better than "native apps."

So I am not waiting for the HTML5 future to save us all from native apps any more.

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.

Strictly speaking that's probably true, but I'd like to be clear that I'm not really deriding the idea of preprocessors, but rather the need to use preprocessors to make up for weaknesses in the underlying technology that shouldn't be there.

Any time you start talking about a build process, you're talking about introducing (and subsequently managing) overheads. If adding that extra step is a big win for some other reason, the overhead is worth it. But if adding that extra step just brings you up to where everyone else was in the first place, your underlying platform isn't good enough.

Put another way, I think it's crazy how often I find a potentially interesting library for building a modern web page/app, but then the getting started page starts with something like "First install package management library P and with that get dependency management tool D, then create configuration file F, featuring dependencies A, B and C, run setup script S to install those dependencies and create scaffolding S', and now you have a complete project ready to go that includes only 3 levels of directory hierarchy and 17 files to start you off so you can follow the 'Hello, world' tutorial." That is an absurd amount of hassle just to get something going in a quick experimental project and see whether it's actually any good, and it amplifies the problems already caused by having so much fragmentation and NIH syndrome in front-end development today.

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.

That's a fair point, but I suggest to you that there is a flip side: when we build new tools today we also have the wisdom of hindsight. We have several decades of general software development experience to draw on that the guys building early tools in languages like C and the guys who developed the first GUI libraries didn't. And this is really the heart of my problem with the current situation: we don't seem to be paying any attention to those lessons, or the flashing neon signs that developers who went before us installed to warn us never to tread this path again.

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”.

I almost rose to that challenge, but then I realised it was missing the point. You can write a word processor in assembler, and some people have, but just because it's possible, that doesn't mean it's an efficient way to do it with the other tools and techniques we have available today.

But regardless, without presenting clear ideas on what a better path would be, I'm concerned your complaints aren't truly useful

The problem with modern web development is that instead of trying to build tools that are comparable with the best we've developed elsewhere, learning from the greater experience of other software developers and DBAs and sysadmins and UI designers and all the rest, we're taking it as axiomatic that we have to build on what's already there.

Why should we do that? The amount of resources being thrown into new web standards and languages and preprocessors and tools across the industrial as a whole is vast, and it already includes several projects on a scale not very far from building the kind of "portable Web assembly language" or "powerful, flexible, extensible layout model" concepts I'm talking about. Just think about all the new rendering engines, JS runtime environments, X-to-JavaScript compilers, X-to-CSS compilers, and so on that have been built in recent years.

I don't claim to be nearly as creative or smart as, for example, the people who developed tools like SASS. But such tools have been developed, and have been very successful, and we can learn a lot from that both in terms of what is possible and how much easier good tools can make the development process. We can also learn a lot from where even those tools haven't been as successful, because as preprocessors they are inherently limited by their target format.