The Web’s Declarative, Composable Future(addyosmani.com)
addyosmani.com
The Web’s Declarative, Composable Future
http://addyosmani.com/blog/the-webs-declarative-composable-future/
5 comments
These are legitimate concerns to have. There are many new technologies at play in this space and a lot of new concepts.
> 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.
`<polymer-ajax>` 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.
> 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.
`<polymer-ajax>` 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.
Yeah, good thoughts, time will tell. We could go back and forth on some of the finer points, but that's better over a beer than a forum.
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.
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.
Beers!
It's 100% bizarre to think about elements that don't render UI. Honestly, I'm still wrapping my head around it.
If you think about it though, there are plenty examples today that don't render UI (directly) but serve a specific purpose: <script>, <meta>, <html>, <style>, <head>, <title>, <link>, ....
Search for "display: none": http://src.chromium.org/viewvc/blink/trunk/Source/core/css/h...
Interesting times indeed.
It's 100% bizarre to think about elements that don't render UI. Honestly, I'm still wrapping my head around it.
If you think about it though, there are plenty examples today that don't render UI (directly) but serve a specific purpose: <script>, <meta>, <html>, <style>, <head>, <title>, <link>, ....
Search for "display: none": http://src.chromium.org/viewvc/blink/trunk/Source/core/css/h...
Interesting times indeed.
I'm worried about the direction the web is going in right now. I think a lot of the "progress" is being pushed by people whose agenda is building browsers and possibly certain very large and high profile web apps, and not so much by the people whose agenda is simply building good web sites. I also think a lot of the agenda is being pushed by people who want to move fast and break things.
The trouble is, the web sucks as a platform for developing serious applications, because that's never what the technologies were intended to support. It offers only one major programming language, and that language is horrible. It offers one DSL that was designed to mark up content in simple ways and has been abused to fill some sort of ill-fitting UI description role. It offers another DSL that was designed for basic presentation functions, based on underlying models so bad that almost everyone ignores or overrides them even to the extent of building preprocessing tools to paper over the gaps. It offers limited separation of concerns in terms of content, presentation and behaviour, yet the promotion of web components seems determined to erode that separation even further. It offers almost no tools for modularity or composition in any of the three fundamental pillars everything is built with, and with a small number of exceptions even the various proposals to improve this don't look that promising so far.
We've seen this before, and we know how the story ends, if you just stop pretending the Web is somehow a special thing and look at general software development. The modern web being pushed by the likes of Google and Mozilla looks increasingly like the unintended result of one-night stand between modern C++ and VB6. It's all about papering over the cracks and shoe-horning existing tools into roles for which they are completely unsuited. This approach will get you so far, and then it will fail, as it always does.
We would do much better if we redirected all the recent enthusiasm for improving the Web. We can still recognise what has made the Web successful: essentially, it offers a ubiquitous, readily understood, cross-platform, client-server model for letting normal people interact with services running on someone else's system. But then we can also recognise the forces that are limiting web development today: lack of a real "portable assembly language" and run-time environment that a diverse range of programming languages can use as a stable, secure, reliable foundation; and the lack of a clean, flexible model for presentation and interaction.
You can't fix the latter using any combination of JavaScript, HTML and CSS, no matter how big a number you put after them. Their fundamental models are broken and cannot be repaired. The only way we will really make a big jump in what we can do is to build more suitable replacements that are designed to be fit for purpose from day one. And unfortunately, the organisations best placed to do that today seem determined to ignore all the warning signs from the history of software development and pursue a futile alternative anyway.
The trouble is, the web sucks as a platform for developing serious applications, because that's never what the technologies were intended to support. It offers only one major programming language, and that language is horrible. It offers one DSL that was designed to mark up content in simple ways and has been abused to fill some sort of ill-fitting UI description role. It offers another DSL that was designed for basic presentation functions, based on underlying models so bad that almost everyone ignores or overrides them even to the extent of building preprocessing tools to paper over the gaps. It offers limited separation of concerns in terms of content, presentation and behaviour, yet the promotion of web components seems determined to erode that separation even further. It offers almost no tools for modularity or composition in any of the three fundamental pillars everything is built with, and with a small number of exceptions even the various proposals to improve this don't look that promising so far.
We've seen this before, and we know how the story ends, if you just stop pretending the Web is somehow a special thing and look at general software development. The modern web being pushed by the likes of Google and Mozilla looks increasingly like the unintended result of one-night stand between modern C++ and VB6. It's all about papering over the cracks and shoe-horning existing tools into roles for which they are completely unsuited. This approach will get you so far, and then it will fail, as it always does.
We would do much better if we redirected all the recent enthusiasm for improving the Web. We can still recognise what has made the Web successful: essentially, it offers a ubiquitous, readily understood, cross-platform, client-server model for letting normal people interact with services running on someone else's system. But then we can also recognise the forces that are limiting web development today: lack of a real "portable assembly language" and run-time environment that a diverse range of programming languages can use as a stable, secure, reliable foundation; and the lack of a clean, flexible model for presentation and interaction.
You can't fix the latter using any combination of JavaScript, HTML and CSS, no matter how big a number you put after them. Their fundamental models are broken and cannot be repaired. The only way we will really make a big jump in what we can do is to build more suitable replacements that are designed to be fit for purpose from day one. And unfortunately, the organisations best placed to do that today seem determined to ignore all the warning signs from the history of software development and pursue a futile alternative anyway.
I hear my coworker complain about it regularly, talking about how much easier Powerbuilder was to do applications and how far astray we've went. :)
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.
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.
I am not concerned in the least about the direction the web is going in right now.
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.
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.
You deride the use of preprocessors and such in other places in this thread
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.
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.
I feel you about the inadequacies and oddities of JS, HTML, and CSS, but who's going to engineer this clean break with the past? What entity or entities are cohesive enough in purpose and broad enough in interest to produce something that could ever hope to rival the existing, impressive-if-frequently-kludgy, broadly-installed functionality of the web platform?
What is so broken ("broken"-broken, not just "hard to do correctly", "inconvenient", or "inconsistent") about JS/HTML/CSS?
You bring up general software development, so I want to say: "custom elements defined with HTML templates rendered in a shadow dom" must just sound like layering crazy on crazy, but it's actually a really old-school idea: encapsulation. Encapsulate the HTML structure, the CSS that styles it, and the Javascript that adds behavior and/or fully elaborates the structure into a single thing and maybe some of the crazy can be controlled.
What is so broken ("broken"-broken, not just "hard to do correctly", "inconvenient", or "inconsistent") about JS/HTML/CSS?
You bring up general software development, so I want to say: "custom elements defined with HTML templates rendered in a shadow dom" must just sound like layering crazy on crazy, but it's actually a really old-school idea: encapsulation. Encapsulate the HTML structure, the CSS that styles it, and the Javascript that adds behavior and/or fully elaborates the structure into a single thing and maybe some of the crazy can be controlled.
it's actually a really old-school idea: encapsulation
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?
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'm not sure I should respond, since trolling web-related posts seems to be your favorite past time, so I'll only respond to one thing you said.
> And unfortunately, the organisations best placed to do that today seem determined to ignore all the warning signs from the history of software development and pursue a futile alternative anyway.
What makes you so sure of that? Step one of a scorched earth strategy is getting all (and I mean all) platforms on board. If it doesn't run on an iPhone it is completely doomed, for example.
So the lack of visible proof that teams exist trying to reinvent the web from scratch is not something you're going to get into the project is already very far along.
> And unfortunately, the organisations best placed to do that today seem determined to ignore all the warning signs from the history of software development and pursue a futile alternative anyway.
What makes you so sure of that? Step one of a scorched earth strategy is getting all (and I mean all) platforms on board. If it doesn't run on an iPhone it is completely doomed, for example.
So the lack of visible proof that teams exist trying to reinvent the web from scratch is not something you're going to get into the project is already very far along.
Android apps don't run on an iPhone.
Firefox OS apps don't run on an iPhone.
Are they doomed?
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.
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.
[deleted]
The defects you point to are real, but it sounds like you're speaking to us from 2008.
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.
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.
The defects you point to are real, but it sounds like you're speaking to us from 2008.
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.
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.
slaps own hand for feeding the troll
1. What's so horrible about JavaScript? Could you give a few examples?
2. "one DSL that was designed to mark up content in simple ways" - With custom elements, we can extend that simple language to our liking. There are no bounds anymore.
3. "everyone ignores or overrides them even to the extent of building preprocessing tools" - Problem? We write in Sass/Less/Stylus/etc. which are capable languages that are continuously improved.
4. "It offers limited separation of concerns in terms of content, presentation and behavior" - What do you mean? You can separate those things just fine.
5. "It offers almost no tools for modularity" - npm is full of tools for this. You can have modularity in your source code and rely on tasks to package it for production.
6. "the Web is somehow a special thing" - Hm, it's open-standard and fully cross-platform. Looks pretty special to me.
7. "and run-time environment that a diverse range of programming languages can use as a stable, secure, reliable foundation" - Isn't JavaScript just that? I'm not an expert on this, but it looks like the general trend is that more and more languages are being compiled to JavaScript.
8. "to build more suitable replacements that are designed to be fit for purpose from day one" - I think we can all agree that this would be better, but it's just entirely unrealistic. We can't just ditch stuff that has become common. The Web is here to stay.
2. "one DSL that was designed to mark up content in simple ways" - With custom elements, we can extend that simple language to our liking. There are no bounds anymore.
3. "everyone ignores or overrides them even to the extent of building preprocessing tools" - Problem? We write in Sass/Less/Stylus/etc. which are capable languages that are continuously improved.
4. "It offers limited separation of concerns in terms of content, presentation and behavior" - What do you mean? You can separate those things just fine.
5. "It offers almost no tools for modularity" - npm is full of tools for this. You can have modularity in your source code and rely on tasks to package it for production.
6. "the Web is somehow a special thing" - Hm, it's open-standard and fully cross-platform. Looks pretty special to me.
7. "and run-time environment that a diverse range of programming languages can use as a stable, secure, reliable foundation" - Isn't JavaScript just that? I'm not an expert on this, but it looks like the general trend is that more and more languages are being compiled to JavaScript.
8. "to build more suitable replacements that are designed to be fit for purpose from day one" - I think we can all agree that this would be better, but it's just entirely unrealistic. We can't just ditch stuff that has become common. The Web is here to stay.
Javascript has plenty of terrible language features, particularly in the scoping rules, but the biggest problem is the lack of any concept of modules/packages, or namespaces. <script> tags just dump everything into the current page context. So you get stupid issues like name conflicts between all the different libraries that define a "$" function. Refresh the page or navigate to a new page and the context gets wiped out, so you have to store state in cookies to mimic the concept of a session. The 'Back' button often breaks everything. The whole platform was just designed for rendering simple documents and forms, not complex applications. The deficiencies of HTML/CSS/JS are why stuff like ActiveX, Flash, and now PNaCl even exist. They are workarounds, but they are proprietary and break portability, so they are not the way forward.
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.
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.
ECMAScript 6 modules: http://www.2ality.com/2013/11/es6-modules-browsers.html. The JavaScript language is evolving and the issues you mentioned have been addressed.
1. http://www.youtube.com/watch?v=hQVTIJBZook around 11:30. This is common knowledge, we should not have to repeat this every time we talk about this topic.
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.
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.
1. JavaScript has "bad parts", yes, but we can just ignore them. Allow me to use an analogy here: Image you have a smartphone that has 100 apps installed, and of those 100 apps, 10 are crapware (e.g. pre-installed vendor-specific apps that are just bad). Does this make the phone horrible? No, of course not. Just ignore that crapware. Even if you can't uninstall it, it's not an issue for you. Use the good apps, install more good apps if you like to (analogy to JavaScript libraries) and ignore the crapware (JavaScript "bad parts").
2. That's literally what web components are for. Read OP's post. We will have <calendar-widget> and <login-form> and many more custom elements with plug-and-play functionality.
2. That's literally what web components are for. Read OP's post. We will have <calendar-widget> and <login-form> and many more custom elements with plug-and-play functionality.
npm = node package manager. That's for server-side javascript with node.js. Totally different deal from what we're talking about here, which is client-side javascript.
You can use npm modules on the client via Browserify. And there is a dedicated to client-side package manager called Bower.
Those are some pretty cool projects. This sort of thing really needs to be supported natively in the browsers and written into the ECMAScript standards, though. It looks like what both Browserify and Bower are doing is basically a macro expansion that outputs regular Javascript, which is interesting, but really shouldn't be necessary.
Basically the current state is that everyone knows that HTML/CSS/JS sucks (by sucks I mean not adequately productive to work in, relative to the feature demands of modern web applications), so we're building languages that compile to them so that we don't have to write them directly. JS is becoming like the assembly language of the web. Some cool stuff has come out of that, but it doesn't mean we should give up on trying to make HTML/CSS/JS better. They were designed to be written by humans, so we shouldn't need to compile to them in order to be productive.
Basically the current state is that everyone knows that HTML/CSS/JS sucks (by sucks I mean not adequately productive to work in, relative to the feature demands of modern web applications), so we're building languages that compile to them so that we don't have to write them directly. JS is becoming like the assembly language of the web. Some cool stuff has come out of that, but it doesn't mean we should give up on trying to make HTML/CSS/JS better. They were designed to be written by humans, so we shouldn't need to compile to them in order to be productive.
JavaScript is all about lack of standard solutions. Take any aspect of the development and you will get a million of possible solutions, whether they are classes implementations, package managers or build tools.
Server-side and development. In a nutshell, npm is used to install development tools for building and packaging your source files, running a local server and even deployment.
What's so horrible about JavaScript? Could you give a few examples?
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.
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.
A solid example of such a custom element would be a <code-block> element: https://twitter.com/simevidas/status/450272769948016642
I quite like the concept of Web Components - operate with elements rather than blobs of JS. Browsers have been doing it for ages defining built-in elements. Now front-end devs have the tools to do the same. I'm excited to see what will come out of it.
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
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
I am afraid this will bite us in the butt worse than iframes.
More work for us if it does. Consider it a form of job security.
Like Addy points out ("not a silver bullet") performance, security, and accessibility are not a given, and those are why I'm cautious. Security-wise, the document is already hard to lock down, and so it makes me a little worried to increase the surface area with application-level extensions. Cautiously optimistic.
What really remains to be seen is whether this reduces or increases complexity. This really depends on how well it works to declare data in the document and then interact with that data via the JS. For instance, 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? Does it encourage "globals"-like behavior, where hidden dependencies crop up? Are there life-cycle behaviors to the Ajax component that might trigger the request at surprising or frustrating times?
If you're a Web Components advocate and you're feeling agitated, knock me down here. Fence-sitters are the worst when you're trying to get market-share for an idea, so sorry about that. It looks like Web Components are happening, though, so I'm sure I'll get to wait and see.