Transcript

Jen

This is The Web Ahead, a weekly conversation about changing technologies and the future of the web. I'm your host, Jen Simmons, and this is episode number 65. I want to first say thank you so much to our sponsor, Media Temple, who is making this show possible. Then, jump right in. The guest today is Simon St. Laurent. Hi, Simon!

Simon

Hi there.

Jen

He is a senior editor over at O'Reilly. He's a co-chair of the Fluent conference and the OSCON conference. It feels like, Simon, in a way you're probably personally responsible for a large majority of the JavaScript books that are out on the market right now.

Simon

I have helped.

Jen

Yes. Not you alone. It's you along with a lot of other people over at O'Reilly. Of course, there are many other books by other companies besides O'Reilly. It just seems like you, over the last couple of years have just really helped create a pretty extensive library on JavaScript books.

Simon

Yeah. We've had a good time. One of our earliest successes in the web space was JavaScript. The definitive guide which was this gigantic tomb, it still is and will be coming out again the near future. I edited JavaScript: The Good Parts. By edited I mean I changed one word in it. That was a key book for getting JavaScript. A combination of respectability and increased usability.

I think that's what opened the way to the framework explosion that we've seen with people figuring out different ways to use JavaScript. It wasn't just visual basic with Java syntax. I'm really happy with that. The Fluent conference kind of take some of those conversations and makes them live and in person. We're definitely eager to do more with JavaScript and with the web generally.

Jen

Yeah. I was just at Fluent. It was in San Francisco a couple of weeks ago. There was a lot of excitement there about what's happening right now with JavaScript and the web. A lot of people seemed to be saying like, "Oh, finally the web has grown up. Finally now this is a real programming environment. I can do a lot of stuff." People were talking about, "Okay, so what's the stuff we're going to do?" Some of those sessions and demos and examples were pretty impressive, you know?

Simon

There's a mix of really impressive and sort of, okay, they've come into my web and now they want to change everything.

Jen

Yeah. That's what we're going to talk about today.

Simon

Yes. I come from, I don't know, I first encountered the web in 1994. I bounced off at earlier because it involved markup. I'd seen what high time looked like so I ran away as quickly as I could. I went back to HyperCard and lost a few years of potentially cool stuff. I've seen a lot of mistakes along the way. I've seen a lot of ideas that seemed great and then weren't great. I have a pretty strong tendency to be cautious. I'm happy with the demos that we're seeing. I'm seeing people from all categories of software development.

Taking the web far more seriously and incoming into it. The web is no longer something that other programmers have to tolerate as just a small part of their job. For some of them they now have to tolerate it as a large part of their job, and that's not always happy either. I've really enjoyed watching that growth over the last, oh no, twenty years. At the same time, this last round of changes of people coming in. The shift really to single page web applications. I'm not in a sin, I've written a single page web application.

I feel like people are looking at it more as a platform for software delivery rather than a general purpose communications medium. All of these expectations that come from desktop application programming, or flash programming, or survey side programming are suddenly poured under the browser. Where browser best practices differ from sort of classic software orthodoxy, we're seeing the browser get a lot of flak.

Jen

Yeah. I feel like this is something I want to write about myself. You have been writing a lot over on the O'Reilly's programming blog. You keep coming out with these really great articles. I'm like yes, that's exactly right. Jeremy Keith has been writing about this too, actually. He put something out again today, I think. I feel like there's this slow conversation starting and I'm not sure yet how concern I want to be.

Maybe it's just another trend. Another way that people are thinking about the web. It's not a big deal. I'm slowly becoming actually quite concerned that we're going to need a whole web standards 2.0 movement. By that I say web standards, when I think of web standards movement I realize ... Actually there were two movements at the same time, that happened at the same time. It kind of happened because of the same group of people.

That people called their effort the web standards movement, whatever. It felt like last year that group said, "Oh. We've won. We succeeded. We don't need this effort anymore." There was really two pieces to it. One was, hey, let's get browser makers to agree that they want to standardize what they're going to do. The features of the browser, how HTML, CSS, JavaScripts works, right? Let's have specs, let's have them at the what way or the W3C. Let's agree to them.

That standardization movement, I think that very much succeeded. I think it completely succeeded, but at the same time that same group of people. Especially Jeffrey Zeldman and others were saying, "Here are the best practices for the web. Stop making layout with HTML tables. Stop putting the information about color and about font sizes and all of that. Don't bake that into your HTML. We need to have a separation of concerns here.

