Bill Cava: I started the conversation today by asking Ted about the challenges he sees facing front-end developers in general on the web today.

Ted Henry: Well, I think as a UI developer, at least in my experience, I felt like I have had to learn the language of backend developers in order to get my vision for UI implemention. And there have been several projects along the way at Ektron that have tried to bridge the gap, I guess, between the needs of -- expressing the needs of a front-end engineer in terms of data structures and the flexibility of mark up and all that into the backend, and that stuff that we are really doing now with the Templated Server Control project.

But that’s been sort of a dream because prior to now like a lot of Ektron developers, you are limited to EkML, XSLT, in some cases, you had data binding. So I found that the biggest challenge has been as a UI developer is one of my limited buy by what a backend developer essentially compiled into a control. So, that’s been one of the main things that I have been trying to work on since I started with Ektron.

Bill Cava: So you mentioned the templated controls.

Ted Henry: Yeah.

Bill Cava: So do you want to talk a little bit about that?

Ted Henry: Sure. The templated controls are, in some ways, a response to the lack of flexibility in a traditional control set that we have shipped. They are based on MVC, the MVC pattern of the project type. And the idea is to give an Ektron developer complete control over the markup so that a designer can do whatever they want.

Bill Cava: What’s your perspective of there challenges you see facing front-end developers today?

Keith Pepin I think a lot of the challenges facing front-end developers are the ones that have been there for my whole career. Back in the early days, in the browser wars, you were constantly dealing with the differences between the two different browsers, the two different clients, how they render something, the objects that you use that you can get it to render when you are talking about JavaScript, and that sort of thing.

Unfortunately, those still haven’t gone away. The good news is that they’ve gotten a whole lot better with the different libraries and frameworks that are available, CSS frameworks and JavaScript libraries to make cross browser coding just so much easier than it used to be, and the fact that the browsers standards have gotten much better corral. They are still not perfect, but with standards compliant browsers, you can be reasonably confident that when you write this line of code or you write this bit of markup that it’s going to render the way that you expect.

I think the disappointing thing for some developers is that there is a lot of cool stuff out there right now that you really want to work with. Some of the stuff are HTML5 and CSS3 and if you are in a corporate environment, for example, your stock is still supporting those older browsers that don’t understand those things yet. So you have to make choices.

You have to decide, am I going to fall back gracefully, am I going to provide some sort of UI that’s close to my vision but not really what I wanted and use some of these advanced features for the people that do have support for it, or am I going to try to provide a 100% consistent interface across all browsers in which case I have to work with the limited set of tools and options and techniques.

So I think those challenges are always there for the front-end developers. It’s definitely something that I think front-end developers deal with very differently than a backend developer. The backend developer doesn’t worry about that.

(00:04:58)

They’re dealing on their platform; they have their set of objects. That's what works for whatever code they’re writing. But the front-end developers, you have to write code that works across 16 or 17 different operating system and browser combinations.

Ted Henry: I’ve found that in space. A web developer keeps a matrix in their head of what works in this and what works in that and what doesn’t work, and where backend developer, if it compiles, you’re fairly safe.

Keith Pepin: Right.

Ted Henry: The web developer often times, the only time you have to know that something doesn’t work is when you see it on the screen.

Keith Pepin: Yeah, that one operating system way off in the distance and it just happens to render differently for that one platform.

Bill Cava: So you said some of the problems that you face today are the same ones that you’ve always faced. So look to the future and then say what problems do you see front-end developers facing over the next year to five years? Are they the same problems that you have been facing? Are they different challenges?

Keith Pepin: I think some of them are got to be the same, but like I said, the future looks better. Now with libraries like jQuery, cross-browser compatibility is so much easier. It used to be you have to code all of that cross-browser compatibility yourself.

Keith Pepin: And now with a lot of the libraries out there, they’ve done a lot of that thinking for you, so you call this method, and you’re again, fairly confident, it’s going to work. Same thing with the CSS techniques and frameworks that are out there as well; they really do make it a lot easier to build some of these applications. But you still have to worry about it, and in the future, while I think it’ll be easier, I think browser development from what I've seen and the release of browsers happens so much faster now.

Microsoft recently retooled their release and development cycles so that they can release a new version of IE that much faster because they’re trying to keep up with Google and Firefox, Google in particular though. So for example, IE 10 --

Ted Henry: IE 10. Yeah, that’s right.

