Anyone Feel Current Web Technologies Are Working Against Modern Web Developers?

For the last 3 years or so, I’ve been getting an ever stronger feeling that the current web standards are becoming more and more inappropriate as the web evolves, to the point that they begin to hinder web developers to perform relatively common and basic tasks, potentially crippling the evolution of the web as a result.

The source of the problem seems to be that the core concept which all the main web standards are modeled around, is the concept of a ‘document’, which itself is modeled around ‘text’, where ‘text’ is the first-class citizen of the web. HTTP, HTML and CSS are all based around this core concept. These technologies seem to imply it’s still assumed that website are merely a collection of semantic documents, and thus these tools have been tailored to fulfill those requirements.

These technologies generally assume that a web document is a relatively static resource that flows from left-to-right, top-to-bottom, and are laid out and marked up like traditional printed or written informational documents. This obviously wouldn’t be a problem if that’s what we were all trying to build, but I’d dare say the majority of new websites do not map very well to that assumed document model.

This gives rise to a number of problems which just about every developer (or maybe I should say designer) must deal with on a daily basis. They include:

  • Vertical alignment: There’s still trivial way of centering content vertically, especially if that content has a dynamic height.
  • Shrink wrapping and vertical stretching: Controlling the behavior of how elements are sized can normally only be achieved by altering the display properties of an element, which often has other effects you didn’t intend. Vertically stretching elements can is relatively painful.
  • Inline blocks: Aligning blocks horizontally is still a major problem. Using display: inline-block often introduces undesirable spacing between elements. Other display options like table-cell introduce other side effects. Floating elements are not without their side-effects either, often limiting their usefulness.
  • Advanced positioning: For example, fixing an element on a single axis is currently not possible. Think of a table heading where you want the heading to be horizontally scrollable with the rest of tables contents, but which should always be displayed at the top.
  • Stateless protocol with one-way client-server model: HTTP is designed for serving textual information, not as a means to transport application data between client and server, and vice versa. HTTP probably shows it’s age more clearly than the rest of the web standards.

These are just things I’ve encountered over the last two days trying to implement what I thought were pretty simple web designs. What’s worth noting however is that these designs were for web applications which don’t normally fit too well with the assumptions made by our core web technologies.

Now, I would love to know if others have come to similar conclusions to what I have, and whether or not you believe work should begin on a new set of web technologies that throw the concepts of hypertext and documents out the window. I personally can’t help but see the more recent additions to HTTP, HTML and CSS as band-aid solutions to fundamental problems.


and whether or not you believe work should begin on a new set of web technologies that throw the concepts of hypertext and documents out the window.

This is where CSS3 (like flexbox), Web Sockets (push polling), LocalStorage&SessionStorage, Indexed DB, GeoLocation, Canvas API, SVG, WOFF, Web Workers, WebGL and all that jazz is for.

Making clients act like servers (storing data, holding a mini database, sending requests TO the server), acting like Desktop OS applications (running scripts that talk directly to YOUR hardware, caching stuff, storing things from the web randomly in your file system), and generally not having anything to do with documents and text at all (web applications, drawing on web sites, Javascript required to actually read any text because it turns out, it’s not text).

As far as HTTP, the almighty Googles have come out with SPDY. Of course, it works like OperaMini does: all the data going either way of course has to go through their servers. Hmm, hmmm.

However if it were adopted as a standard and all the servers used it in place of HTTP, that could maybe be a possibility.

While some of those are certainly welcome additions, some others seem rather awkwardly tacked on. My biggest concern however is how bloated and complicated the specifications seem to be getting. The more stuff we add, the harder it’ll be for new browsers to enter the market, and the more bugs there will be in current browsers. Just play with some of the more recent additions to modern browsers, and you’ll often find significant implementation differences between browsers. Sometimes their vendor bugs, where as on other occasions it’s simply due to the spec being too ambiguous.

I just can’t help but think there’s a simpler way to build both document orientated websites, and web applications. I don’t mind HTML as a syntax, and I really quite like the syntax of CSS, but the specs just seem to be rife with excess bloat. The improvements that are being introduced such as CSS3 can’t really be called evolutionary steps, as really nothing old has changed, only new stuff has been added - not my definition of evolution anyway. What we need is indeed an evolution, one that actually breaks backwards compatibility. Microsoft Windows is a fine example of a where a complete break in backwards compatibility could do wonders for OS evolution.

