Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Web-apps are the legacy apps of the future.

By rodentboy in Op-Ed
Mon Oct 25, 2004 at 04:58:19 AM EST
Tags: Internet (all tags)
Internet

Back in the days of stone knives and bearskins applications were things that were written in cretinous languages like COBOL that ran on wierd 71 bit architectures and used messed up file formats like JCL and VSAM files or whatever. What's a 'Data Division'? Some whiny 80s band from Manchester?

Of course today we are so much smarter. If you look at the evolution, from ML, to branched languages to structured programming to OOP, and from 3270 applications, to PC apps to client server to web apps, you can clearly see how the applications programmer transformed himself from knuckle dragging simian to homo sapiens. That's the stereotype, right?

We have a name for all that old stuff, a pejorative name: 'legacy'.[1] I'm here to tell you that the web application is the new legacy.


Just look at all the languages, formats and protocols that are used in your typical web app.

HTTP

HTTP was designed to be a stateless protocol. How many applications are stateless? In fact a good definition for an application might be 'an interactive tool for manipulating state data'. So far it sounds like a good fit.

Of course there are cookies that can help you track the state of the application, but the user can refuse them. That's nice. Your users can refuse to use your application's state mechanism.

The statelessness has another benefit. Now every event your user produces in the application requires you to submit something to the server and to fetch another 'document' as a response.

And since every response is a document referred by the preceding document now your users can use the back button 7 times and place the application in an inconsistent state, isn't that nice?

HTML

First of all the syntax is ugly. Couldn't they use balanced delimiters instead of these ugly brocket surrounded tags? Every tag is optional and can be nested any which way, even like this [ { ] }.

There is no separation of content and formatting. You can't make macros to abstact the formatting out. I can't think of any markup language that doesn't include some kind of macros except HTML.

HTML was clearly designed to present documents made up of mostly text with a few figures or tables. Instead the typical website turns this design inside out and consists of documents made up mostly of tables and graphics with a few paragraphs of 'content' thrown in there.

So to solve these problems you have CSS and XML/XSLT that are kind of neat except that XML preserves the ugly SGML syntax and that they add complexity to something that could have been done right in the first place.

Forms

Strictly speaking forms are a part of HTML, but since they seem like a bolted on afterthought they deserve to be treated separately.

Form tags allow you to place input controls in a web page. This feature along with cookies are the only things that make web applications even possible. Since they are so crucial, it's nice that a lot of thought has gone into them.

Like validation. Wouldn't it be nice to at least be able to say this text field should only accept integers or accept entries matching a certain pattern? That wouldn't allow for cross validation but it would be a start.

To validate these things you have to either put a garlic strand around your neck and use Javascript or waste bandwidth making round trips to the server to keep asking for new documents. Making round trips to the server makes it hard to preserve values that were entered in the form fields from one docuument to the next. Whole edifices of server side code, called frameworks, have been written to solve this problem.

Controls that need to be preloaded like drop downs need to get this data from the server. That's ok until one dropdown affects what appears in another dropdown. In that case you either make a trip to the server or use Javascript. If you use Javascript to avoid making trips to the server your script needs to have the data for all the possible choices.

Live Script

Opps, sorry Javascript. A quickly written Java like toy langauge that allows you to manipulate the DOM (fancy word for parse tree) of the HTML from within the browser. Remember how in the HTML section we said that presentation is not typically separated from content and that tags can appear anywhere? How do you think that makes the DOM tree look?

To be fair Javascript allows you to drill down to the elements you are interested in pretty easily but it's mere existence rankles. It won't run the same on all browsers, and while that is not Javascript's fault, that means you can't always rely on the fancier features.

Even worse, like cookies the user may even have it turned off so unless you can dictate to your users you can't rely on it at all.

The Server Side

You can use any language on this end that you want. In the old days C and script was used a lot which could be pretty dangerous considering your API was exposed to the whole world. Now Java/J2EE is popular and so is C#/.NET, perl or php.

Most of these languages allow themselves to be embedded right into the HTML [2] [3] document, so now we have no clear separation of content, presentation or behaviour!

Because of statelessness and the way forms work, the server side has to consist of a set of discrete endpoints that receive form data from the browser and that have to return a document in response. The users state has to be looked up for each action the user takes and then a decision has to be made which 'document' the user has to see next as a result of that action.

You can't even use the function call metaphor.

So we end up, in addition to writing the application itself, having to write a big state machine to maintain the consistency of the user interface presented to the user in the browser.

Conclusion

Web applications are a patchwork of 42 different languages, data formats and crufty post hoc solutions to non-problems improperly applied. Ergo web applications are the legacy apps of the future!

A lot of work has been done to make web applications easier to write and maintain. So why did I leave that out? Why didn't I mention framework X or methodology Y? The necessity of these complex 'solutions' only serves to show how unsuited a browser with forms is as an application environment in the first place.

 

 

 

[1] It's not legacy just because it's old. There is plenty of cool old stuff like Lisp, or UNIX.

[2] To be fair, when this is done right it consists merely of placeholders for dynamic data in the HTML.

[3] The opposite, where HTML embedded in the code is even worse.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o [1]
o [2]
o [3]
o Also by rodentboy