Keith Pepin: Yeah, but at the end of the year. We waited how long for IE 9 to come along. So I think that kind of rapid development will help in the sense that I think there's a much better move to corral things with the standards that are out there now and to make the browsers more standards compliant which has been a dream in some sense for those of us, they have standard compliance browser. We’re working with Firefox, Chrome, Safari, and Opera. I can be relatively certain that my code is going to work on all of those, and it’s always for the past several years, it’s been IE that’s kind of like this redheaded stepchild that I have to coax along to sort of get to where I needed to be and to get it to do the things the needs to do.

IE 9 has come a lot closer. I think they’re still not there yet, but I think as they release more iterations more rapidly, then we’re going to get closer and closer to having sort of the nirvana which for me is I write one line of code, I expect it to work. It's going to work, just like the guys in the backend. They right their code and they compile.

Ted Henry: I was to going to say, absolutely from a web developer’s perspective, the code that we write will get easier in a sense as the browsers all support the Microsoft mantra of -- I forgot exactly what it is the right ones. It’s the same code same markup, same code same markup, but it’s what works in Firefox should work in IE. That's what they're going for. I think that’s absolutely true that at that level of things it’s getting easier.

However, I think overall for a web developer -- well, a web development team like ours that the future is going to get a lot harder in a sense because the expectations for UI are going way up now.

Keith Pepin: That’s true.

Ted Henry: Yesterday was a nice to have; today is yeah, that’s great; tomorrow is going to be a problem if it’s not there.

Bill Cava: Give us the example of something like that just to give a sense of what you mean.

Ted Henry: Most of the thing that jQuery UI does, for example, I mean dialogs and datepicker and as the expectations go up for the front-end stuff, so does the code that is hardest to manage. We have a ton of JavaScript that we’re writing with now that gets managed differently than a .NET code does.

(00:10:03)

.NET code has compile errors, we have build time errors, we have even run time errors that come with a call stack and a bunch of things that sort of pinpoint that where the error came from. We have a development process in place when there’s ever any kind of .NET error, the whole engineering department goes into a particular mode in order to fix it. Phone calls are made in some cases. The build is broke, okay, well, somebody has to fix it.

With JavaScript, the expectation is getting higher for front-end development, but if the processes to support that don't match that, then you tend to having JavaScript everywhere, and the only way that you ever know if it doesn’t work is in some QA test that from a management perspective that’s kind of -- I think what leads to things like Silverlight, I mean, Silverlight is UI that’s managed and compiled and much simpler to manage in that sense.

So I think it’s going to -- I think in some case from the web developer perspective as Keith was saying, there are certain things that are going to go a lot easier, but from any kind of web app that needs to scale in terms of size and feature support and all that, it’s also going to go a lot harder.

Bill Cava: So let’s get segued into the Silverlight conversation that I wanted to have which I remember at PC 9 and PC 10, Microsoft is talking a lot about Silverlight and HTML5 in two different threads, almost two different parallel threads. So you have the IE 9 talking about all the stuff they were doing with the rendering engines and they’re talking about all those fantastic stuff with HTML5 that they were supporting. And in a separate parallel thread, they were also talking about Silverlight and all the amazing RIA apps you could build with Silverlight.

So at the time, there was sort of a discussion internally at Ektron around what ultimately would win out, because although Microsoft is trying to position it in such a way to make it seem like HTML5 and Silverlight weren’t competing, it’s obvious that those two teams were solving very similar problems and having the same conversations about how to solve these problems in very different ways.

So we had conversations about what would win out.

Keith Pepin: Yes, I remember.

Bill Cava: And here we are in almost 2012, and Silverlight has been sort of relegated to the development platform for Windows Phone 7. And Microsoft is saying that Silverlight is still supported; it’s still a development platform for building RIA. But when they talk about building rich interactive applications for the web, they talk about HTML5.

Keith Pepin: Yeah, right. HTML5, JavaScript, and CSS3.

Ted Henry: Yeah.

Keith Pepin: Yeah.

Bill Cava: So I know that was something you had strong opinions about.

Keith Pepin: I had very strong opinions about it, yeah. I guess I still do. To me, it was fairly obvious that there are just huge leaps and bounce have been made in just the past, I don’t know, five to ten years on the front-end side because desktop computing has gotten so much faster and more powerful. The scripts that you write in JavaScript execute so much faster, even though they’re not compiled. And what you’re capable of doing in the browser as a result is light years ahead of when I first started in the business, and now you can build these huge rich applications using the same techniques and the same kind of coding that we were doing 15 years ago. But now you can do so much more with it that HTML5 and CSS3 and JavaScript have just come so much farther, and the fact that the browsers now are retooling their JavaScript engines completely to allow you to take advantage of their computing power.