In my opinion, the web standards need to become more generic and less assuming, which should make them simpler as a result. There’d be less repetition, and less stuff to remember. Like why do we need so many options for the display property? I’m sure just a few such as ‘block’ and ‘inline’ (which should behave like an inline-block). You could then add a separate property to control how the element is sized (e.g. shrink-wrapped, fill available space, etc).

I’m just frustrated with wasting time trying to do simple things, like get a block to fill 100% of the height of its parent. There’s currently way too much problem solving required these days to achieve simple UI layouts, and I’d consider myself quite proficient with CSS. Anyone new to CSS would have no hope.

What we need is indeed an evolution, one that actually breaks backwards compatibility.

Ah, but see, they tried that. It was called XHTML2, and it failed precisely because nobody was going to be the first (and possibly only) to spend a lot of developer time building yet another completely different parsing engine, when chances were that their competitors would spend that same time and developer power making something the public would oooh and aaah over. That, and one vendor flat-out refused anyway.

Breaking backwards compatibility breaks everything and segregates us (users).

Microsoft Windows is a fine example of a where a complete break in backwards compatibility could do wonders for OS evolution.

My uncle is still running Windows 95. Or 98, I forget. It works for him, and everyone around him upgraded because they were doing the “hardware gets replaced every couple of years” thing.
However, converting every server in the world to understand something new to replace HTTP… I’m not going to say it’s not possible. I don’t think it would be easy. I’m also not sure what authority could enforce it. MS could at least tell itself what to do.

but the specs just seem to be rife with excess bloat.

Partially because those who write it are rife with excess politics. In my opinion.

In my opinion, the web standards need to become more generic and less assuming, which should make them simpler as a result.

Generic, we’d love, but vendors have to build for that too. A million exceptions and special use cases just quadrupled. And all the regular fights regarding the WCAG1 were partially because it was very vague. Most of the browser inconsistencies (the ones not caused by outright bugs), such as whether inline-block elements should treat whitespace between them like inline elements do or not, or whether tables can be positioned ancestors, are caused by generalisations in the specs, where one vendor decides yes and another decides no.

I’m still not a fan of HTML5, but I think the unified error rendering parse rules are a good thing: they can go ahead and be a bazillion pages long. They are not for us, but for the vendors, telling them in every possible use case exactly what they are supposed to do. Even though personally I have benefitted from browsers having radically different error rendering… often it’s that one browser who alerts me that I haven’t checked new code in the validator.

some others seem rather awkwardly tacked on.

Yeah. And most are unfinished. SVG is pretty old, but I hear talk of adding more stuff to it (I think mostly to make it have similar rules as <canvas> does in 2d mode).

The more stuff we add, the harder it’ll be for new browsers to enter the market, and the more bugs there will be in current browsers.

I’m not sure I’d praise with joy the arrival of a wholly new browser :slight_smile: but, yes. Also, the security concerns of many of these new additions seems to sit on the back burner a lot… like, let’s get something working first before deciding how the UA is supposed to deal with the possible security implications.

Like why do we need so many options for the display property?

Because designers want many options for display? Making it simpler necessarily reduces what you can do with them.

I’m just frustrated with wasting time trying to do simple things, like get a block to fill 100% of the height of its parent. There’s currently way too much problem solving required these days to achieve simple UI layouts, and I’d consider myself quite proficient with CSS. Anyone new to CSS would have no hope.

Yeah. Since CSS is all pretteh and cute for me, I usually end up faking a lot of that stuff. CSS does have limits. To me, not being able to walk the DOM like Javascript can is a severe limitation of CSS.

I do like trying out challenges of pages, or learning a neat trick from someone else on how to tackle a particular problem. It’s prolly what keeps me from getting bored with front-end stuff.

What you have to remember is that you aren’t just building websites for people using IE8/Fx4/Chrome on a modern PC over a good connection. Your site has to be able to work in different situations, including older browsers, slow connections, mobile devices and so on. And so it’s all very well pushing the boundaries and saying you want to break backwards compatibility, but in doing so you will necessarily be alienating a significant chunk of your potential audience … however you go about it.

Yes, there are difficulties in getting the layout right, principally around vertical alignment. I don’t know why this has remained a problem for so long, but I’m fairly sure there are methods in CSS3 that should resolve this, as and when it becomes widely enough deployed that it’s safe to use. But beyond that, you run into the problem that the more advanced and complicated you make your website, particularly around interaction technology, the more people you’re going to prevent from using it.

