HTML Web App Development Still Has a Ways To Go

GMGruman writes "Neil McAllister was helping out a friend whose web developer disappeared. Neil's journey into his friend's website ended up being an archaeological dig through unstable remains, as layers of code in different languages easily broke when touched. Neil realized in that experience that the ever-growing jumble of standards, frameworks, and tools makes web application development harder than it needs to be. Although the Web is all about open standards where anyone can create variations for their specific needs and wants, Neil's experience reminded him that a tightly controlled ecosystem backed by a major vendor does make it easier to define best practices, set development targets, and deliver results with a minimum of chaos. There's something to be said for that."

Comments

This just in...

[sunking2]

Knowing how to code is easy. Being a decent software engineer isn't. 90+% of web developers fall into the first category.

Re:This just in...

[ducomputergeek]

The problem I find with web developers is that they are too busy chasing the "Ohh shiny" of the month. I've worked off and on with a development group over the years usually as their systems & database guru during the planning stages. This is usually once or twice a year. And each time they are using a different framework "Because it has killer feature xyz". But then they get into it and it seems like it won't do A or B and they end up coding their own.

Meanwhile, at the day job, we had a project that was very close to something I did 12 years ago and wrote in perl5. I dusted off the old scripts, installed, changed the path to perl to the new system and was up and running in less than an hour. I had to update a few lines of code to use new perl modules, but a decade later it still worked. We rewrote the backend to use PostgreSQL instead of flatfiles and updated the template files so the web pages generated don't look like something out of the NS4 days, but maintenance has been a breeze.

Re:This just in...

[R_Dorothy]

On the flip side: Being a decent software engineer doesn't make you a good web developer. I've had to deal with a site built by decent software engineers who didn't understand the web and it fell seriously short in SEO, content management, analytics, degradation and a slack handful of other stuff that's second nature to a decent web developer.

Re:This just in...

[Migala77]

Knowing how to code is easy. Being a decent software engineer isn't. 90+% of web developers fall into the first category.

And 90 % of developers think they are a part of that 10%. And they disagree on who else is in that category.

Re:This just in...

[Junior J. Junior III]

First, minor nitpick though it may be, HTML isn't coding, it's markup. It shouldn't require a 90th percentile web developer to craft it. All you have to do is understand and follow about 2-5 pages of straightforward rules, and you can create a valid HTML file. It's not hard. People don't do it not because they're dumb, but because they can get away with it.

HTML was designed to be as accessible to new developers as possible. If it had not been, and you could only do web development if you were in the 90th percentile of brilliant developers, it would not have taken off so explosively in the mid-90's.