The HTLML is for marking up content. The CSS is for styling and layout is part of your styling, whatever. Color, fonts, all that, it's all styling. Think of it as if, this is what I walked away from the era of with, is think about it as if your CSS fell off, your HTML would still work. You'd still have a very great web page. Especially if you're delivering art content. Like an article which is what up until recently the majority of the web has been let's deliver a blog post. A New York times newspaper article, stuff like that.

Even the photo like Flickr or something like here's a photo. The idea would be, hey, in five years your company might want to redesign. They don't necessarily have to rebuild the whole thing. They can just slap a new theme or a new skin on to the HTML. Change the CSS, keep the HTML and you can keep going. Also, once you do things like that then the site becomes accessible which we talked about extensively in last week's show.

If somebody clicks a button and puts it into Instapaper and read it later into some other kind of app. They have a thing in their car, they push a button and it gets read out loud to them. It's good as it work. JavaScript is yet another layer. People know this, I rant about this stuff all the time. It feels like that was part of the Designing with Web Standards book by Jeffrey Zeldman. The part of that whole ... like we didn't know that we needed to have a separation of concerns.

We started doing the web a certain way. Then, we realized, oh my gosh. This is a terrible way to do things. There's all these reasons why this should not work. Then, it took us years, and years, and years to convince everybody to treat the web like a stack. Use progressive enhancement into ... have a separation of concerns. It feels like now there's a whole new group of people. When I was at font, it felt very much like there's two worlds now.

There's the responsive way of design web standards folks who go to these kinds of conferences and then there's this other group of people that's maybe new group of people. They kind of come out of nowhere. It's like they came over from Java application programming on the back end, or they came right out of school with computer science degrees and professors who thought the web was like not any good. They've come from flash action script programming.

There's this momentum building of this people who think I'll just have JavaScript do everything. I'll have JavaScript write the HTML, I'll have JavaScript write the CSS, I don't know why we're bothering with all these crap. This is just a mess. This is too hard. I just want to use JavaScript like a proper programming language and the web sucks. Finally now, the web is finally starting to act like it should have all along. Let's just use JavaScript for everything.

Simon