I’m not sure how any of that squares with your first paragraph:

For the last 3 years or so, I’ve been getting an ever stronger feeling that the current web standards are becoming more and more inappropriate as the web evolves, to the point that they begin to hinder web developers to perform relatively common and basic tasks, potentially crippling the evolution of the web as a result.

The problem isn’t that technology and standards moving in ways that are inappropriate and causing a hindrance … the problem is that the technology and standards aren’t moving quickly enough in the right direction. And even if they were, it wouldn’t get around the issue of people having old systems that wouldn’t understand the new technology even if it was a standard.

Good replies guys. It’s nice not getting flamed just because your opinion differs from the general population, though SitePoint’s always been pretty good in that regard. It’s a bonus when you actually get intelligent insight which you can learn from, like what you guys have provided.

There are situations, especially with web applications, where you don’t have to support as wide of an array as you would if building a general website. As I see it, it would take just as long to implement a completely new spec, as it would for CSS3 to become usable in the mainstream.

The original idea behind web standards I thought was that you could make breaking changes in the spec without concern for older browsers. That was the whole point of the different CSS and HTML versions. If your target audience didn’t support CSS 2.1, then you’d just use CSS 2 without a problem. We don’t seem to have that however. Though it probably wouldn’t be too hard to add. Let’s say that for CSS 4, they introduced a version specifier, where the stylesheet would only be interpreted as CSS 4 if it specified that it was CSS 4. That would be a step in the right direction. If you wanted to support older browsers but wanted to use CSS 4 to enhance the experience of newer browsers, then like today, you could use two stylesheets.

I do agree with the first part of that paragraph. As for the second part, that comes back to the poor version management we have with the current standards. <noscript> and IE’s conditional HTML comments are still the best we have for sniffing browsers and feature support without resorting to javascript, which one can’t rely on.

I find it interesting that your recommending the specifications be more generic yet the problems you have cited are fairly specific. In my opinion I think css2 does the good job providing tools for accomplishing just about every visual task you just need to know how to use it. Granted some of things uyiy cited are not possible to accomplish with CSS but JavaScript can be added in a gracefully degrading manor to accomplish those design goals. I think the specification is pretty hood as it is of course it’s not perfect but nothing will ever be perfect. For what it us and meant to accomplish it’s pretty good imo.

I think it’s your interpretation of what I mean by generic. By generic, I mean to be less assuming. HTML and CSS seem to be too assuming, and therefore I find many properties are too specialized, which can create a lot of overlap, and can often be the cause of the more subtle differences between browsers.

I think the ‘display’ property stands as a good example. The display options alter many different things, such as whether an element is inline (i.e within the flow of text), whether the element is shrink-wrapped or stretch-to-fit, whether it’s a box, and with the introduction of the table display options, many other subtle things. Often I find one display option to be suitable, but there’s often a specific characteristic of it I find undesirable which can often prevent me from using it. I’d much rather have separate properties for controlling these characteristics (thus my definition of making the CSS more generic), rather than hoping for a predefined combination of characteristics that fits my specific requirements. Overall, a more generic spec will give greater control to the developer, and provide more flexibility and possibilities, while simplifying the spec. How would anyone, unless they read the spec or did extensive testing, know all the effects of ‘display: table-cell’?

So I guess I’m saying to break down properties into their simplest and clearest form, even if that means we end up with more properties overall, it’ll probably still be easier to learn, read and write.

Using HTML and CSS for specifying a layout isn’t that unlike other languages that don’t have to worry much about being standards compliant.

For example, Flex using a UI system which is tag based (like HTML) and very similar in other regards.

Java’s GridBag layouts act very similar in some regards as HTML (filling available space, etc.).

There are some quirks that we fight with that are still odd (like vertical layout), but that’s just because it hasn’t evolved far enough. I think it’s going to get there, it’s just slow because there are so many hands in the pot.

I personally have never had an issue where I’ve had to say “I just can’t get this how I want”. Sometimes I’ve had to get creative, but it’s never been something I can’t possibly do. You can also always use something like Actionscript or Java to create web applications as well, if you feel you need finer grain controls.

I personally like our options now and want to see HTML and CSS to continue to evolve, but I don’t want to see it completely uprooted.

