Slashdot Mirror
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."
Knowing how to code is easy. Being a decent software engineer isn't. 90+% of web developers fall into the first category.
"Neil McAllister was helping out a friend whose Web developer disappeared."
What? Can you DOS people now?
It is an ever-growing jumble of different libraries, standards and tools.
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.
Loading...
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...
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.
Which features are missing, exactly? Cappuccino, for example, implements almost exactly the same APIs and conventions that native Mac/iPhone developers use, only in Javascript.
The serverside part of creating web applications is actually the easy part. It is indeed as you say: just pick a platform and a framework and use that. In most cases you have full control over the server side part of your web application, so you create it just the way you like it. The hard part is creating a good looking and well functioning interface for your clients using HTML, CSS and Javascript which will deliver (somewhat) the same experience, whatever the clients software, hardware or screen size may be. It's hard exactly because you don't know what the client will be using to access your application, as you have no control over this whatsoever.
Pretty good is actually pretty bad.
If it was 'never intended for interactivity', why are POST and DELETE part of the spec? They are designed for interactivity.
If you want to get picky, 'computer' were 'never designed' for media playback, using your criteria. (That criteria being that only the initial thought counts, and not the years and years of changes afterwards.)
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
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.
Life is like a web application. Sometime you need cookies just to get by.
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?)
Perl is for coders, not web designers. As the former, I can pull together and correlate data from all over the place. The only problem is my output is ugly as hell. Since I don't do commercial work viewed by the general public that isn't a problem but it would be nice. Whenever I right click and look at the source for a fairly complicated webpage I get depressed. Seems way, way too complex and you are not seeing everything being brought in via CSS and JS libs.
I keep looking for a way to bridge the gap between WYSIWYG page designers and plain text perl backends. Any and all suggestions are welcome.
-Xanthos
Average Intelligence is a Scary Thing
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.
Loading...
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:
Really, web development ain't all that hard, but the customers often make it far more expensive then it needs to be.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Say I want to write a speech synthesizer in JavaScript.
There is no emoticon for what I am feeling.
Populus vult decipi, ergo decipiatur...
"Force shits upon Reason's back." - Poor Richard's Almanac
x86 frameworks have been around for how many decades? HTML5 has been around for how many months?
Web development may seem like a pain, but last I checked, it's the only truly cross platform development environment that has ever existed. If your bank, for instance, had to develop binaries for every platform, you'd never be able to login and move your money around at 2 in the morning.
It's taken time to develop the standards that enable platform agnosticism of more vanilla HTML standards, and it will take time to flesh out new standards that compete with native toolkits for interaction. But it will happen, and compiled, single platform application development will be nearly unheard of.
You don't need to know many languages to develop a good webapp! It only takes HTML, CSS, Javascript, SQL, PHP and a bit of Linux knowledge to put together a simple app!
As a webmaster, if found the article strange.
We have better tools today, than years ago. Firefox and his amazing extensions (like Firebug or Webdevelopper) make analizing what is going out here, much easier. JQuery itself make writting javascript predictible (so if it works here, it will work on other browser). There are not lacks of good Code Editors. We use to have good HTML Wysiwig editors, but these are outdated by now (I could be wrong, but the better pad nowdays seems the brain of the designer).
So.. what you need? REDMINE to track proyects? Good debuggers? Inspectors? Documentation?
Working with HTML could be hard (specially if you have to support webpages that have to run on Internet Explorer 6), HTML itself is crap, Javascript is much more evil than people know (but I love it, like a bad girlfiend)... but.. the tools? what tools you need? tools that automagically write code (good code) for you? Visual Studio seems to have some of these, and while I don't use these myself, I have ear good things... (if you are into wysiwig and how bloated any code touched by microsoft looks. ). What you want exactly?
Could be, maybe, that you don't know what tools we the professional webmaster have available? :-)
-Woof woof woof!
In this case the term 'ways' is used synonymously with 'distance'. This comes from using the word 'way' to mean 'road' as in 'highway'. 'Ways' is then by definition 'a large distance'.
'A ways to go' actually a colloquialism, so I understand your confusion.
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 :-)
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
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
It is when the choice is put into the hands of monkeys with darts. That's the problem he's pointing out. Most small companies don't hire seasoned developers unless they specialize in software development. They get whoever they can for cheap, or, at best, they get what their limited experience tells them is the best person. They hire:
1) Kids fresh out of college who know theory but have worked with very little.
2) People with no actual formal computer training who simply "know about computers" and and will work for what a real developer (or even a kid fresh out of college) would consider shit. But which beats what the guy was making selling tires.
3) People with experience, but in the wrong things. I'm a very senior sys admin type. My resume looks very fancy and technical. I'm sure I could convince some mom and pop to hire me as a web dev, especially if I was willing to take a pay cut (say I lost my job and needed something now). Could I build a web site? Sure. Could I make it functional? Absolutely. Would you want to come behind me and maintain it? I'd like to think so, but reality is I'm not an experienced web developer. I'm likely to make bad choices, especially in the beginning. Especially if mom and pop are breathing down my neck because they hired me to make them a web site dammit. It's been a week, where is the damn thing already?
I'm not saying you're wrong of course. More choices is a good thing in theory. For the expert, it's nearly always a good thing. This doesn't change the reality of the situation though... most people aren't experts. Even the ones working in the field. Sit an inexperienced kid, an enthusiastic amateur, or a sys admin who needed a job (now) in front of the current embarrassment of choices, and we're all likely to make bad choices. Probably for the best of reasons. Then we're going to go get new jobs, and the next kid/amateur/sys admin is going to make new bad choices and pile them on top of the old bad choices with a little duct tape and some Gorilla Glue.
It's a thorny problem. Fewer choices is bad, but the current situation isn't great either. Luckily I'm a sys admin, so you developer guys figure it out :-P
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
You're thinking of the Dunning-Kruger effect.
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
We know where leadership by an anti-intellectual "strongman" who scapegoats minorities and likes boisterous rallies goes
The correct usage is "a way to go".
How about procedural audio? Say I want to write a speech synthesizer in JavaScript. How do I send the samples to the speaker?
Well, it depends on if you mean "in the browser" or "in JavaScript." If you mean that latter, I'd probably fire up Mozilla Rhino and put together something using the libraries that ship with Java. Some of those are still available in the context of the browser via applets in a lot of cases, too, so with some work, you could probably do it in browser as well.
If you mean in-browser, no Java libraries, I'd probably have the samples in an array of bytes which I'd base64 encode and stuff into the src attribute of an audio, embed, or object tag as a dataURL. This likely wouldn't work in realtime, but then again, you didn't ask for a realtime speech synthesizer. :)
(FWIW: I know Flash 10 has an audio buffer explicitly for writing to programatically in realtime, and I agree it's awesome I agree a lot of the people going on and on about how great Ajax was and HTML5 is and how it all renders Flash totally unnecessary are generally not thinking about features like this. Just pointing out that there is in fact more than one way to do it and some of the other approaches have their merits.)
Tweet, tweet.
See it in action here. If you're talking about that mess of cluster that is subclassing from Exception, yes it doesn't have that (perhaps Dojo or other js frameworks do?) However, unlike Java and the like, this language at least has closures.
Make sure everyone's vote counts: Verified Voting
Actually ways is a pluralized singular word taken from an olde English word (1588) wayes. While it is the same as the word way, it does have very specific contexts that it is used in the English language, in both Queens and American English. Most people are just not taught it, and either pick up it's usage through general day to day speech. But either ways, it is just a reference to either the same idea or concept conveyed by it's non-pluralized brother as an adverb or noun.
Common examples are:
sideways - The hat sat on his head sideways.
If you tried the same sentence using the word sideway it just doesn't work...
Always - Not a fair example, but same root, same result. You will never hear someone say alway.
ways - (n) The old man is stuck in his ways.
- (adv) He had a ways to go, but he got there.
While the first sentence may sound correct with way, the proper word is ways. It is not a colloquialism or an idiom, but rather proper speech. The second sentence could be a long way to go, but again, the proper adverb when not using an adjective is ways, not way. Just one of those wonderful bizarre details with the English language. We have too many words for the same meaning, and the context and usage matters. In this case, it's a very old word we just use, and most people no longer realize there is a difference between the usage of ways and way. But, there is, in a very subtle context.
As a noun, it represents an idea of a pluralized singularity. All the ways are his. Whenever you try to summize a multitude into a single context, way becomes ways. Rare, but for some silly reason the context exists.
As an adverb, it again works to pluralize a single context. There are multiple ways for "it" to go. It, being the context of the verb, creates a singular entity to focus the ways upon. I am not aware of any other word that actually operates in that fashion, but I am sure they are out there.
And as far as as I am aware, ways is only used like this as an adverb or noun. At no other time can you create a context that can contain this odd scenario... But then again, I am not really that knowledgeable about the English language...