The Web’s Declarative, Composable Future

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 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 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?

Have you spent any time looking at Clojurescript and David Nolen's work; React; Chrome dev tools; LightTable's integration with the browser; Atom; etc? Smart people are doing smart stuff.

One other point I wanted to mention: I've worked with other UI frameworks for developing what you call "serious" applications, such as MFC, Windows Presentation Framework, QT, and others.

The web may suck, but all those options completely, also, sucked. Nobody knows how to build UIs yet.