I’ll admit, there’s only been a few instances where I’ve had to depend on javascript to achieve a layout, but what’s most frustrating is the time it can sometimes take to solve a layout problem that seems common and trivial. That’s what gave rise to the title of this thread. Sometimes, after you’ve tried about 10 different methods of getting a simple UI element to display correctly, you could swear that someone’s conspired against you in an attempt to make your life hell.

For example, I’ve been battling a relatively simple problem on and off for the last couple of days on a personal project I’m working on. I’ve been trying to make a block element stretch to 100% of the height of its parent. I’m using ‘display: table-cell’ on the parent div to get around the spacing issues of ‘inline-block’, but that seems to have the consequence of preventing ‘height: 100%;’ from working. Resorting to absolute position doesn’t work either, as elements can’t be absolutely positioned within their parent if the parent is a table-cell, at least in Firefox 5. I’ve thought about floating the parent div, but then that introduces a whole other set of challenges. My point being is that everything I try to get around this just seems to dig the whole deeper, to the point that I’m thinking of just changing the UI. Turns out ‘height: 100%’ only works when the parent as a defined height - that doesn’t even make sense. It was the same story before they introduced the box-sizing attribute. You’re much more likely to want to include the padding and the border as part of an elements dimensions, so why not make that the default? This seems to be the story of my life when it comes to HTML and CSS.

The thing is, I could happily live with any one of those things, but it’s the collective that really kills my spirits. I guess in the past, all of these challenges were overshadowed by IE6, but now that I no longer give a damn about IE6, these things become major pains in the ass. I have to admit though, that despite my complaining, I’m still quite impressed with the state of our web technologies, considering that their all open standards, with many different vendors of renderers, etc. Samanime touches on this with his post, giving examples of how other proprietry technologies have drawn inspiration from our open web technologies. Maybe it’s so frustrating because HTML and CSS are so fantastic 90% of the time.

It feels like we’re at that point where we need to apply what we’ve learnt over the last decade, to a clean new set of technologies. It’s not the syntax I’m concerned about (HTML and CSS I love), it’s just the misdirection of the past. I don’t see why we need to bring forward all those mistakes. I’d love to see HTML and CSS trimmed right back to their bare essentials, and have only the best ideas of the last decade put back in. Call them HTML 6 and CSS 4.

But without a height set on the parent, it will only be as tall as its content. How else would it know how tall to be? Makes sense to me.

Not necessarily. In my case, the parent is 93px tall, but that’s not because it’s height is set to 93px, but because it’s display is set to ‘table-cell’, so it’s starting height is determined by adjacent cells. Also consider the circumstance where the child element had a sibling that was taller, the child with a height set to 100% should be as tall as its tallest sibling. There are clearly many ways in which a parent’s height can be predetermined without an explicit set ‘height’. The point is though, in my circumstance the parent is clearly taller than its child and using javascript’s offsetHeight property confirms this, so why doesn’t the child, with it’s height set to 100%, respect the height of its parent. If the height of the parent was in-fact determined by the size of it’s children, and it only had a single child, then setting that single child to ‘height: 100%’ would be equivalent to ‘height: auto’ which is probably the point you were making, but in my example, the parent is of greater height than its child, so a height of 100% on the child should stretch to the height of the parent. It’s seems pretty simple.

I’m not sure what conclusion to draw from this though. To me, it seems as simple as “calculate height of parent” -> “use the result as the base for the percentage value of the child”. If the parent’s height is determined by the child, then the calculated height of the parent would be 0. I’m not sure however what the specs say, but maybe in this circumstance they’re being too specific, and thus excluding those instances where the height is not explicitly defined, but where the height is greater than its children. I’m not too sure.

Here’s one the kids can try at home.

<!DOCTYPE html>
<html lang="en">
<body style="height: 400px;">
  <div style="background: gray;">
    <div style="display: inline-block; background: red; height: 200px;">Blah</div>
    <div style="display: inline-block; background: green; height: 100%;">Bing</div>
  <div style="background: gray;">
    <div style="display: table-cell; background: red;">Blah<br/>Blah<br/>Blah<br/>Blah<br/>Blah<br/>Blah</div>
    <div style="display: table-cell;">
      <div style="background: green; height: 100%;">Bing</div>

EDIT: Added some HTML so you can see exactly what I’m talking about. We’re kind of drifting away from the point of this thread however.

I have to agree that the layout module in CSS was never perfect and it would have been better to have solid foundations rather than a lot of the css3 stuff that 90% of people will never use.