It allows you to build such a richer application now in the browser, and do a lot, I mean -- there is an amazing applications out there that people have made that you swear to God, if you’ve been around the front-end for a long time, you take an initial glance at it. You’re like, oh, that has to be Flash, that has to be Silverlight or something like that, some sort of plug-in. No, it's just bunch of divs on the page, some JavaScript running in the background, maybe some AJAX calls back and forth the server issues for some data points.

But you see these rich three-dimensional worlds being built by people all in the browser now.

(00:14:59)

So to me like there’s still a need for someone -- like there is a niche for Flash and for Silverlight, but because I don’t have to learn anything new to build these same rich applications with HTML5 and JavaScript, may be there was a few more objects I can take advantage of, may be there is a few more tricks, but the underlying skill set is exactly the same that I have held it for long time.

Ted Henry: I think you nailed it, right?

Keith Pepin: Yeah.

Ted Henry: Because when I think about Silverlight, I can think of a lot of very attractive things about that both from a UI developer perspective and from somebody who is responsible for building components that can be tested and delivered and counted on to work. So Silverlight has a lot of attractive things about it, but I think from my perspective, there is a skills issue. And not only just a skills issue, but how those skills were acquired because if you look at, if you think about Keith and I and our backgrounds or I don’t think atypical for web developers, that’s not necessarily out of a traditional computer science background, and self-taught out of interest and passion.

So we are talking about there is a matrix that a web developer builds up in their head that this works in this browser, this doesn’t work in that browser. And you get a lot of momentum behind that about what works and how to do things. I mean Silverlight has C# built into it. I love C#, it’s great. But for UI stuff, it’s well, wait a minute, I know if I just use -- this was jQuery, I’d used the selector and bind to this event, I would be done. But for Silverlight, there is a whole new language and framework to learn to build it. This is what you were talking about.

On mass, you have a lot of people who are good programmers, but they don’t know anything about C#. They know a lot about JavaScript because they have had to learn it and they have had to learn it because somebody who knows C# isn’t front-end enough to know how to do it. So you have to be self-taught in a way. So I don’t think it’s they were up against the skills barrier -- even Flash --

Bill Cava: When you said that you are saying the Silverlight Team.

Ted Henry: I am saying that yes, the Silverlight team and -- well, both Silverlight and Flash, it’s like Flash has its niche like you were saying and Silverlight will too. There is all this momentum behind these web standard technologies that people have put blood, sweat, and tears in the learning.

Keith Pepin: And Flash is interesting too because I mean Flash, ActionScript, essentially JavaScript under the hood with a whole lot of other objects. But even then like there is this barrier for a lot of developers to get into Flash development and it was interesting to watch who became Flash developers. A lot of times, it was the visual folks that already knew the tools that were very similar to the Flash development suite. So they only had to learn a few extra things to become a Flash developer and they could build things visually.

And then there was these other set of Flash developers that learned how to do it from the programming perspective. They were largely JavaScripters, they learned ActionScript, they learned some of the other objects they could play with and they became good Flash developers. But it’s still sort of this niche and there is this like hurdle to get over.

Silverlight has all of that plus more because it’s a different language that has completely different tool. It doesn’t have that same history where folks can transfer it from these other tools that they are familiar with and here is another one that has same sort of palette tools and the same sort of constructors that they are sort of used to, plus a few extras.

Silverlight was like completely different. It’s a very different interface when you are developing on it for the first time and that’s a hurdle. If I can do all of the same things; HTML, CSS and JavaScript, why don’t I build it with what I know? I can get this done today without that learning curve. I think that’s one of the reason why internally with Microsoft, why you are hearing more now that okay, Silverlight is kind of like on the back burner, this is it.

But there’s also been other technologies that came along and choices other folks have made in the industry that helped further that along. I mean you look at the iPhone and the iPad and how they just basically said no, we are not doing Flash. You are not going to get that; you are going to get HTML5, you are going to get CSS, you are going to get JavaScript, and the apps that are built on that are amazing, just that choice.

(00:20:01)

Keith Pepin: Okay, well, if I want my stuff to work on an iPhone or an iPad, what I can use the same skills and tools that are already now to develop that. That’s powerful.

Bill Cava: So one of the things that Silverlight gave you that that current frameworks on the HTML5, JavaScript, CSS don’t, is all the stuff around debugging, the stack trace that you were talking about, and all that stuff. So that’s sort of what was enticing, I think, for many developers access to all that stuff and develop an environment.