Then you get billion parodies of that like James [Shaf-fer's 09:18] Replacing CSS with Note. It was totally parody but a lot of people looked at it and went, wait I've had this conversation. The place that I find I can connect both crowds is that ... People talk about web scale and that's also been parodied rightly, but the way that I tell the story of separation of concerns so that people who haven't yet come to value it through suffering and other things.

Jen

You're so mean.

Simon

I'm sorry. I'm having flashbacks to maintaining a gigantic 80,000 page site in 1997 or something. I was not the primary one on that, fortunately. The separation of concerns is what left the web scale organizationally. It's not about, I'm going to send you this page and CSS makes life so much faster for the browser. That's not really the issue. CSS makes it so much easier for me to hand off. As you said this HTML document from person to person, organization to organization and brand new skin, after brand new skin.

These things are magical. If you decide that instead you want to build all of your layout through JavaScript, you end up handing over large chunks of intermingled code that, well, I mean the people can ... You can hand JavaScript from one programmer to another. It's not like write once, read never, but it's not the same kind of reuse. It's not the same ease of letting different people with different skills get to different things in the application.

I'm afraid that as we move deeper and deeper into this, there'll almost be a computer program. We're going to face the same kinds of long term maintenance costs that computer programs have. Maybe that's acceptable for some organizations. It probably is acceptable to a lot of organizations. Lot of web apps are after all proof of concepts.

They're going to get torn out and rebuilt if they succeed or just abandoned if they don't. That's a really different set of values and set of practices than we've become use to on the website. I have 5 pages from the 1995 that I visited with the whole 25th anniversary of the web thing and they still ran perfectly fine. I marvel at how bad the photos are, but it's okay, but-

Jen

Did-

Simon

Yeah?

Jen

No, I was going to say Jeremy Keith has talked a lot about sort of the fragility of kind of try to force the way of being one particular application framework zone or something. You pretend like it's an application framework where when the web is actually ... I've talked about this as well at Fluent. Like the web is sort of brilliantly bullet proof. It's designed to handle a wide range of different devices. It's funny, because people keep comparing, right? They're Like which is better, iOS or Android or the web? Which is better, native or the web?

Simon

No, no, no, no. Yeah.

Jen

It's kind of a good question to ask. We've been asking it now for 3 years, 5 or 6 years, but it's like in a way it's a weird comparison, because if you use Objective-C and you write an XCode and you're writing an iOS application, you're basically writing an application for one operating system, and it's known. There's like 4 or 5 different models of screen sizes, big and small iPads, big and small phones, but that's it.

You know exactly what's going on. You may not know what the speed of the network connection, but basically maybe you want to support two versions of iOS going back or something or maybe 3. It's all known quantity. What it means to program for that environment is very different than building a website. Part of the beauty of the web, even though it's chaotic, and it's not so nice and neat. You can't really tie everything up on a bow is that it works across a gazillion different devices. It works on different operating systems at the same time.

You can't write one program and have it work both on iOS and Android and Windows phone and a phone that you've never heard of that is super popular on the other side of the globe, but you can make a website that works on all four of those and even more and more and will keep working ten years from now, and will go back and will work on browsers that existed 3, 4, 7 years ago.

I feel like that value's getting lost and people are just like whatever works in my browser, on my computer while I'm developing it then we're good to go. I don't know why I have to separate all those stuff. I just want to put everything into one application environment.

Simon

Then, they get very annoyed when their boss calls because it doesn't work on their particular device and it all has to be fixed, and then it's the web's fault. I do know some people who've left the web for those happy native platforms where they know where things are going. Danny Goodman who wrote Dynamic HTML: Definitive Reference was my HyperCard guru years ago. Wrote a book on iOS for JavaScript people because he was so happy moving to iOS, but most of the time I see native apps doing things ... they really fallen to two categories.

One is stuff that I wouldn't despite Brandon Eich promise that asm.js will make everything as fast as native. There are a lot of apps that are doing things that I don't think I would want to try efficiently with web tools. Photoshop is kind of the classic one that I bring up, but Photoshop is possible. Video editing is kind of the next frontier of that. Then, there's this huge class of native apps which basically are alternate ways to browse the web.

Somebody took apart Facebook's application after they claim they've walked away from HTML5. Most of the stuff underneath it was still all HTML. Then, they built a faster application using web tools because it was fun. The apps promised a different economic model to some people. Companies really seem to like Walt Gardens. I'm afraid that [Si-ron Call 16:14] took a lot of content to place these words less accessible.

The thing that we just seem to keep losing is the easy connectivity between different websites. The piece of the web that actually amazes me the most isn't what we do on the browser. It isn't the server stuff, that's the stuff in between that I can cut and paste the URL from one place to another, and have it understood in a million different context. It's completely insane. While I'm on a browser, it gets more interesting when I have a right mouse button I can sometimes get URLs out of applications.

When I'm on a touch device, I'm like, I want to share this. Oh, I can only share this the way the app wants me to share it. I don't want to do that. Okay, never mind. I see a lot of people who are incredibly excited in building these social things that to me just feel like a less functional version of the web. I'm not going to stop them. I even use some of them on my phone. I just find it strange that we'd want to do it that way.

Jen

Yeah. What do you feel like there's this trend happening. You've been writing on these issues quite a lot and what kind of response are you getting?

Simon

I get very polarized responses. On the public next web list which is the extensible web manifestive list. I get told I've read the manifester wrong and I'm calling for separation of concerns in ways that are just inconvenient. Then, I hear from people who have been working on the web for a while and they're like, hooray. That's great. Well, I think we have a basic breakdown here. I'm going to the extensible web summit next week. That'd be a 3C technical architecture group.

The tag is having this one day event at Adobe. I'm looking at the list of people attending and I'm like, these are all the people that I've talked with on Twitter. I should go meet them. Then, I think about the conversations we've had and I'm like, well I hope they'll be happy to see me. I don't know. I'm going to kind of scope that out. In a lot of ways it's a conference organizer and book publisher. I'm looking at this event as something that will set my path though the next, at least two years, but maybe as much as five years in terms of prioritizing which kinds of stories are likely to emerge.

I haven't seen anything quite that promising in a while. At the same time I want to welcome everyone. I also want to stir them away from the ditches. I keep worrying whether I can be welcoming people in and at the same time issuing appropriate warning labels without them just getting annoyed that I keep telling them not to do things. I'm trying to avoid the get off my lawn conversation, but it's not always easy.

I think Twitter is probably actually where it's worst. It's the 140 character limit in the place where I have most of my public technical discussions is really a challenge. I have better luck in Facebook because I don't have that limit. It's also a different crowd of people. With the blogs, it's interesting because I publish them and I see them Tweeted, I see some conversation, I've kind of get out of broadcast mode. I'm happy to tell the stories, but I want to be talking with people more than talking to them, because I don't feel yet like I've found a way to connect with programmers, per se who see the web as an obstacle to be fixed rather than, wow, I can build here forever and it will be great.

Jen

I think I just feel like I keep ranting about this subject. I kind of just want to be more productive instead of just ranting and coming from a place of fear and confusion and frustration. Like I don't even know why I'm afraid or confused or frustrated. I'm curious too. That fluent, I did more than once overhear people say things like well, the web has really been really sucky for many years, finally it's less sucky.

I'm so glad I'm ready to go beat it up and make it my ... beat it into submission make it do what I want. I see things on Twitter. People saying, oh yeah, my JavaScript framework writes my HTML for me. Yeah, I don't have to worry about my CSS. I'm confused. There's something I'm missing.

Simon

I first heard running into this when I was first learning Rails. There were a lot of people who wanted to create template system that didn't look like HTML. This really puzzled me because, I don't know, I'm very used to angle brackets. I also should confess that I spend 5 or 6 years in depths of XML. Markup is kind of my oxygen. Some of the template systems were great. Some of them seemed like an effort just to make everything look like the other code in the projects. Which also puzzled me because I like my markup to look different from my codes so I don't forget which thing I'm writing.

As Rails progress it sort of shifted the defaults ... approach shifted from being CSS to being SASS. There was sort of this whole notion of the framework compiling all of these pieces for you and into this final deliverable that just happen to be JavaScript and stuff. CoffeeScript was also a key part of that transformation. I like CoffeeScript. I just was kind of surprised by the shift that way. I'm a little calmer about it when I've looked at the frameworks currently in used.

Angular is the last one that I really got to take for a spin. It was too long ago but at least it felt like it really markup friendly to me. They clearly thought about what HTML was and how to keep using it in ways that were familiar to people. Weren't too disorienting. They wrap It with JavaScript and really framework guys all of it. At least underneath it I can still find the pieces I'm familiar with. I did write a single page app I mentioned earlier. I wrote it with Jen Robbins, it was HTML pocket reference.

That was really a disorienting experience, because I found myself having to rewrite basic web functionality into the framework. In my case it was that ... We were loading sub documents and pointing to places within the web that's just a fragment identifier, that's easy. Somehow, the framework didn't understand fragment identifiers especially as they applied the sub documents. I felt like I was writing a miniature web browser for a while there just to be able to get to the right place in a document.

Good came out of that. Eric Meyer and I have CSS Selectors for fragment Identifiers spec that maybe someday we'll finally get the world to look at. People periodically are like I need this. There are plug-ins for browsers out there. You can do these things. There was some good side effects of having to reinvent all of these things. I still was really puzzled like why am I having to reinvent this? Oh, it's because they don't see these things as documents anymore. They see them as the set of objects and I'm just suppose to use JavaScript to jump around in them.

The other big thing that I got out of that was at one point, Jen had me ... We made a switch versions of HTML on the reference. You want to just see HTML4, fine. You want to just see HTML5, fine. You want to see both. I went to all this work to create this beautiful JavaScript piece that could tree walk and make everything set. It worked great on my computer, by it was incredibly lousy on the device. I think it may even have been Jen who suggested it, she was like, why don't you just try switching style sheets? It was amazing.

The mass of power of browsers that understands CSS versus doing everything in JavaScript. It must have been a hundred to a thousand times speed up. The browser had the CSS. It did all the tree walking for me. It just happened, it was so much happier. I got a lot of lessons about how to layer all of these different parts and do it efficiently by working on small devices with minimum processing and not an incredibly complicated project. One that was just complicated enough to get beyond the, hey, this is cool. We can make this all work kind of phase.

The other thing about that one that I'm thinking about now is that we had it setup so that I was kind of the programmer and Jen was the designer. It was just a two person project most of the time. We brought in somebody else who did a much better job on my JavaScript afterwards. That's fine. Jen was really able to focus on the CSS and I was able to focus on the JavaScripts. Between those two sets of skills, we were able to put the application together.

As I look at the current context for applications and the way that we're building them. I can imagine the work flow for stuff that was all in JavaScript, but I think it would hurt a lot to describe it. Something that I really like at that artifact conference which I guess is another place where you and I and Jen were in the same room. There was this discussion what work flows look like for designs specifically for responsive web design.

The themes you're talking about , for separation of concerns and letting different groups of people bring different sets of skills to the problem just was all though there. I think that talk you gave where you started with just a bare HTML document, and then drove out from there was fun. I looked around the room and people were like, oh, yeah. I could do that. We've kind of forgotten it but it's always been there and sort of always been the safe foundation.

Jen

I gave that talk in quite a bunch of times last year. It was interesting because people are trying to wrap their heads around a responsive web design and how to do layouts and how to figure out where to move stuff on the page from one size grain to another size grain. I was very overwhelmed and confused when I was first learning this stuff and the thing it felt almost like you're sliding down a mountain and you're flipping outside down and you don't know what to do.

You just need to like grab some hold and just hold on and get yourself re-oriented better again. For me, that place to grab on to to really hold on to is the HTML itself. The content and kind of figuring out. This idea dog tails right with all people were saying with design for mobile first, design your content first. I seem to be taking it in a certain direction that a lot of other people weren't talking about which is figure out your content and figure out the order of your content.

Before you do anything else, just write your HTML. Just write a sample perhaps it's just one sample you're doing a prototype of how that content's going to work in the HTML. Lock it. Don't change it. Don't do your layout. Don't rearrange your HTML based on this layout you want to do, because you just want to be float before blocks. You don't have to use negative margins and you don't have to look anything up because that takes much time and effort. We'll just rearrange the HTML. I'm like no. You can't rearrange the HTML to make it faster and to be lazy.

Keep your HTML in the same order and then design whatever you can. If your layout skills aren't a hundred percent then, you're going to be a little limited or the fact that CSS and the old school float layouts can't do anything. It is they are limited. Holding up HTML is this holy thing. Sacred thing of like that's the core of the whole shazam. You don't want to mess with that. You want that to be really solid. Then you can dance around and do all those fancy stuff on the outside of it.

Simon

I joke that HTML has always been responsive, we just broke it.

Jen

Yeah. It's true. All these stuff works across all these devices. We just keep breaking them.

Simon

Yeah. We want to fix these things down. A lot of my early web career was dealing with graphic designers and explaining to them the many differences between a web browser and Cork Express.

Jen

We're still doing that. We're still really doing that.

Simon

I got into, I think it was CSS regions, but I was talking about it in multiple context. Somebody was like, well why don't you want people to be able to do what they can do in design? I was like, I think you have me down for the wrong argument. I'm marketing with programmers, and they were like, programmers are interested in pinning down all of these boxes and doing this?

I'm like, it's a long story. In the last week or so, I've been Tweeting and talking about XSLT again. I feel sort of bad about this because I've never really been an XSLT fan. I did actually do some cool things with a single page web app I was talking about before.

Jen

Tell people who never know what you're talking about.

Simon

Okay.

Jen

Just very briefly. What is it?

Simon

XSLT is comes out of the XML world and it's extensible style sheet language transformations. Originally, the XML folks hoped that this can come to the web browser. Somebody would send you XML and if you wanted to view it in the browser as HTML, you would have this XSLT style sheet that would turn it into HTML or generated PDF or lots of different things. There was the idea that, we'll send you a document and then we'll transform it to whatever you want it to be.

What I'm saying with a lot JavaScript folks is that they want to set up a little framework. They want to send a [Ja-son 33:17] and then they want to transform it into whatever they want it to be. I'm also seeing people who to the extent that they have to use HTML, want to set the HTML lot for layout and they don't seem to have any qualms about throwing in random markup that's only needed for layout. I'm like, these people XSLT. That way they could get a clean document and they could transform it to whatever set of boxes they want and work with that.

The rest of us wouldn't have to suffer through it. I worry that somebody will listen to this and some may ran off to learn XSLT. If you do, that's fine. It's not really in most browsers. XML community plans to rebuild the web, that really didn't happen. I'm really kind of weirded out to find like this approach that I had dismissed 15 years ago for being way too complicated and requiring people to know too much is suddenly reappearing in a different flavor in the JavaScript world.

I've spent enough time in both JavaScript to XSLT to think that, oh, I feel really bad saying this. To feel that the JavaScript folks might actually have less pain trying to do what they're doing in the older XSLT world. I'm sure I'll get a lot of scoffing for that. It was actually built for transformations and JavaScript is more about manipulatings. It's kind of a different set of tasks. I think about these conversations about regents.

I think about developers who really want their HTML view ports to be a layout they control precisely, as precisely as the graphic designers wanted to control. The web pages with dreams of Cork Express. I keep thinking that they need another layer. They need another scratch pad. I don't think it's canvass, but somehow I want them to get out of the conversations that keep blending, markup that's maintainable with programs that are really something else again.

Jen

There's something here that's just off. It did feel like we learned the hard way. We had come to this place where everybody is sort of agreeing. That progressive enhancements, a person in concerns, blah, blah, blah. Absolutely, that's what we're doing. Oh, my gosh. We thought the web was this other thing like print and now we're finally, after 23, 5 years, designing for the web itself. These are people whom their clients are big media corporations.

This seems to be the conversation a lot of them are having. They're helping media corporations kind of switch out of their mid 2000's web, whatever. 2006 website into a more modern website which reflex actually what the web is. What all these phones and devices and tablets want. Then, all of a sudden It just felt like, oh, we're finally, we don't need to have these big debates. We don't need to have these kind of nerd wars around. This, that and the other. We were all moving in the same direction, we're all sort of agreeing and now we can really get some momentum behind some new ideas and come up with some better stuff. We've got new tools, we've got new CSS, we've got… right?. Then, all of a sudden it feels like there's an disjoint title wave of people who either completely don't understand the web or hate it. Just hate the web. They want to just destroy the whole thing and change it to something completely different. It feels like we have less agreement now than ever before about-

Simon

I think it's less that there's less agreement now. It's that it's a lot more visible. I've always had, as long as I can remember that I've been posting about web topics at O'Reilly, I've always had the occasional comment. Let's replace the web with some kind of real desktop application paradigm. Canvass is the best idea to hit the web in millions of years because then I don't have to think about the dom. it's been there but until recently I've only encountered it when I was writing or speaking in context that were more programmers eccentric.

I would get the [se-nos-can 37:49], I would get this online. I would get different variations of it in the XML world when suddenly it went from being documents to, hey we're going to bind all these data to objects. Suddenly the entire world was schemas and programming. I guess I experienced the same flood before in the XML world when that shifted very suddenly towards programming.

I hadn't made that connection. It's been there. The difference is now that people are taking the web seriously, this group of critiques who sort of always existed is now very much coming into the web and coming in to the conversation about where we should go.

Jen

A lot of what I think we saw being built is flash application that were running inside of a box. Other sorts of plug ins. Like some internal intranet for giant corporation. The reason you had to keep using AA6 for so many years is because they have made this kind of hard coded very particular application that was Java, running in the Java ... whatever the heck it was called let thing. Javalet, it's not what it was called, but a blog that out of my mind.

I don't want to think about that stuff. That sort of awkwardness in those websites, those were so deeply broken and not accessible and not responsive. There's all these reasons that ... because it was fighting. It was like, well, we don't really want to use the web. We want to do this other thing, the web can't do this other thing. We're going to make a hack and we're going to jam our hack, just ram it into the middle of the page.

It seems so exciting with HTML5 and a lot of these APIs to be like, hey, we don't have to do a hack. We don't have to make this separate box and ram it into the page. We can actually integrate these things directly into the browser. What perhaps we didn't expect is this sort of kind of ideas that the web is bad. It's not real programming. HTML is not real. There are so many examples that I didn't even bother to bookmark these examples, because they're rampant. Poeple being like HTML is not code.

Simon

Yeah.

Jen

Oh, yeah. It's spaghetti. All right. It's knitting. Of course, it's code, but it's not going to run as a program in a way. It's declarative and not, oh, I forgot the word. It's different. It's different flavor, but that doesn't mean maybe you have PhD in programming and I don't or this other person doesn't. That doesn't make them stupid and you smart. It means that you ... I don't know.

Simon

Right. It's different communities. I blogged about Lea Verou's key note this week from Fluent. When I'm walking through the hallways and hearing people say, wow, I didn't know you could live code CSS, because I didn't really think it was code, but wow. That was cool. I think we can reach people. I think it does happen, but if it gets a vocabulary difference, it a different set of values, it's priorities in a really big way.

I kind of think back, I also spent some time in Java and I did write some applets and was excited briefly about it. Right ones when anywhere sounded great, but it didn't really happened for Java with the way it happened with the web. The set of little tools markup and cascading style sheets and JavaScript because, you know, it's a script.

It's not a real language or something. Proved overtime to be a much lighter weight, much saner way to build this applications. I think overtime if we can get pass this kind of sizable bump in the road right now, I think we're going to see people come to appreciate that. I tell myself that I've seen this before and that will attempt to create this complex applications that do exactly what we want them to do very precisely, but slowly and crinkly and eventually the maintenance cost are going to catch up with us.

Maintenance cost are really what kill projects on the web. You can get things set up, but can you keep things going? If it's static and it's just sitting there on a server, it's not so hard. But the more intricate you get and the more demanding you get that you control every pixel, the less likely it is that it will survive the next 200 rounds of change.

Jen

Yeah, you can. I love flash when it came out. There are a lot of reasons why I no longer love flash. I won't take the time to explain them all. I think we already all know. We could list them. Probably the one that was the most ... Everybody thinks it's because the iPod didn't ran flash, but it's not. I think it's because it was just way too hard to update content inside of a flash application.

Simon

Restaurant menus.

Jen

It was not worth it.

Simon

Restaurant menus were the classic. They build this complicated sites and the prices would change and the menus would change in it. You could keep following them back, but it's a long time.

Jen

Clients had to hire a programmer to change the ... add something to the menu. It just was really bad. Perhaps you're really right. The reaction that you're having, I'm having, that other people are having has to do with this like, we did go down that road. It was incredibly painful. I thought we learned those lessons, but I guess we're going to go down the road again.

Simon

Yeah. Go down the road with a different crowd. The part that actually makes me more nervous and again this is why I'm going to the extensible web summit, is that ... I'm not going to say that building tables into HTML was a bad idea. We bought them in and then we misused them. I worry that as we look at different kinds of layout approaches, as we look at different ways to connect JavaScript to browsers, and as we standardize those things, there's a lot of opportunity to go wrong.

I'm happy about the extensible web manifested saying that we should actually test features before we standardize them. I've seen a lot of design by committee I'd rather not repeat. At the same time I follow the conversations around the specific features and I'm not sure it's just a question of testing. I think there's a strong question of priorities there. What kinds of things we're trying to do with the specs and as these conversations about control and about the web is basically a software delivery mechanism come to the four.

I start to get nervous about what the quality of specifications is going to be going forward. Will it still preserve these values of accessibility in a lot of levels. Accessibility sort of works for me as a classic test of ... Is this feature actually going to work for a lot of people. Is it going to prove maintainable in the long run?

I want to make sure that ideas that seemed good at the time don't get baked into specs where they no longer seem good for a long time. I'm on the outside. Except for that CSS selectors thing, I don't spend a lot of time actually discussing the details and specifications. I've been watching them for a long time.

Jen

Yeah, and something that you and I didn't talk about right now, today and something that is not ... Especially in a hundred and forty character, there's no space to talk about this is that there's, I feel like there's many different kinds of websites, right? On the one hand you've got the blog that's delivering articles or perhaps it's a big media company and they're delivering articles, but it's very similar. Way in the other spectrum you have something like what Brandon Ike was demoing at Fluent which is basically a video game platform.

He was showing instead of Xbox, or instead of this other video game platform. Nintendo, whatever, like use a web browser. I feel like in that sort of situation where if you're making a web browser into a video gaming platform, like of course, it's going to be all code, all JavaScript. It's all going to be programming.

Simon

Java is perfect for that.

Jen

There's not really an HTML. HTML is just kind of the delivery mechanism for canvas, right? Somewhere in the middle there's a lot of the overlap. There's a lot of different kinds. You see something like Twitter, whenever that was. A year ago, a year and a half ago. They rebuilt Twitter so that basically it loaded, delivered empty HTML pages and they would ran JavaScript. The JavaScript would go fetch all the content and the content would draw.

Simon

Yes,

Jen

Yes, it was really slow and it was very awkward and clunky. I think that's a perfect example of using JavaScript to do something that ... you don't need JavaScript to do that. The web is already really good at delivering content in HTML pages. They did, they rebuilt it. They got rid of that and they rebuilt it back to the more of a typical stack, right?

You're leveraging all these power that the web has took 25 years for the web to get that power. Don't throw it out. use it. Then, layer on top of it JavaScript. Of course, you got JavaScript running on Twitter. There are certain things that require JavaScript. I think there's a sophistications that's needed in understanding and even when we're having conversations like this. Getting specific about examples.

Simon

It's sort of looking forward to examples. I've been a pretty broad general supporter of web components which are sort of about extending the web through HTML, CSS and JavaScript and seem to provoke some strange fimortification issues, but I've been really happy in the last week to see people asking hard questions about how do these things fit into this broader web. Brining up accessibility questions around web components. Making sure that as we try to do something new and cool and different, we aren't contaminating everything around it.

Jen

Yeah. Web components is making me really nervous. I think in many ways it's because I just not learned enough about it. For those who never heard of this, in some ways it's a chance for developers to write their own HTML elements from scratch and make up all your own, whatever. Like I don't want to use [pro-graf 49:03] section and article. I want to make my own up. They're going to be called-

Simon

Right. You can define the styles with CSS and the behavior with JavaScript and the accessibility through RAS. It work.

Jen

There's a lot of people who are very excited and I think those people are smart. There's definitely something here. There's some kind of need and there's some kind of power that people are yearning for the web component's going to give them. I just do worry, like if we had already learned the lessons together and then we can move forward with this progressive enhancement as our core shared value.

It would be like, let's go, but when I look around and I just keep meeting one person after another, after another who they don't give ... about accessibility. They don't want to write their own HTML, they don't want to look up the schematics for elements. It's just like, okay, and then we're going to give them the tools to write any code, any new HTML elements, any new CSS properties that they want to. I wonder where we're going to end up after-

Simon

This is where I worry about the interaction between people and standards. I've been watching, like Addy Osmani last week was talking about creating ways to highlight components to do it right. I think that's a good start. Even if we specify that a component has to have all of these things, it's hard to actually make people do that. I am cautiously optimistic. Partly because in the long run I don't see another way to go ahead. I really hope we don't screw this one up.

Jen

Yeah. I can hear the fear in my voice or the get off my lawn. I don't like coming from that place. I have to figure out personally what I'm going to do. I got to learn, read, listen to other people more. There's something there that's really getting under my skin. I get this conversation once in the beginning in an attempt to try and figure out what that is. Even though I kind of don't have any answers, I just have grumpiness.

Simon

I think some of that things that I've done, again this is a while ago, I just kind of created my own little vocabulary and supplied CSS for it. Just to like take things for a test run. I need to spend more time with RAF, I need to spend more time with actually adding behavior to it. There are a lot of calendar examples out there which is probably good, because calendars are something computers are terrible at. I feel like on this stuff we're just at the beginning. It's too soon to tell. I like the underlying idea. I want to make sure we walk that path the right way.

Jen

Yeah. I think we all want the same thing. We want a web that really works and works for everybody and every situation that they find themselves. That works for the people who own the website as well, are responsible for maintaining it and having a teamwork on it. I know you have to run so thank you, Simon, so much.

Simon

This has been great. It's nice to actually say a lot of these things. Especially in more than a hundred and forty characters.

Jen

Yeah. You can say more words in an hour-long show than you can in a blog post. It's easier too. You don't have to edit.

Simon

Yes.

Jen

Even though it's messier. We probably said things that later I'll regret what I said.

Simon

It's usually okay.

Jen

You've sent me a bunch of stuff. You talked about a bunch of stuff. I'm going to put all those links in the show notes. People should check them out again 5by5.tv/webahead/65. I'll also put in a link because you invited me to give a key note at Fluent, thank you very much. I kind of gave a hopefully helpful pitch on why ... Like a less grumpy version of this Podcast perhaps. Less direct. Sort of saying, hey, let's remember why HTML is awesome. People can check that out and see.

Simon

I'll be blogging about that next week so maybe we can add that to the show notes later.

Jen

Yeah. Cool. Good. Again, thanks for the sponsor, Media Temple and to everybody who listens. Until next week.