If you can’t make 50% + 50% = 100% then don’t bother creating matrix transformations until you can.

It’s the simple things we want.:slight_smile:

Don’t get me wrong I love CSS but there are a number of shortcomings where layout is concerned. There are very few things I can’t do with CSS but they really should be easier and more intuitive.

On the other hand I do like the flexibility of CSS and the fact that you can do something in many different ways depending on the job in hand. If CSS was too rigid we would be thrown back into the table layout mentality and have to work within a defined grid. CSS broke out of that mould but as a consequence lost a few of the capabilities of tables such as equal columns and vertical-alignment. However much more was gained (although at a price of complexity in some cases).

Of course once you start digging into details and the specifics you see that many things are the way they are because they need to be. There are good reasons for many of the property values and once you try to simplify them you lose the ability to do something that was required.

Why didn’t you just use the table-cell itself because that gives the effect you want.

<!DOCTYPE html>
<html lang="en">
<body style="height: 400px;">
<div  style="background: gray;">
    <div style="background: red;display:table-cell">Blah<br/>
        <div style="background:green;display:table-cell">
            Bada Bing

I realise you were demonstrating a point but the resulting effect can be reproduced with the above code so it could be seen as a contrived example. The original code you had could not have been done using tables either so it’s not just a shortcoming of css but a layout concept that never worked anywhere.

Regarding 100% height I’ve always remarked that when they created css the concept of 100% height was slightly flawed in that you simply wanted the element to be 100% the height of its parent (forget siblings as that’s what the table display properties are for).

The stock answer was that for an element to depend on its height via its parents contents would be detrimental to performance in that the height would not be known until the page had rendered. The 100% height for a child could only be resolved when the parents height was known and this would be based on the height of its children - catch 22 almost.

e.g. How tall are You? I am as tall as my parent.
How tall is your parent? The height of the tallest child.

Indeed the height would also need to be recalculated for all elements in that parent should the height be changed via window resizing and would result in a considerable overhead. You would have to monitor all elements and readjust accordingly.

Then there is also the issue of what happens when the content is greater than 100% such as when you base the content on the height of the viewport for example. If you specify 100% do you want 100% and no more or do you want 100% but it can grow (much like IE6s broken implementation of height does already - and often with dire consequences). Perhaps it should be min-height:100% that should be recalculated to match a parents height.

The more you think about it the less easier it becomes.

I often hear developers bemoan the fact that things aren’t working yet the have an element half way down the page and then they have added 100% height to it and just expect it to go from where it is until it reaches the bottom. Clearly a flawed train of thought but an obviously desirable function.

However, I have always argued that CSS already knows some of these things because absolute elements do base their height on their parent quite easily and will keep track as elements grow and shrink and is the basis of my equal column techniques. It’s a shame that static elements can’t behave the same but there is a subtle difference in that the absolute element does not affect its parent height which is what we are asking the static element to do.

It seems to be of the same stable as the parent selector which has been on many peoples wishlist for years but has the same argument that the overheads in implementation would be too severe.

It seems to be of the same stable as the parent selector which has been on many peoples wishlist for years but has the same argument that the overheads in implementation would be too severe.

Likely because of how CSS is parsed: backwards. Imagine if it could parse like Javascript. Parent selectors would be a breeze, I assume.

I got a mod_p0ny, where’s mah parent selector???

See me? I’m sitting at the table with a napkin tied around my neck, banging my fork and knife on the table, demanding WHERE’S MAH PARENT SELECTOR???

The problems with code forking are the extra workload it adds, the greater risk of inconsistency and, depending on how it is achieved, the greater risk of browsers not fulfilling their potential. What I mean by that is that it is rare that browser support for a standard is binary, it isn’t just ‘yes or no’. Many browsers support some features of CSS3, without supporting all features. If you use version control on your CSS, so that only browsers that support CSS4 use the CSS4 sheet (some time around about the 23rd century…), any browser that only has partial support for CSS4 will ignore that stylesheet completely, and so there would be no advantage at all to partial support. And you then have to figure out ways to achieve the layout in each and every version of CSS, which seems like a pretty long-winded way of going about things.

Many browsers support some features of CSS3, without supporting all features.

Heck, all browsers only support some features of CSS2. Bleh.

The latest versions of all the major browsers effectively support all of CSS 2.1 (the small parts that they are missing are so obscure most people don’t even know they exist).