Keith Pepin: Yeah, absolutely.

Ted Henry: I am totally agreed. I mean I look at that stuff now and I think it’s the idea of XAML that a designer designs a site expressed in XAML and then it’s picked up by a C# developer and it is creating this elegant in a way handoff between two sides of the application development world that don't tend to communicate very well.

Bill Cava: Do you see a hope for the open WebStack in terms of getting to the point where we have the tools in place to do the same level of debugging and diagnosing and development that we could do on Silverlight?

Ted Henry: I’ll be controversial now to say no and I’ll tell you why. At one point, I had hoped that we might with XHTML. I have a deep, I guess, background in XML and XSLT way back in the day. And I guess, I'm in some way indoctrinated into thinking about markup that way, that markup either validates or it doesn’t. And the idea of tags that don’t self-close is completely weird to me.

So XHTML to me was something I wanted XHTML 1.1. That’s what I wanted; strict XHTML 1.1. It validates or it doesn’t. If it doesn’t validate, hence that’s a P1 defect and you got to fix that. Well, that’s obviously didn’t work out too well. And you can see this, and that now this is one thing about browser developers that I'm sympathetic to, but I don’t understand is that browser developers are quite sympathetic to TagSoup. You put basically anything that looks like markup into the page and the browser will somehow -- the parser will somehow figure out what to do there or at least try to. With JavaScript, not so much; JavaScript, they’re quite willing to choke on terrible JavaScript, but not that way with markup.

So I think even in the future with HTML5, okay, that’s more than just markup, but we are going to live in a world where the browser manufacturers are going to tolerate really, really bad markup. So the idea that we can get to some sort of like almost compilation error with a web document, to me, it’s just not going to happen. It’s somebody will forget to close a tag, maybe an ending tag won't be there at some point or there will be non-standard attributes on elements that markup will not validate. I grudgingly accept that and I don’t like it, but I grudgingly accept it, and I will implement XHTML because I just cannot close tags that don’t have an end tag to go on.

I think that it's going to be very difficult, and the other thing is that with .NET, you have built-in tool support for Microsoft. But I mean for JavaScript, what do you have? You have JSLint pretty much in all, and there’s JSHint. There’s some parsing stuff that’s built into Visual Studio but is not -- it’s who owns that; nobody. So it’s --

Bill Cava: It’s nowhere near what you can do with Silverlight?

Ted Henry: It’s nowhere near what you can do with Silverlight, exactly. So we're in, I think, for a bumpy ride.

Keith Pepin: See, this is where the conversation gets interesting because I'm going to take the counterpoint. I actually think we will get there. The tools that are available now are so much further ahead than where we used to be for automating the testing of these things. JSLint, absolutely, that’s built into a lot of different test suites, but there is some fantastic automated tools out there now for testing your JavaScript. So I agree; we're not there yet and the actual markup I think is still problematic.

Ted Henry: We try to put anything in there.

(00:24:56)

Keith Pepin: But I think we can get there. I mean again, I go back to the browser standards and all the browsers coming closer and closer to sort of rendering things the same way, will sort of reach the same level that we can with our service side code debugging techniques. The tools available now again I think are a lot farther ahead than they ever have been and I see them getting closer to that.

Ted Henry: And another thing that we are doing besides tool support to address the problems that come along with HTML, CSS, JavaScript images is that I think traditionally that UI is handled by finding somebody who is good at it and saying okay, I am going to put him on this or her on this job. The problem is that that doesn’t scale. So you have something, some huge web app that you are trying to build. You are going to need more than one developer to work on it. And then you are in a way kind of relying on their ability to communicate and to share standards around which they are doing things in order to ensure consistency throughout your web app.

So one of the things that we are working on is along with the templated server controls, which expose CMS functionality, and our MVC and the view is completely open, it’s all data binding, you can do whatever you want with it as far as markup. There is another class of control that we are creating that is called Ektron UI.

And what Ektron UI is, is an attempt to implement atomic, but complex, UI elements that are difficult to create for a variety of reasons into .NET server controls that things like -- or like what jQuery UI does to implement, to integrate jQuery UI, datepicker and modals and tabs in a query and stuff like that with .NET in such a way that it’s easy for a .NET developer to implement it. But there is a core group of UI developers who build these things in the first place. So this difficult UI is built by the people who know it best, but then can be utilized by .NET developers who may not know anything about UI.