HTML was originally designed to be loose and forgiving about markup errors. This was both good (HTML was fault tolerant; you could still read a page even if the author didn't mark up everything perfectly) and bad (because now the browser had to do a lot of guessing to infer the intent behind the bad markup and render it somehow, and this made things very prone to error and inconsistent rendering). Ultimately it was recognized to be bad, so W3C tightened up the rules for validating correct HTML syntax, and web developers who cared learned to appreciate the benefits of valid markup. The browser is still forgiving of invalid markup, of course, so bad markup is still tolerated. But unless the web developer recognizes the value of valid markup (consistent rendering as intended), which isn't hard to author, they will tend not to worry about validation, and will continue to think that the web ecosystem still sucks as much as it did in the late 90's when browsers from various vendors were widely inconsistent.

In the early days, the browser wars were not just about who owned the market share, but who could usurp the open standard for HTML and CSS through vendor lockin to unofficial vendor-specific HTML tags. Browser vendors thought they could win the browser wars if they could advance HTML and offer web developers incentives to develop web sites for a specific browser, and thereby steer the market toward using the preferred browser.

As a result, browser developers routinely ignored, broke, or unofficially extended W3C recommendations in ways which made web development a horrible nightmare. When W3C released HTML 4 and CSS 2.1 recommendations, it took nearly 6 years for browser vendors to deliver browsers that actually supported those standard anywhere near decently.

They STILL don't support the standards fully, 100%. W3C has never even finalized the CSS 2.1 recommendation, for that matter.

We've been stuck in a decade of HTML4/XHTML1 + CSS 2.1 stagnation. Only the last 4-5 years have been decent for web developers to fully use clean, compliant HTML4+CSS2.1, and even then only if they elect to break compatibility for outdated browsers and focus on supporting reasonably modern versions of the major browsers that have finally gotten on board with supporting the W3C recommendations.

The downside to this decade of stagnation is that we've been stuck with the limitations of HTML 4 and CSS 2.1 for a long time, long enough for other people to come up with other ideas. Things like tableless layout, fluid layout, rounded corners, transparency, server-provided fonts, multi-column text flow, and so on have frustrated web developers for the last decade. W3C really couldn't do much about it for the first half of that decade because it took browser vendors that long to just get their shit together enough to support the most recent standard. But now, they've been taking way too long to advance to the next level.

HTML 5 and CSS3 are nearly here, and are already partly supported by contemporary mainstream browsers. This is good, but we really need to see a faster adoption, especially in the advancement through the Recommendation process. Unless innovation happens on a regular basis, other players out there are bound to realize that you don't have to serve only HTML over HTTP. Microsoft has something called XAML now, which they use to build rich interfaces for Silve

C Development Still Has a Ways To Go

[Gudeldar]

It is an ever-growing jumble of different libraries, standards and tools.

"tightly controlled ecosystem"? Bullshit...

[Assmasher]

The problem with web app development is that the environment was never intended for interactivity, it was designed for displaying information. Everything added since then to create 'apps' has been bolted on (sometimes cleverly, sometimes not so cleverly) and implemented differently between browsers and (relating to plugins/extensions) differently between operating systems. Developing for x86 machines running Windows and/or Linux isn't a "tightly controlled ecosystem" but you can certainly develop excellent applications, why? Because the environment was intended to run applications.

Re:Hmmm?

[TheLink]

Nah she'll be a beautiful Web 2.0 developer once she gets out of her cocoon.

Mostly

[Poodleboy]

I can agree with all of this except the "backed by a major vendor" part, which seems superfluous... Design is all about maintaining a coherent vision of the end product, whereas hammering a tin shed on the side of the Taj Mahal is always a bad idea, particularly for maintainability and robustness. What isn't clear to me is why I need a vendor to supply my vision when I've already had years of education and experience...

Web development is hard for even talented people.

[Anonymous Coward]

Even for excellent software developers, web development is difficult. It's not the concepts that are difficult, per se, but rather the jumble of half-backed hacks that make up ever layer of the web stack. The foundation is so weak that anything built upon it just can't stand well, even if it itself is well-designed (given the constraints of web development).

Just look at the common open source technologies used by many web sites. MySQL is one buggy hack upon another. PHP is much the same, plus some security holes.

HTTP has been over-extended well beyond its original use (cookies are a hack to get around its statelessness, it's caching mechanisms are fucked to high heaven, SSL and TLS are hacks).

JavaScript is perhaps the most horrid hack of them all. Something meant for adding minor interactivity to a page has been misconstrued as being suitable for large-scale application development, although it lacks many of the most basic features necessary to do that sort of development effectively.

It's difficult enough to fight with unclear and conflicting requirements alone. Toss in shitty technology, and it becomes very difficult even for the best seasoned professionals to develop even just mediocre software systems.

The problem is not the tools...

[khendron]

The problem is not the tools (well, not *always* the tools), but the developers. You can provide the best development tools in existence to an incompetent developer, and you will end up with a crap website. It has nothing to do with the quality of the tools or the maturity of the application frameworks.

Hell, humans have been building houses for 1000s of years, yet an incompetent builder can still build a house that will fall apart. I don't think the problem is that the hammer and saw still have a ways to go.

His anecdote seems orthogonal to his point...

[fuzzyfuzzyfungus]

I honestly don't understand how an anecdote about a seriously fucked server setup is relevant in the slightest to the pros or cons of "HTML web apps" or their development.

With HTML, whether the shiniest of web 2.0 or the seriously old-school stuff, there is clear separation between the client(where "standards" such as they are, matter) and the server, which can do absolutely whatever it likes, so long as it responds correctly to a few HTTP messages.

If you want to deliver a webapp, the development of your client component is, indeed, somewhat constrained by the fact that "web standards" are more evolved than designed, and are somewhat inconsistently implemented. If you want to discuss the cons of web-apps, horror stories in this vein are the anecdote to use. If you want to discuss the pros, heroic tales of multiplatform, install-free deployment are to be used.

On the server side, though, the vices and virtues of web standards(aside from seriously uncontroversial stuff like TCP/IP and HTTP GET) are basically irrelevant. It's your server. You can do whatever you want to deliver HTML, CSS, and javascript, and interpret responses from your clients. Totally in-house stack? If you feel like it. Modestly customized OSS job? Sure. Some single-vendor enterprise development solution? If that is how you roll. The fact that somebody's web-dev fucked up and then disappeared just seems completely irrelevant(can you think of any type of development, application or otherwise, where "the developer fucked up, then disappeared, and we had to call somebody else in to do a mixture of archeology and pacification" has ever been a good thing?)

Re:"tightly controlled ecosystem"? Bullshit...

[Assmasher]

POST and DELETE

You're confusing HTTP with HTML.

If you want to get picky, 'computer' were 'never designed' for media playback, using your criteria

Uhm, you're completely missing the point. Computers don't have to be 'designed' for media playback, media playback is simply an expression of the inherent capabilities available to a computer. A web browser is an application, not an operating system or hardware, that people are trying to force into being an application container. It is not meant for these types of things. People have found ways around these shortcomings; however, they generally tend to be poor, kludgy, and overly complex. This is, again, because HTML, XHTML, and such, are not intended to be used for application development.

Flash is another example of something that was not intended to be used for application development, yet it has grown to accomodate these type of possibilities and since the introduction of Flex, it's far less horrid than previously - but it still isn't a good development environment because of all its legacy baggagejust like web browsers.

Meh

[SmallFurryCreature]

Actually, web development is pretty easy. Just that you got to stay away from the "do it all frameworks" that you want to "customize".

Either build it yourself or use off the shelf, but when you try to combine the two you get a mass.

The tools/languages he mentions all do their own things. And since when are html, xml, json and css a language? Might as well call headers in C a separate language.

Neither is cross-browser all that hard or rather, it doesn't need to be.

As an experienced web-developer I see some very simple problems with web-development:

• I want program X, now make it do Y. If you want wordpress, use wordpress. Yet what many a customer wants is to use Windows XP, then have it modded to be OS-X, with no budget, with MS supporting it. If you want to use off the shelf software then you got to use it as it is, or spend on customizing it and then accept that you got a custom solution that nobody can help you with.
• A cheap developer is often a bad developer. There is a reason I charge a high hourly rate, I know what I am doing and more importantly, what I shouldn't do. This doesn't mean I am the best programmer you can hire. A programmer punches code. A developer gets you a working site. Anyone can punch out code but you will all to often end up with something that just doesn't work.
• Outsource only if you are a master at cross-culture communication. Indians, Chinese, East-europeans, they just ain't got the same attitude as you do. Granted I only see the bad examples, were someone has outsourced a project, it turned bad and I am asked to clean it up, but there is so much work with this that i wonder if it ever goes right. And the outsourced code is often so fucking bad, you got to wonder how old the people involved were.
• Know your tools. Really, what truck driver doesn't know anything about trucks? For that matter, what shipping company director doesn't know anything about trucks? We often don't realize how much we know about stuff, does a shop owner know a thing or to about real estate? That a door should be 2 meters tall or more? That it is handy if the door opens if you push on it? That lights inyour shop are handy? All basics stuff, but many have no idea at all about their own website. And if you don't know the basics, then how can you judge wether you got value for money? it would be like hiring someone to maintain a garden when you have never seen a garden, don't even know what the word means.
• Time/Costs/Money. The web for a lot of customers is often what their little nephew did with the wedding pictures. Cute but hardly something that you want to build your company on. A webshop/site is expensive, especially if you want it customized. Renting a physical store isn't all that hard, but when you are done making it your store you are looking at a huge bill, and the same goes for your online presence.
• Know what you want. Developers like me charge by the hour, so if you spend all day calling me up trying to determine the font/color of a something on your site, that will get you neat bill at the end. Yes, just for changing the color. If I don't charge you direct, I will do it indirect. KNOW what you want. If you are building a house, you don't tell the brick layer to tear the walls down again because you want to try a different look do you?
• And finally. CONTENT. Get your content ready in time. I seen plenty of projects delayed endlessly because the content takes to long to be produced. A site needs content and anytime between delivery of the site and you getting it up and running is lost revenue.

Really, web development ain't all that hard, but the customers often make it far more expensive then it needs to be.

Re:Web development is hard for even talented peopl

[mujadaddy]

Say I want to write a speech synthesizer in JavaScript.

There is no emoticon for what I am feeling.

Re:"too many frameworks"

[coryking]

Off the top of my head, here are a few problems with the mryiad of many frameworks for the web:
1) The super-ultra-awesome slider you want is for YUI but the rest of your site uses jQuery. If you want to use it, you'll have to have the browser pull down both jQuery AND YUI.
2) Many of the frameworks conflict--prototype, for example, doesn't play nicely with a bunch of other frameworks.
3) Each framework added to your stack increases the number of moving parts on your site. More moving parts = more chance for error.