Of course 2.1 is basically 2 with all the bits removed that the browsers weren’t implementing and a lot of those bits have been reintroduced in 3.

@Paul O’B: Glad you chimed in. Interesting reply there. It’s easy to forget that their are complexities in the implementation of CSS that can sometimes shape the specification.

Yes, well said. I mean, we really can do without 3D transformations; no one expects a freak’n OpenGL walkthrough of their webpage. Calculating 100% height of a parent is too expensive, but 3D? No worries. :slight_smile:

Valid points, however, you’re forgetting that it’s up to the browser to decide whether to render the CSS4 stylesheet or not. If it has partial support, but thinks it can handle it, then’s nothing stopping it. It could apply the CSS3 styles for example, then parse the CSS4 style.

As I see it, such a thing may even encourage browser vendors to implement specs more completely, and at once. But, I haven’t thought that idea through thoroughly at all, so it may be completely flawed. It planted the seed for discussion though.

Meanwhile I’ve been getting the feeling everything seems set to return us to 1997 – HTML 5 in particular is like a trip in the wayback machine to HTML 3.2; completely missing the POINT of HTML, the POINT of 4 STRICT, and on the whole throwing the entire past decade of progress in the trash…

Funny thing is, I’m getting this feeling for the exact OPPOSITE reason of what you seem to be saying.

You say that like it’s a bad thing – text is and remains the fastest, most concise and reliable transmission method of information… But then I’m the jackass who whenever someone sends me a video link for an interview or tutorial I immediately respond with “transcript please” – I lack the patience to sit there and watch/listen to drivel like podcasts.

I’m also the type of user who is getting increasingly PISSED OFF with this “web application” bull taking perfectly good working websites and flushing them down the toilet with scripting for nothing, push-pull for nothing, and frankly lacking the utility those same sites had a decade ago… Take webmail for example, which has gotten so bad I’ve given up on it and gone back to using actual e-mail clients; Something I had considered to have gone the way of the dodo SIX YEARS AGO. They still suck, it’s just now they suck less than these fat bloated slow loading broken navigation javascripted train wrecks people vomit up and try to call websites!

HTTP isn’t really… Not sure where you get that unless you’re jonesing for push – HTML of course is EXACTLY set up for that because that’s what it was created FOR… a device neutral capabilities neutral way of delivering CONTENT. Meaningful content.

CSS… Not sure where you get that either; CSS is for device specific appearances – of course with most people having their heads firmly wedged up 1997’s posterior vomiting up presentational markup, throwing CSS at non-semantic markup in a nonsensical manner then sending their code to “all” either by intent or design – maybe there’s justification for your misunderstanding.

Again, you say that like it’s a bad thing. The POINT of HTML and websites is to convey INFORMATION to as many people as possible in as accessible a manner as possible.

Given it seems the majority of new websites are accessibility train wrecks of fat bloated slow crap that’s increasingly painful to use… All thanks to this “web application” {rather nasty expletive about one’s uncle’s relationship to your mother omitted} taking decent web concepts and flushing them harder than a Ferguson.

Which boils down to some art {expletive omitted} wanting to so something not worth the time, effort or “gee ain’t it neat” ******** they seem to think actually makes a difference.

True, but again that’s artsy fartsy nonsense that probably means you’ve got one of the “But I can do it in Photoshop” dumbasses on the line… Good strong whack with a baseball bat between the legs can really help in that department.

So change the design so it doesn’t need it.

Uhm, do you mean a CAPTION? Sorry, that sounds like you don’t know the purpose of all the TABLE tags and/or attributes.

Which is why there’s UDP and you write an APPLICATION, not a website.

Which I think is a lot of the problem, more and more ‘developers’ want to use websites as applications – which has REPEATEDLY been slow, buggy, unreliable, and total utter garbage – but they keep trying over and over… Bite the bullet, you want to make a Internet aware application, write a bloody application using a REAL language – instead of some stupid scripted trainwreck.

Sounds more like you were trying to use the wrong tool for the wrong job. Care to elaborate more on what you were working on?

Though admittedly, one person’s idea of simple and anothers can vary wildly – but your post sounds an awful lot like you tried to put a square peg into that round hole… and then was suprised when it didn’t fit.

You know, the more I think on it, the problem isn’t the technologies… it’s developers trying to use them for things they shouldn’t.

If anything, I think modern web developers are working against modern web developers. Take one look at how Google wants to be the next “Ask Jeeves” for proof of that.