alan taylor   [05.09.06 06:47 AM]

This same sort of schism became apparent to me when I was first introduced to ASP.Net. I fall squarely in the Web Developer camp, and was really floored at the way the folks at my (old) company were incorporating CSS and javascript into an app by making them properties of some server-side compiled page. The output was so spotty, the process so cumbersome, I couldn't see the appeal at all. But, from their POV, it seemed like they only had to solve these problems once, make a re-usable class and be done with it.

My shorthand for the two approaches was inside-out vs. outside-in. The ASP.Net folks liked the inside-out aspect, letting their tools create the presentation layer based on rules set by them in a comfortable environment. The Web Devs seemed to like the outside-in approach, as in "Just give me relatively unstyled data, and let me take care of the presentation and UI". A lot of it did seem to boil down to what environment you were most comfortable building websites/pages in.

Harold Neal   [05.09.06 07:17 AM]

I think part of the distinction is sometimes between those who develop sites that are primarily read-only versus those who work primarily on transactional business apps. This somewhat correlates to the terms web developer and programmer used in the posting.

Go onto many banking or reservation sites and you will find an app that does not play well with the back button. Hit that button and the session often gets in a bad state. Ajax has back button issues and can tend to complicate this sort of issue even more. There are ways around this, but they aren't simple.

Yann   [05.09.06 07:28 AM]

I am more the structured developer. I don't mind playing around with HMTL - Javascript although the quirks when testing with multiple browsers and the lack of really good debugging tools make it a lot harder. The added user experience makes it all worth it though (as long as not trying to reproduce desktop application behavior).

I have been using DWR (java env) and I like how easy it is to use. I still need to use javascript to add new table rows and the like.
I suppose it is one of the reasons why Atlas (Ms framework) might seem interesting, no need to do it, someone else already has and knows what it should look like. But I am unconfortable not having some control over what happens.

I do believe it is quite hard to come up with a one approach fits all and still think each page should be designed based on its content (still need to follow basic rules like important information should be on the top left). I see all these issues as being the learning process of client application developers (where standards are pretty well defined) swtiching to the web where there are really no one-way of writting the UI application. There is the need to overcome the problem of not really knowing what it should look like and embrace the fact that we are only bounded by our own imagination (still working on it).

Adrian Howard   [05.09.06 09:03 AM]

I think there is a division - but it's not really between "web developers" and "programmers". It's between monoculture-programmers and everybody else.

Monoculture programmers never want to leave their little ecological niche. Whether it be to learn JavaScript, Ruby or even a different framework in their language of choice.

David Evans   [05.09.06 09:12 AM]

The state of developing web pages seems to have been stagnant for the past few years. I thought the whole web services initiative would bring us a whole new crop of advanced editing tools. I'm not a developer, but I've built my share of websites since 1993. I shouldn't have to struggle so hard to make an AJAX-enabled web page. Why in the world are we still looking at raw javascript code? Where are the debugging and tracking tools and integration with Dreamweaver? Even better, the Wordpress plug-ins. Ever since I started working with Movable Type and WP I haven't touched Dreamweaver in years.

Anthony Eden   [05.09.06 09:30 AM]

The more I use Rails the less I even think about it these days. I suppose I fall into the first category as well, tending to avoid hand-coding JavaScript, but with Rails it's just soooo easy, especially with RJS now, that it's just a non-issue. Granted there are still times that I have to get down and dirty with JavaScript, but thanks to libraries like Scriptaculous and Prototype even that is much easier now than it was just a couple of years ago. One of the best things about those libraries is they really do a good job of showing you how to write good JavaScript in addition to giving you tools to write less JavaScript.

Rob   [05.09.06 09:54 AM]

Perhaps Simon should try being a professional developer before writing sneering commentary which only serves to highlight his ignorance of basic issues facing software development teams that are working on non-trivial webapps.

The fact is, there is no such divide which he asserts (possibly in an effort to make himself feel superior?). Sure there's some framework monkeys out there, but there's plenty of professional developers who can and do weigh up the pros and cons of different approaches carefully. Not every project is either a toy "My Pony's Home Page!!!1!" or Bank of America's Online banking system; there's a continuous spectrum.

In professional software development teams, one of the primary considerations when choosing a technology is productivity. AJAX comes with not inconsiderable costs in this area and in many cases the tradeoffs simply aren't worth the benefits. Yes - shock, horror - professional software developers make decisions based on the business case rather than the fad du jour.

Simon St.Laurent   [05.09.06 11:18 AM]