Display: Sort:
Web-apps are the legacy apps of the future. | 102 comments (69 topical, 33 editorial, 0 hidden)
HTML WILL SOME DAY BE OBSOLETE (1.80 / 10) (#1)
by sllort on Fri Oct 22, 2004 at 04:50:02 PM EST

FILM AT 11
--
Warning: On Lawn is a documented liar.
and what value are these observations? (2.63 / 11) (#3)
by circletimessquare on Fri Oct 22, 2004 at 05:00:57 PM EST

some day the internal combustion engine will be obsolete

or silicon-based semiconductor chips

or MTV

there was once a time when innovations like these were very cool because they improved upon what came before

but, they have their problems and limitations

much like html, et al

but you fail to see how html was a vast improvement over what existed before

and how whatever will replace html will have its own set of problems someone like you in 30 years will complain about unhelpfully


The tigers of wrath are wiser than the horses of instruction.

Some day, hopefully, (none / 1) (#4)
by trane on Fri Oct 22, 2004 at 05:03:13 PM EST

humans will be obsolete.

[ Parent ]
fuck you (1.83 / 6) (#18)
by circletimessquare on Fri Oct 22, 2004 at 08:01:48 PM EST

if you really believe that, then go kill yourself

you will save the rest of us from that sort of bullshit doom and gloom

The tigers of wrath are wiser than the horses of instruction.

[ Parent ]

Nono you misunderstand (2.20 / 5) (#21)
by trane on Fri Oct 22, 2004 at 10:12:16 PM EST

It will be a good thing! We will create our successors, our robot overlords that will obsolete us. That's what I'm going to do instead of killing myself...

[ Parent ]
Vast improvement how? (none / 0) (#5)
by rodentboy on Fri Oct 22, 2004 at 05:14:45 PM EST

HTML et al isn't even a vast improvement over COBOL and 3270s

We don't seem to be learning. Why make up a so called markup language in the 1990's without macros?

The internal combustion engine will stubbornly refuse to become obsolete for a long time and for good technical reasons (high power density, low cost , low weight etc.) The web application technology was obsolete the day it was crufted together even by the standards of 1960.



[ Parent ]
it's you word (2.33 / 3) (#6)
by circletimessquare on Fri Oct 22, 2004 at 05:24:11 PM EST

versus history

didja miss the whole internet explosion thing in the early 1990s?

i suppose the fact that html is easy to use by nonprogrammer's doesn't figure in your holier-than-thou world

you have to learn that in technology, what is popular is what is right


The tigers of wrath are wiser than the horses of instruction.

[ Parent ]

I said web apps not HTML (none / 0) (#7)
by rodentboy on Fri Oct 22, 2004 at 05:36:39 PM EST

Html is eaier to use by non programmers, but Html based apps are harder to use by everyone especially non-programmers.

If most of the internet protocols were designed like this from the beginning, there wouldn't be an internet cos it would have collapsed under it's own weight years ago.

I like your might makes right argument too, if history bla bla. By that argument Microsoft software is the epitome of goodness and all things happy with little birds singing in the trees and soft tame bunnies nibbling at the grass that you can pet.



[ Parent ]
sour grapes (nt) (2.00 / 2) (#8)
by circletimessquare on Fri Oct 22, 2004 at 05:44:22 PM EST



The tigers of wrath are wiser than the horses of instruction.

[ Parent ]
HTTP (2.83 / 6) (#9)
by theNote on Fri Oct 22, 2004 at 05:45:06 PM EST

HTTP is an amazing protocol.
Among other things, it has built in well defined error codes that come in handy when writing communication layers.
It also spoken by every major platform out there.

Yes, HTTP is stateless.
No, not every application needs state.

However, not every application that uses HTTP is transmitting HTML. HTTP is not just for your browser and websites, it is a very useful and flexible middle ground in protocols.
Its just heavy enough so you don't have to code at the tcp/ip layer, but light enough that you don't have a lot of cruft.
Hence the easy addition of cookies to web applications. The openness of HTTP headers is a very nice thing.

Regardless of what you think will replace HTML, Javascript, Forms, etc, I'd be willing to bet its going to be delivered over HTTP.

And furthermore... (none / 1) (#11)
by skyknight on Fri Oct 22, 2004 at 06:23:34 PM EST

it's really not all that hard to bolt statefulness on top of HTTP.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
What you say is good and all... (none / 1) (#28)
by curien on Sat Oct 23, 2004 at 10:45:42 AM EST

but here's the real reason the future of the Internet rests over HTTP.

Firewalls, proxy servers, and NAT oh my!

I cringe when I think of the problems we'll see in 5-10 years (or sooner) due to the over-multiplexing of HTTP services. sigh

--
This sig is umop apisdn.
[ Parent ]

Exactly (2.80 / 5) (#14)
by godix on Fri Oct 22, 2004 at 06:56:11 PM EST

HTML was clearly designed to present documents made up of mostly text with a few figures or tables.

This statement is correct. It's not the fault of HTML that people are trying to use it for something it wasn't designed for. Your complaining makes about as much sense as bitching that your car makes a crappy cup of coffee.


- An egotist is someone who thinks they're almost as good as I am.
But (none / 0) (#15)
by rodentboy on Fri Oct 22, 2004 at 07:01:52 PM EST

Wouldn't it make you sad if a whole herd of people forced you to use your car to make coffee. And that you had to drink that horrible car generated non-coffee every day?

Used to be an intelligent person could work in IT without going insane.



[ Parent ]
Not really (3.00 / 3) (#16)
by godix on Fri Oct 22, 2004 at 07:15:23 PM EST

Wouldn't it make you sad if a whole herd of people forced you to use your car to make coffee.

Nope it wouldn't. Because they can't force me, I can always learn how to use a coffe maker myself, use my car to drive to work, and just ignore anyone who suggests I switch those.

To put it in web terms, I have yet to see a site that screwed up HTML enough for me to jump through hoops to view it that was actually worth jumping through hoops to view. I learned that lesson a few years ago when I neglected to install flash and realized the lack actually made the web more enjoyable and I got less ads. When people break HTML standards it's for THEIR gain not the users.


- An egotist is someone who thinks they're almost as good as I am.
[ Parent ]

Abstraction and language (2.88 / 9) (#22)
by Blarney on Sat Oct 23, 2004 at 12:07:18 AM EST

The current WWW system is sort of broken, but if we take a broader view I think a reasonable solution could be found.

We've all seen help-wanted ads for Web programmers and these days they seem to require some sort of superman/woman, don't they? If PC programming ads looked like that they'd be like:

Experienced PC developer needed immediately. Must be experienced with VGA, SVGA, VLB, PCI, AGP 2X/4X/8X video interfaces. Memory programming utilizing page tables and segments. Familiar with SCSI, Ultra DMA, and USB hard disk storage systems, using caching/virtual memory allocation and filesystems. RAID experience a plus! Input/Output programming using AT/PS2 and USB keyboards and mice necessary. Artistic skills also desired, applicants must provide portfolio of screenshots as well.

Sounds pretty stupid, but that's actually the level most web designers actually work on. If I program with the Window API it doesn't matter to me whether the data files are on a VFAT, FAT32, network share, or NTFS volume - yet web programmers must know the difference between MySQL and Oracle databases. In Win32 or even GTK it does not matter to the ordinary application programmer whether the user has an NVidia FX card or an antique Riva 128 or Voodoo Banshee - yet web programmers must write their HTML and JavaScript to perform sniffing and workarounds for MSIE of various ages, Mozilla, Safari, maybe even stupid old Netscape 4! A new synthesis is required.

The fault is not with the low-level interfaces but with the way they're tied together. It might be really ugly to twiddle the registers in my video card so as to display a pixel - but that is a problem for the OS, the drivers, the BIOS, not for the application programer. These POKEs and PEEKs could be ugly, but they're FINE! Similarly, I can't get too worked up about HTML being crufty or JavaScript being flakey..... it's just nothing that the web programmer should honestly be worrying about, ever, at all.

What we need is a language that compiles to everything the web programmer needs. This language should compile down to server-side scripts in languages such as PHP or Perl, with data access calls to local or remote MySQL, Oracle, or filesystem generated, and these scripts in turn should emit HTML files with all necessary Javascript incorporating all necessary cross-browser sniffers and hacks to display properly on supported viewing platforms. None of this should be the programmer's problem!

A programmer should be able to specify the layout and graphical resources of various forms, to specify constraints upon input values in algebraic or function-call style, to write some basic error handlers, and have all the dirty work done for him. Need form values checked? Use the same constraints to generate server-side validation and client-side JavaScript whenever possible.... no need for human duplication of effort. Let cookies and POSTdata be used for flow between forms, but let the COMPILER decide the optimal way for this to be done - or, if not an optimal way, at least a ROBUST way.

Should new server-side languages/databases be made available, or new client viewers, the compiler would merely need to be improved to use them as targets - not the WEBSITE itself, which would now be truly a portable program.

I mean, VGA displays are ugly to program. But nobody CARES... we don't really have them around, but things are back-compatible anyhow, and it's not an issue, nobody discusses them or thinks about them... the world of PC application programming has progressed. The same thing will happen on the Web, it's a shame that it didn't happen DURING the bubble but someday it will.

Abstraction (3.00 / 4) (#33)
by cdguru on Sat Oct 23, 2004 at 01:21:05 PM EST

HTML was designed - intentionally - to separate the form of presentation from the tagged organization. The presumption was that it could be left up to the browser and/or user to determine the "style" and form of the presentation. The mission of HTML was to just identify the parts of the text so they could be presented.

I think that worked in the real world for about 15 minutes and then some PR or marketing guy came by and said "but all the headings should be in the Corporate Standard Font." And thus was born the idea of specifying the font, spacing, layout and everything else in HTML.

Could we go back and have two separate things - a presentation definition and a content definition? Maybe. But HTML still tries to isolate the presentation from the content. If we are going to have the presentation be bound to the content, fine, let's have a specification that does that. Otherwise, let's get away from trying to do it with something was designed to avoid it.

[ Parent ]

Cascading Style Sheets [nt] (none / 1) (#48)
by SoupIsGoodFood on Sat Oct 23, 2004 at 08:10:49 PM EST



[ Parent ]
Complexity (none / 0) (#63)
by immy on Mon Oct 25, 2004 at 08:39:56 AM EST

This comment regarding the complexity of web development and the number of skills web developers must utilize on a day-to-day basis is spot on.

Some posters have been arguing that the reason why the web became so "huge" so quickly is because HTML is so easy to learn.

The problem is that the average noob may find HTML easy to pick up and write some crappy web pages in, but to develop a good looking web page with even a small amount of interactive functionality, other technologies have to be learnt: Javascript, CSS, server side scripting languages, basic SQL, hacks for cross browser compatibility etc etc etc.

The web should be moving on from HTML and the kludges associated with it to a cleaner development model ASAP.



[ Parent ]
defending HTML (2.90 / 10) (#24)
by Kasreyn on Sat Oct 23, 2004 at 05:56:11 AM EST

First of all the syntax is ugly. Couldn't they use balanced delimiters instead of these ugly brocket surrounded tags? Every tag is optional and can be nested any which way, even like this [ { ] }.

Sadly, they wimped out and designed HTML so that everyone could use it, rather than using delimited balancers or bouncing delinquents or delicious ballast or whatever the hell anal retentive thing it is you're going on about. Sick, isn't it, wanting a format to be widely usable over technically perfect? Someone should write them a delimited and balanced email.

If they'd done html your way, you wouldn't be here to gloat about it, since the world wide web would never have caught on. I learned how to write web pages from a book with "For Dummies" in the title. Somehow I doubt that would have been possible with a web format using limeyfied DeLancies. And so, today, 95+% of web pages are successfully (well, at least successfully in terms of actually rendering) written by people who believe computers run on Magic Gnomes. Best of all: It Works!, unlike many other standards that have been proposed.

Cheers!


-Kasreyn


"Extenuating circumstance to be mentioned on Judgement Day:
We never asked to be born in the first place."

R.I.P. Kurt. You will be missed.
Ha ha (3.00 / 4) (#34)
by rodentboy on Sat Oct 23, 2004 at 01:42:11 PM EST

It's kind of funny. Most people complain that I didn't make any suggestions on how things could be improved, and I didn't on purpose.

The one one point where I did make a concrete suggestion (balanced delimiters in HTML) attracted a few responses like yours along the lines of "you are an elitist, HTML was designed that way to be usable by oridnary people, vox populi bla bla".

I'm not implying that any alternative HTML would have had to be harder to learn. You are basically saying that ordinary people couldn't deal with it if it's syntax was something equivalent to:

body { table { } }

Even further you are saying that you wouldn't have been able to figure it out if it had been like that. I have to ask you sir, do you keep all your files in one directory to avoid the complexity of nested directories?

Maybe the permissive everything can appear anywhere nature of HTML is a feature (but I doubt it since we now have XHTML and XML that insist on well-formedness) but I never said that everyone should have had to mark up their pages in pure Postscript and like it.

And besides, it's kind of hard to think of a less demotic format than HTMLs ancestor SGML. Not a good place to start if ease of use is your goal.



[ Parent ]
Actually, my files are very organized (3.00 / 3) (#52)
by Kasreyn on Sat Oct 23, 2004 at 10:09:11 PM EST

But the average net user does, indeed, keep all his files in one directory. For ease of thought, it's even got a cutesy name like "My Files" or "My Music". Typically, programmers and the computer-proficient have a hard time grasping just how totally clueless the average computer user is. My mocking of balanced delimiters was an attempt to point out their likely incomprehension.

Frankly, html as it currently stands is *too complex* for many. As in, if I had been involved in its design, I would have constantly been asking the question, "is there any way we can make this easier to learn without sacrificing functionality?"

I'm not sure if there *were* such ways, mind you. And yes, they could have started with something better than SGML.


-Kasreyn


"Extenuating circumstance to be mentioned on Judgement Day:
We never asked to be born in the first place."

R.I.P. Kurt. You will be missed.
[ Parent ]
Defending Complexity (none / 0) (#65)
by Houston T on Mon Oct 25, 2004 at 10:32:09 AM EST

HTML does not have to be simple for a wide audience to be able to create HTML documents. Tools like FrontPage would simply be the preferred way of generating them, just as tools like Acrobat are the preferred way of creating a PDF.

Although PostScript is more than simply a markup language, my understanding is that it, too, used to be widely hand-coded. I suppose one reason many continue to hand-code HTML is that the structural overhead of computer-generated code continues to have a high cost for many Internet users.

[ Parent ]

legacy (none / 0) (#26)
by forgotten on Sat Oct 23, 2004 at 08:57:41 AM EST

legacy doesnt mean bad.

--

No (none / 1) (#29)
by curien on Sat Oct 23, 2004 at 10:47:40 AM EST

What it usually means is, "Too complex to update to modern mechanisms." This has negative connotations. Occasionally it means, "Done so fucking well the first time, we don't want to update it to modern mechanisms."

--
This sig is umop apisdn.
[ Parent ]
"too complex to update" (none / 0) (#51)
by forgotten on Sat Oct 23, 2004 at 09:00:16 PM EST

i dont think it has negative connotations for the application. i dont think it would have been reasonable to expect designers of, say, yesterdays mini-computer programs to anticipate porting of their software to desktop pcs.

it may however have negative connotations for the IT budget.

--

[ Parent ]

Factual inaccuracies, anyone? (2.71 / 7) (#43)
by ubernostrum on Sat Oct 23, 2004 at 07:04:13 PM EST

Every tag is optional and can be nested any which way

No, some tags are most definitely not optional. For example, a minimal valid HTML 4.01 document would consist of a DOCTYPE declaration and opening and closing head tags. The root html element and the body element are optional in HTML, but any body content would need to be inside an appropriate containing element.

And while there are browsers which regrettably will allow tags to be nested any which way, HTML does not. The HTML DTD defines a hierarchy of block and inline elements, with rules for which elements may contain which others. HTML also requires that a contained element be closed before its containing element is closed, although it is possible for some elements to have an implied closing tag.

There is no separation of content and formatting. You can't make macros to abstact the formatting out. I can't think of any markup language that doesn't include some kind of macros except HTML.

I'd like you to meet a specification called Cascading Style Sheets. You mention CSS but I think you need to be reintroduced, since most or all of the "formatting" you complain about is deprecated in favor of CSS. And as for "markup languages without macros", I don't know what background you come from but I sure as hell use a lot of SGML-based languages that don't have macros.

And really, beyond this your article turns into a bitter rant based on the assumptions above and an irrational hatred of JavaScript. I'd continue debunking but I'd be here all day; suffice it to say that a) JavaScript does a hell of a lot more than manipulate the DOM, b) your comments on the DOM tree need to be informed by my point above abotu tag placement and nesting, c) the form features you want are being worked on by the WHAT-WG, a group I recommend you read up on.

And, finally, this stuff, as you so artfully recognized (and derided) wasn't really designed to be an application framework in the first place, so really you're someone who's got an apple and is complaining about all the ways it isn't an orange. What you want is the Web Services crowd, which is a whole different world.




--
You cooin' with my bird?
But you do get it I can tell (none / 1) (#49)
by rodentboy on Sat Oct 23, 2004 at 08:51:16 PM EST

And while there are browsers which regrettably will allow tags to be nested any which way

So you do get it.

a minimal valid HTML 4.01 document would consist of a DOCTYPE declaration and opening and closing head tags.

Don't make me fucken laugh. Maybe 1% of the documents on the web have the DOCTYPE declaration. How relevant is the standard if it is universally ignored.



[ Parent ]
Huh. (3.00 / 2) (#54)
by ubernostrum on Sun Oct 24, 2004 at 02:20:28 AM EST

How relevant is the standard if it is universally ignored.

How relevant would any proposed replacement be, then?




--
You cooin' with my bird?
[ Parent ]
Enforcement (none / 0) (#70)
by rodentboy on Mon Oct 25, 2004 at 01:10:23 PM EST

The standards bodies come up with more and more ways to fix the problems, but the browser makers are forced to continue ignoring the fixes in case some badly marked up pages might not work.

In particular, think of Mozilla. If they refused to put in kludges, some pages that render in IE would look broken in Mozilla and then Mozilla is seen as broken.

So basically we will always be trapped with some kludges because of the permisiveness of early browsers. In that way this stuff is legacy because any mapping that you could make between the old stuff and the new would have to map the quirks as well.



[ Parent ]
Doesn't matter (none / 0) (#72)
by GhostfacedFiddlah on Mon Oct 25, 2004 at 01:27:16 PM EST

There are very few differences between browsers that will break a webapp if ignored.  Usually just a table cell being slightly larger/smaller than usual.  At the worst, something might be placed below when it should be placed beside, but the second someone complains, the problem can be fixed.  I've been developing for three years, and never had a problem that was worse than a simple sizing issue.  

Even javascript has a "baseline" of commands that work on every browser since NS4.0.  I seldom have to leave this baseline, and if I do, I make sure to notify the user.

Beyond that, it's up to the developer to make sure they're following standards.  There are plenty of html validators out there.  As for your "kludge" argument, you might want to look up Mozilla's quirks mode.

[ Parent ]

Optional tags (none / 0) (#64)
by dorward on Mon Oct 25, 2004 at 10:14:48 AM EST

No, some tags are most definitely not optional. For example, a minimal valid HTML 4.01 document would consist of a DOCTYPE declaration and opening and closing head tags.

Actually, the head tags are optional. A minimal document is a DOCTYPE declaration, a title and some content. (And I might be wrong about the content part, I can't be bothered to check).

[ Parent ]

apples and oranges (none / 0) (#74)
by m50d on Mon Oct 25, 2004 at 02:25:46 PM EST

And, finally, this stuff, as you so artfully recognized (and derided) wasn't really designed to be an application framework in the first place, so really you're someone who's got an apple and is complaining about all the ways it isn't an orange. What you want is the Web Services crowd, which is a whole different world. You're right about the balanced tags, but the above is missing his point. He's not complaining about html, he's complaining about web applications. And the fact that they are trying to use the wrong tool for the job is one of the major problems with them.

[ Parent ]
Legacy apps? (2.33 / 3) (#45)
by SoupIsGoodFood on Sat Oct 23, 2004 at 07:36:52 PM EST

You ramble of for a while about the annoying quirks of web apps and the stateless internet (where you make many flaws). But you never get to the part about how they are the legacy apps of the future.

This artical is so bad I have to take it as a troll. So I won't bother ripping it to shreads in detail.

My thoughts exactly. (nt) (none / 0) (#57)
by For Whom The Bells Troll on Sun Oct 24, 2004 at 10:50:50 AM EST



---
The Big F Word.
[ Parent ]
I actually agreed with the fundamental point... (none / 0) (#68)
by Pxtl on Mon Oct 25, 2004 at 12:45:08 PM EST

That it will be a legacy app. Microsoft saw this already when they made .NET, and Sun saw it long ago when they made Java. The fact is that a web browser is a stupid, ineffective way to make an application. The problem is that attempts to replace it have crashed and burned hard (Java). Still, I think that with time you'll see more and more internetapps served with full client-server programs rather than web+http. I mean look at the Fark/Slashdot/etc. weblog discussion sites - how many idiots are hitting F5 over and over again, with servers screaming in agony resending the same full pages instead of just the changes when needed? This is seriously sub-optimal. The web will always be there - its too firmly entrenched to leave. But for heavyweight web-apps (like BBs, webmails, etc), it is bound to be replaced with better approaches. At that point, people will look at the clumsy, slow approach of embedding a program into a website with messy languages and a billion competing systems and wonder what the hell to do with all this old crap.

[ Parent ]
Slow adaption to new technologies != legacy apps (1.50 / 2) (#88)
by SoupIsGoodFood on Tue Oct 26, 2004 at 05:15:31 AM EST

When I think of legacy apps, I think of something that is old and complex, or undocumented. So complex or undocumented that it's easier to keep it running than it is to replace it.

The majority of web apps are very simple, and most of the technologies they use are open and well documented, and therefore very easy to convert to whatever the latest technology is.

The problem that you seem to be talking about is gaining support for better technologies. But this is a different subject to legacy apps.

[ Parent ]

+1FP, but... (3.00 / 2) (#53)
by waxmop on Sat Oct 23, 2004 at 10:41:39 PM EST

Everything after the HTTP section is either just stupid or such an old complaint you might as well bring up how Betamax was better than VHS.

So I'm voting this up anyway because I think the kludgy ways people track states is just shameful.
--
Limberger is the angeldust of cheese.

A good thing, maybe (none / 0) (#56)
by Nyarlathotep on Sun Oct 24, 2004 at 08:36:45 AM EST

This is probably a good thing.  We have a major problem that applications (Micrsoft Word) has grown to an enormous size to give the few power users the features which should be add-ons (via an AppleScript like langauge).  The comming crufty web apps will split off the main stream users of applications like word, and give them a poor minimal program which no respectable person wants to use.  Well this is probably bad for main stream, as they will have "no place to go" without changing programs.  *But*, by driving a wedge between the power users and the masses, it *could* be marvilous for smaller less featureful, and ideally more scriptable, programs.

This future is by no means assured.  Victory will probably be determined by having both a web product and a rich desktop product which are simillar.  Say perhaps by using the same Java <puke> code base.  Microsoft does not like Java, and has its own equally bad alternatives.

Anyway, you should not be too worried about it.  Private consumer software products are always big piles of junk in one way or another.  You make a good product by starting over and designing it to do something specific, and allowing scriptability to extend it.  A consumer's computer needs to do too many things, and the consumer does not understand scripting.

I guess I'm expousing the theory that, in any society, the quality of the software is controlled by the portion of the population which has a basic understanding of the principles of programming.  So the real question is not whether a specific application framework sucks, but what effect it will have on people learning the basics of programming.
Campus Crusade for Cthulhu -- it found me!

Legacy applications? (3.00 / 4) (#58)
by Scrymarch on Sun Oct 24, 2004 at 11:04:00 AM EST

Walter: uh--and also, Dude, Legacy is not the preferred nomenclature.  Heritage applications.  Please.
Dude: Walter, this isn't an app who built the fuckin' newsgroups, here, this is an app that peed on --

Ahem.

Please do try to remember that is the most senior application citizens who will be the most conscientious voters come software sentience.

3 points for Big Lebowski reference [nt] (none / 0) (#84)
by wji on Mon Oct 25, 2004 at 10:09:30 PM EST



In conclusion, the Powerpuff Girls are a reactionary, pseudo-feminist enterprise.
[ Parent ]
And now a word (none / 1) (#62)
by johnny on Sun Oct 24, 2004 at 11:54:44 PM EST

from my sponsor.

yr frn,
jrs
Get your free download of prizewinning novels Acts of the Apostles and Che
not so fast (none / 0) (#67)
by Cazzi Salati on Mon Oct 25, 2004 at 12:10:58 PM EST

Web apps are the easiest and most effective platform for companies to build distributed computing applications, whether internally or as an extranet for clients. It's cheap and relatively simple when done correctly, especially in terms of developing the UI and front-end components. There are huge problems with doing it wrong. But it can be done right, and it works beautifully when it is. cazzi salati

-- My cat's breath smells like cat food - ralph wiggum

Success is its own argument (3.00 / 2) (#71)
by hansel on Mon Oct 25, 2004 at 01:14:08 PM EST

All the legacy apps we deal with today were <i>successful</i>, while their more elegant, more correct competitors died ignoble, silent, wasting deaths.

If what you're arguing is that the ugliness you list above is symptomatic of a successful platform that survives long enough to become a legacy app, then I agree with you.

and how (none / 1) (#73)
by jcs on Mon Oct 25, 2004 at 02:24:42 PM EST

Of course there are cookies that can help you track the state of the application, but the user can refuse them. That's nice. Your users can refuse to use your application's state mechanism.

and i can refuse to install a library for an application and it won't work. what's your point?

And since every response is a document referred by the preceding document now your users can use the back button 7 times and place the application in an inconsistent state, isn't that nice?

learn how to write proper applications, then. do you blindly accept all input from a user and assume that it has passed client-side validation?

Every tag is optional and can be nested any which way, even like this [ { ] }.

tags cannot be nested that way. some web browsers might render it, but that doesn't mean it's correct.

Like validation. Wouldn't it be nice to at least be able to say this text field should only accept integers or accept entries matching a certain pattern? That wouldn't allow for cross validation but it would be a start.

yes, it would. xforms

Oh I never noticed (none / 0) (#75)
by rodentboy on Mon Oct 25, 2004 at 03:01:36 PM EST

xforms is cool (XUL too) but are you saying that most current web applications are actually written using XForms and that I didn't notice?



[ Parent ]
no (none / 0) (#76)
by jcs on Mon Oct 25, 2004 at 03:11:37 PM EST

but xforms is a solution to the problem you mentioned. your article contained no solutions or suggestions, just bitching.

[ Parent ]
rodentboy ... (none / 0) (#77)
by levsen on Mon Oct 25, 2004 at 04:56:44 PM EST

you are a genius. someone needed to mention that. plain obvious to pretty much half of the world but no one mentioned it yet, ever.

This comment is printed on 100% recycled electrons.
Going down the list... (3.00 / 2) (#79)
by ttfkam on Mon Oct 25, 2004 at 05:29:21 PM EST

HTTP: an incredibly simple and concise protocol.  It tells you what you are connecting to, is in plain text for easy debugging, and provides an API for getting and setting data.  Oh yeah, and EVERYONE KNOWS IT from browsers to servers to firewalls to command-line clients to the general programming community.

HTML: Combined with HTTP was SOOOOO much better than gopher, archie, et al.  Definitely a step up.  And since most other people have recognized the same problems that the article's author has, you see such refinements as XHTML (addressing the mixed up tag issue).  Since XSLT is 99.9% used as a server-side technology, I'll address it later.  As for CSS, I was under the impression that separating the content from the presentation was a good thing.  I guess there's no pleasing some people.  Bottom line here is that browsers that everyone used ten years ago are not at all the same animal we use today any more than the original steam locomotive is the same thing as a prototype maglev train.  And since browsers that support modern CSS techniques now account for more than 95% of all browsers, I guess society is dealing with the "legacy" issue in stride.

Moving on...

Forms: Could be better, but still do a lot.  Just because they're not a 100% solution doesn't mean that they shouldn't be given due credit for being an 80% solution.  As for validation, use JavaScript.  Don't like JavaScript?  Don't use it.  But don't denegrate the technology presented to solve a solution, refuse to use that technology, and then whine about how there are no solutions.

Server side: And here is where your argument *completely* falls apart.  What other technology allows you to upgrade all your users at once?  Anyone out there use Yahoo Mail?  Remember when they have updated the UI?  Remember when they added WYSIWYG email composition and readily accessible addressbooks/contacts?

Do you remember what technology they used on the backend before the first major overhaul?  How about after the second?  What are they using now?  Not sure?  Had to look it up?  Point made, and that's the power of web applications today.

As far as dumb coders who write spaghetti PHP -- mixing content, presentation, logic, and data all together -- no matter how good or bad the technology, there will always be idiots using a tool foolishly.  I don't care how good your mythic perfect technology is, someone will skim the lastest edition "Learn Mythic Perfect Technology in 24 Hours" and mess it up.

Are you completely and utterly blind to the fact that while Google produces no operating systems, no UI libraries, no explicit Mac OS X support, etc., they were still able to deliver a search utility, a mail client, a language translator, an ad service, a shop, and a news aggregator to 99.9% of the people connected to the internet?  And they were able to provide these things with your much maligned HTTP, HTML, forms, JavaScript, and server-side programming.  If Google alone doesn't clearly demonstrate to you and all other readers how full of crap you are, maybe any of the other thousands of companies, organizations and individuals on the web today (not to mention the millions who equate "internet" with "web") might.
If I'm made in God's image then God needs to lay off the corn chips and onion dip. Get some exercise, God! - Tatarigami

Google's front page (1.00 / 2) (#80)
by rodentboy on Mon Oct 25, 2004 at 06:22:28 PM EST

Has one form field on it. Not much of an example of what I'm talking about is it?



[ Parent ]
Gmail (none / 1) (#83)
by ttfkam on Mon Oct 25, 2004 at 09:51:08 PM EST

Get a Gmail account smart ass.  Plenty of form fields and an enormous amount of dynamism.

Hell, my Yahoo Mail example sufficiently proves my point.  The Gmail example just makes your position laughable.

If I'm made in God's image then God needs to lay off the corn chips and onion dip. Get some exercise, God! - Tatarigami
[ Parent ]

Webmail apps are maybe the worst class of webapp (none / 0) (#85)
by pnadeau on Mon Oct 25, 2004 at 10:43:51 PM EST

Google is probably the ultimate webapp. A single entry field, simple result format. I'm restricting myself just to form here. On function Google is even more amazing. Things like Webmail are horrendous OTOH and nobody, even an HTTP fanboy could argue they equal a real email client.

The only reason we put up with the crappy interfaces of stuff like webmail is because, as you pointed out, of the distribution aspect. They are available anywhere and don't require an install. Does this make their underside any less ugly?


"Can't buy what I want because it's free, can't be what they want because I'm..."  Eddie Vedder


[ Parent ]
And the better option is...? [n/t] (none / 0) (#101)
by ttfkam on Thu Oct 28, 2004 at 07:59:59 PM EST


If I'm made in God's image then God needs to lay off the corn chips and onion dip. Get some exercise, God! - Tatarigami
[ Parent ]
Gmail again (none / 0) (#102)
by ttfkam on Thu Oct 28, 2004 at 08:03:08 PM EST

If you don't have a Gmail account, get one.  Then explain how it is deficient as compared to a native email client.  Until then, comments like "webmail apps are the worst" are completely useless.
If I'm made in God's image then God needs to lay off the corn chips and onion dip. Get some exercise, God! - Tatarigami
[ Parent ]
Heh (none / 0) (#93)
by riceowlguy on Tue Oct 26, 2004 at 01:52:48 PM EST

Forms: Could be better, but still do a lot.  Just because they're not a 100% solution doesn't mean that they shouldn't be given due credit for being an 80% solution.

Funny how this sounds exactly like the things I used to read about the "Unix Philosophy" and how 90% of the problem can be solved with 10% of the work, and that this was okay.

Go read The Rise of Worse is Better for the sad truth about why (initially | continually) terrible systems like C, Unix, Windows, and now HTTP/HTML/$WEB_WIDGET always succeed over things that are technically superior.

HTML is UNIX for the 21st century.

"That meant spending the night in the living room with Frank watching over me like some kind of Lovecraftian soul-stealing nightmare creature-Azag-Frank[ Parent ]

Inferior to what? (none / 0) (#100)
by ttfkam on Thu Oct 28, 2004 at 07:58:35 PM EST

In the whole article, I didn't read much in the way of better options.  I only heard bitching that the currently most popular items weren't to his taste.

If I'm made in God's image then God needs to lay off the corn chips and onion dip. Get some exercise, God! - Tatarigami
[ Parent ]
Mostly agree (none / 1) (#82)
by Shulai on Mon Oct 25, 2004 at 09:22:09 PM EST

www was never meant as an application platform.
This should not ever happened, but market forces do not think in technical terms and they turned a good concept in a pretty bad one.

Intranet are the worst case, as they easily could chose better solutions. And I'm amazed about how many web based projects are on Source Forge.

I always believed the only almost-good way of doing web deployable apps was using Java applets. Currently there are people doing apps using Flash.

It could been worse, tough, but the fact is, web sucks as a dev platform.

Said that, it still has some good things, but as the article suggest, one day developers will curse the big, big defects in all the code we build and deploy today.


Marketers fucked it all up (none / 1) (#86)
by the77x42 on Tue Oct 26, 2004 at 12:55:56 AM EST

Think back to when the web was just black text on a grey background. Those were the days. IE? wtf is that? Netscape was soooo cool. Then someone decided they could sell stuff online. Yuck. Wiz-bang graphics SUCK ASS on the internet. It should be all about the information.

Web applications are cool, however. It just takes a REALLY good programmer to keep everything looking virginized. Library interfaces and.. ahem.. message boards (like K5) are good examples of web-apps that actually work. You don't need JavaScript, and if your pages are designed properly, there shouldn't be too much traffic for server-side validation. Want to spice things up just to make the boss happy? CSS.

The beautiful thing about web-apps is that the bulk can be written in a REAL programming language (php, asp, jsp, etc.) and not some display language like xHTML. If you are a good programmer, your display code should act (mostly) independantly of your backend code.

But I digress, information should be absolutely key. When people throw in JavaScipt, Flash, or pointless navigation forms, the internet loses its focus and can no longer be blamed for the the errors of ignorant programmers or bastard marketers.


"We're not here to educate. We're here to point and laugh." - creature
"You have some pretty stupid ideas." - indubitable ‮

In the end... (none / 0) (#87)
by bml on Tue Oct 26, 2004 at 04:27:47 AM EST

... it all comes down to the developer. I agree that web technologies (HTML, JavaScript, etc) have a huge potential for building clunky, messed-up applications. But you can also build robust and elegant applications using them. Just follow some basic principles:

  • KISS !!
  • Take the user by the hand, make them go step by step.
  • Separate Content from Presentation !! (use very simple HTML + CSS)
  • Put as much of your code as you can on the server side. Use JavaScript scarcely if at all.
  • Avoid creeping featurism. KISS !!!

    As per your other points, read some history of the development of HTTP to understand why it being a stateless protocol is not only a very good idea, but actually the only viable solution. And if I can break a web app by hitting the back button, it's the developer's fault. XForms will probably solve most of HTML forms' current problems, as others have already pointed out.

    All technologies become obsolete sooner or later; good ones get to be considered "legacy" for some time before that. So you're actually praising web apps by saying that... and I agree with you.

    The Internet is vast, and contains many people. This is the way of things. -- Russell Dovey

  • Wrong link (none / 0) (#90)
    by bml on Tue Oct 26, 2004 at 06:13:08 AM EST

    Something happened to the "step by step" link above while posting. The right URL should be:

    IUI guidelines

    The Internet is vast, and contains many people. This is the way of things. -- Russell Dovey
    [ Parent ]

    Interesting.. (none / 0) (#89)
    by tonyenkiducx on Tue Oct 26, 2004 at 05:23:49 AM EST

    Just seems like a general whine to me though. You missed off ASP, which is one of the larger of the web app languages. And it doesn't seem to offer any solutions to the problem.

    I wouldn't go pointing the finger at the languages themselves, HTML for example is the way it is because it needs to work on any platform and was designed many moons ago when the web was a totally different place.

    Unfortunately the openness and wide user acceptance that the web totes as it's main advantage is the main problem. No language will ever be the "norm", until Microsoft achieves its plans for world domination, and by the time browsers are remote application based, as apposed to script based, the internet will again have evolved and a new solution will have to be found.

    Tony.
    I see a planet where love is foremost, where war is none existant. A planet of peace, and a planet of understanding. I see a planet called
    Mozilla to the rescue... sort of (none / 0) (#96)
    by cgenman on Wed Oct 27, 2004 at 12:59:51 AM EST

    The most convincing part of the internet is that nearly all of it is accessable to Mozilla, an open-source solution which adheres mostly to the standards set out by the W3C body.  That there are a surprisingly simple set of standards, with open implementations, gives one hope that this will be reverse-engineerable.  Likewise, with the plug-in architecture of the web, there really isn't any problem with this Legacy staying cruft if a truly new paradigm of networked information dissemenation comes along.  Quite frankly, the web is pretty darned good at what it is, but people who are attempting to shoehorn it into a 3D virtual reality chat room are free to do so with plug-ins.

    No, the real problem is the backend.  Nobody really knows how ASP works.  Apache is open, but it's confusing.  And with minor exceptions, nothing on the back adheres to standards as simple as the HTML 3.0 specifications.  If you think it's hard trying to figure out how a javascript is displaying a menu from a source code, try reading a Perl script manipulation of customer data on a MySQL DB.  Now try reading Perl when nobody knows how to program Perl anymore.  Of course, that would be a little better than an ActiveX site using VB to query an SQL database or (Gasp!) an Access DB.  Remember the old Sinclair you keep around because nobody can figure out how to get your customer records off of the tape deck?  Same thing.  Build with a proprietary solution, and you build for life.

    --
    - This Sig is a mnemonic device designed to allow you to recognize this author in the future. This is only a device.
    [ Parent ]

    Ey? (none / 0) (#99)
    by tonyenkiducx on Wed Oct 27, 2004 at 11:35:06 PM EST

    "Nobody really knows how ASP works." How do you mean?

    Tony.
    I see a planet where love is foremost, where war is none existant. A planet of peace, and a planet of understanding. I see a planet called
    [ Parent ]
    JS has some uses (none / 0) (#91)
    by Occulis on Tue Oct 26, 2004 at 11:39:40 AM EST

    There are several things JS is extremely useful for: reorganizing tables without sucking up bandwidth, form input validation and even some basic sizzle which makes using the web so much easier. Things like beautiful web sites are not necessary. Pure information is fine. No one "needs" a pretty site to look at. However, a pure black and white site with little or nor images is going to be mainstream about as soon as the grocery stores are full of cardboard boxes whose printing has only brand name and nutritional information.

    Shame and War (none / 0) (#92)
    by riceowlguy on Tue Oct 26, 2004 at 01:26:17 PM EST

    Read.

    "That meant spending the night in the living room with Frank watching over me like some kind of Lovecraftian soul-stealing nightmare creature-Azag-Frank

    legacy happens (none / 0) (#94)
    by nerkles on Tue Oct 26, 2004 at 02:04:45 PM EST

    There is an ongoing process where any software system, protocol, etc. that has widespread use can be superceded by another one (hopefully better, but not always--it's not always "betterness" that propels a change), at which point the previous one will fall into obscurity or niche. This is not news.

    Contradiction, the struggle of opposing forces, the synthesis of contradictory aspects into new forms, including at times destruction, is the way the universe works, and software is not exempt from that.

    If you really hate the state of web applications so much, then I humbly suggest that you participate in coming up with a better way to do hypertext and networked applications.

    You do have an underlying point I unite with: that it can be confusing and frustrating at the outset of a project. There are so many languages (many of them quite good), approaches, details, etc. But if you're doing a project of any consequence it's worth learning about all or most of them before you start, and making an informed decision in line with your project's end goals.

    RIAs anyone ?? (none / 0) (#95)
    by hyevoltage on Tue Oct 26, 2004 at 05:25:01 PM EST

    Rich Internet Applications - It seems that a lot of people want to take web-based in this direction. Macromedia is betting the farm by shifting flash from a merely vector-graphics animation plugin to a full application platform. Microsoft is going the same route with its whole Longhorn suite of confusing APIs. Smaller 3rd party vendors are adding to the mix too such as Laszlo et al. They seem to be solving all the problems of web-based apps while still using the fundamental protocols and procedures (http,xml,server-side code). What's all of your takes on this? Google's Gmail is using vanilla javascript, html, etc but mainly because they want the widest compatibility. Will RIAs be the popular way to do web-based in the future?

    your server-side points are incorrect (none / 0) (#97)
    by sesquiped on Wed Oct 27, 2004 at 01:19:39 AM EST

    Because of statelessness and the way forms work, the server side has to consist of a set of discrete endpoints that receive form data from the browser and that have to return a document in response. The users state has to be looked up for each action the user takes and then a decision has to be made which 'document' the user has to see next as a result of that action.

    You can't even use the function call metaphor.

    Sorry, this is simply incorrect. This is a limitation of most (but not all) programming languages and web servers.

    Read this. Here's a simple example.


    OK (none / 0) (#98)
    by rodentboy on Wed Oct 27, 2004 at 02:25:31 AM EST

    I was aware of something similar, ViaWeb using hashtables of closures allowing the function call metaphor can be used, but you yourself admit that this is not the pattern used in most web applications today.

    What the article is bitching about, is the typical web application. There are some beautiful specimens of this species out there but most are pretty scruffy.



    [ Parent ]
    Web-apps are the legacy apps of the future. | 102 comments (69 topical, 33 editorial, 0 hidden)
    Display: Sort:

    kuro5hin.org

    [XML]
    All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!