7 ms·

The Web’s Declarative, Composable Future

46 points by daw___ 13y ago

SimeVidas 13y ago
A solid example of such a custom element would be a <code-block> element: https://twitter.com/simevidas/status/450272769948016642 https://twitter.com/simevidas/status/450272769948016642
Silhouette 13y ago
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.
- SimeVidas 13y ago
  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.
  - innguest 13y ago
    1. http://www.youtube.com/watch?v=hQVTIJBZook 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.
    - SimeVidas 13y ago
      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.
pfraze 13y ago
I'm cautiously optimistic about Web Components. It's good to add well-defined interfaces to browser Javascript, and there's a certain logic to using the DOM. The DOM is central, it's queryable, and it itself can gain from expressiveness. 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.
- ebidel 13y ago
  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.
dsego 13y ago
I am afraid this will bite us in the butt worse than iframes.
- knieveltech 13y ago
  More work for us if it does. Consider it a form of job security.
znowi 13y ago
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 https://developers.google.com/events/io/sessions/318907648

46 points by daw___ 13y ago

A solid example of such a custom element would be a <code-block> element: https://twitter.com/simevidas/status/450272769948016642 https://twitter.com/simevidas/status/450272769948016642

Silhouette 13y ago

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.

SimeVidas 13y ago
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.
- innguest 13y ago
  1. http://www.youtube.com/watch?v=hQVTIJBZook 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.
  - SimeVidas 13y ago
    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.

pfraze 13y ago

I'm cautiously optimistic about Web Components. It's good to add well-defined interfaces to browser Javascript, and there's a certain logic to using the DOM. The DOM is central, it's queryable, and it itself can gain from expressiveness. 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.

ebidel 13y ago
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.

dsego 13y ago

I am afraid this will bite us in the butt worse than iframes.

knieveltech 13y ago
More work for us if it does. Consider it a form of job security.

znowi 13y ago

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 https://developers.google.com/events/io/sessions/318907648