Hrm.... I wasn't sneering. I was reporting on the kinds of responses I've had to various proposals and projects.

It would be vastly easier for me to publish books in this area if, as you suggest, "there is no such divide which he asserts." Nor does it make me feel superior to assert the existence of such a divide. The cultural gap between programmers and web developers has caused me enormous problems over the years, and I would love to see it vanish.

Unfortunately, perhaps for both of us, when it comes to publishing, the largest markets in this space seem to be in two groups with distinct behaviors. That's not to say that there aren't people in the middle - there just aren't nearly as many of them as would make publishing in this space easy.

If it makes you feel better, I really like the divide Adrian Howard suggests above between "monoculture-programmers and everybody else". There seem to be a lot of monoculture-programmers, while it's been a long time since web developers were allowed to operate in a pure monoculture.

That may have something to do with the business cases for each group.

Hope that helps!

R. S. Doiel   [05.09.06 11:47 AM]

Are we talking about a divide or a natural devision of labor? While I am a software engineer I routinely work with web designers. Empowering the web designer makes the relationship more productive. I think in many cases this is why Ajax (particularly in libraries like prototype) have caused such a stir among web designers. With so many web applications and sites exploiting the view model controller design pattern I don't see the divide (which I think of as a division of labor) as a problem its just an observation on how things self sort.

Charlie Bowman   [05.09.06 03:32 PM]

I don't think that rails makes you decide which side of the fault you're on. It just removed the grunt work from developing.

Peter Nixey   [05.10.06 03:54 AM]

I think that Simon is right and that there is a division but that attitude is more specification than programmer-driven.

In my experience, attitude is determined by the complexity of the AJAX requirements. The more complex the requirements, the more one has to stand in the programmers camp and write careful structured code.

Sites that use AJAX to layer on a useful but possibly optional layer of functionality (like your bookmarks page on del.icio.us) require far less structured code than sites that are entirely AJAX driven like eventsites.

I've developed with both attitudes and one thing I've found is that there's a huge difference between single-page ajax applications and multiple-page apps.

Multi-page apps wipe their scope clean on each page refresh and can afford to leave loose ends whereas a single page app has to keep on working and working. The latter necessarily demand better structured code.

Pat Allan   [05.13.06 01:09 AM]

I've had some thoughts like what Simon's put forward floating round in my head for a while, but never defined to the point where I could describe them.

Most of the developers who I work with are definitely what he's labelled as 'Programmers' (or monoculture programmers, by Adrian Howard's description). I see myself somewhere in the middle - I'm certainly a lot less hesitant than my colleagues to get something done via javascript and AJAX, but I also appreciate the simpler approach of a straight server-side generated page.

That said, I don't really see the positions so divided - but perhaps that's because all developers where I work handle both server and client-side coding, so we have to use Javascript and CSS alongside C# and SQL. The difference lies in how comfortable we are to use a variety of tools (pretty much matching what Adrian Howard has pointed out).

Amy Hoy   [05.13.06 09:36 PM]

I think Simon's hypothesis comes pretty darn close, and Adrian refines it a bit as well. But I think that both of them are missing a certain something -- the factor of denial.

The "monoculture" programmers I tend to run into are in denial of what the web is... like some people who seem to want to deny the fact that we humans are largely meat bags full of water, these folks want to deny that what the web is is HTML and simplistic markup languages and the compile-into-a-page model and cross-browser issues -- because these are not romantic or interesting to them. Which is understandable, because these facts are pretty unglamorous, but denial doesn't help a damn thing.

Also, this denial seems to be an issue specific to the web, because most of the rest of the software development world is application-based and the web is the one thing that's very different. All software applications give you infinitely more control over the end user's experience and program runtime environment than web development of any sort.

That said, I don't think there's any correlation between this denial and whether the projects the people work on are mostly "read only" or highly interactive web applications. I certainly have seen it in both places. Really, there's no common thread among this camp of people other than the denial itself -- they come from all backgrounds, languages, frameworks or not, etc.

I would also argue that Ruby on Rails is not a product of that denial, but pragmatism; it allows you to avoid dealing directly with Javascript for a number of basic tasks, but on the other hand if you don't stray from the built-in Ruby helpers you can't take full advantage of what's available. In my experience, most of the folks who find the Rails helpers "good enough" aren't in the denial/monoculture/whatever camp. They have needs that fall completely into the 80% or so coverage, or they're lazy and don't make cutting-edge Javascript a priority -- which is perfectly fine as long as they can admit it :)