Seriously, it is a cruel joke when you find the-most-perfect-rich-text-editor but it was for MooTools instead of YUI.

*That* is my problem with having so many frameworks. The world would be a better place if we all just used jQuery :-)

Web Development

[hackus]

There are a couple of problems I see in web development:

1) Unlike the systems programmers, myself included, for a given topic area tools are adopted and standardized.

Web developers seem to get jobs based on the flavor scripting language of the year.
(All of which is crap in my opinion....i.e. php, javascript....python...)

It always seemd too me, that XML, XSLT CSS and Java servlets are really all you need and you can build marvelous interfaces. Tried that once, but the response I got was (thats too hard, lets use javascript).

2) The closest I have come to a decent application framework for building web apps is Java. It has clear security controls, recognizes the importance of Virtual Machine technology to compartmentalize access in a dangerous online world. It even has a very straightforward debugging environment which is quite impressive to track down bugs.

But curiously, it is shunned because if you don't know the scripting language flavor of the day, people don't want to build web sites or won't hire you.

Which is one of the reasons why I don't write web applications anymore. Because when your job and pay is based on how fast you can memorize the scripting flavor of the year, and it doesn't bring anything new to the table (in many ways it can be even worse) to solve the problem of writing a web app, well...it becomes just a money game.

I mean really, I don't mind learning new languages, but I haven't seen anything new since Java 1.6 was released that is any better...just mostly worse.

3) Finally the field has become too greedy. I mean, there is no reason why it has taken this long to standardize video and audio, except for the fact that greed is everywhere.

It is really sort of disgusting, and the crap you have to go through to get video onto a persons browser is just way over the top, mainly due to Adobe and Apple being greedy idiots.

Maybe when the Video and Audio tags get full support for open protocols I will write web apps again. It isn't rocket science, but it is currently a science of idiocy.

-Hack

Re:"a ways" to go? From a veteran editor...

[dcollins]

Colloquial/idiomatic.

ways
–noun (used with a singular verb)
way (defs. 7, 14, 20a).

Usage Note: ... In American English ways is often used as an equivalent of way in phrases such as a long ways to go. The usage is acceptable but is usually considered informal.

http://dictionary.reference.com/browse/ways