

The Web’s Declarative, Composable Future - daw___
http://addyosmani.com/blog/the-webs-declarative-composable-future/

======
pfraze
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
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.

~~~
pfraze
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.

~~~
ebidel
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...](http://src.chromium.org/viewvc/blink/trunk/Source/core/css/html.css)

Interesting times indeed.

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

~~~
kyllo
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.

~~~
nDmitry
You can use npm modules on the client via Browserify. And there is a dedicated
to client-side package manager called Bower.

~~~
kyllo
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.

~~~
nDmitry
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.

------
SimeVidas
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)

------
znowi
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)

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

~~~
knieveltech
More work for us if it does. Consider it a form of job security.

