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.
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...
The ultimate glue language. It's not pretty as python but it's a woodchipper when it comes to parsing and re-gluing outputs. Indeed that's what the acronym P.E.R.L strands for. My favorite reason to use perl is that you can do more things more easily with the core language. You don't have to depend upon importing libs. The surprise is that it's also not bloated at the core level: compare the thickness of the perl pocket ref to any other language. it's tiny.
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.
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.
None of those sentences make sense, because "a" is used for singular words.
While i am one to admit that Web Dev is, for some parts, a bunch of hacks, most of it isn't.
JavaScript, the DOM, and CSS are all highly detailed on W3C site. The only ones who chose to ignore the standards was Microsoft. (although it seems they are turning around now)
All the stuff you said is literally the exact same crap we deal with in Operating Systems NOW.
Not all programs run on all OSes the same. I've had cross-platform programs run faster / slower on other machines, use more / less memory, look different occasionally, etc.
Let's not forget how much of a bitch it is in the first place to MAKE a cross-platform executable. Compared to web dev, web dev is making a cup of coffee, cross-platform software development is like building the machine to make the coffee granules. (actually make them, AKA 3D printer or something like that)
If you actually READ the standards on W3C and work with them, you shouldn't ever screw anything up outside of IE browsers, or working-drafts, or on the rare occasion where there is a legitimate bug in finished implementations of standards.
JavaScript doesn't lack a damn thing when it comes to application development for the most part, it is the DOM model that is the mess, and methods and attributes across some browsers. (see keycodes and other such things)
You either haven't used JavaScript at all / are trolling, or you just plain suck at it.
The only other problems are really memory management and leaks with functions and objects. (which varies between each browser)
Again, this is all just sounding more like software development in general: it all sucks, it is all a mess, but those who stick to the standards get by fine without any problems, it is the ones who have to deal with the idiots who went outside the standards and generally fail at decent coding styles (no indent, awful naming, etc)
The worst thing of all web development is the web browsers.
All these people developing them refuse to do huge changes to the base code to actually stick to the standards simply because it will break websites.
SCREW THEM, if the developers in both cases stuck to standards, none of this mess would exist!
People who code shit deserve to suffer incompatible mess.
If everybody done it at the same time instead of pussyfooting around with minor changes, we'd look back at this day with a smile and sigh of relief.
Ditch compatibility modes as well. If people refuse to update, they don't deserve to be on the web.
Backwards Compatibility is the worst thing in development, it just results in a mess.
I think he's talking about JavaScript missing critical language features. You know, things like proper namespaces, exceptions, static typing, a sensible object model (or even something like the approaches to prototype-based OO that Self and Io take), and so on.
There's a big difference between a scripting language like JavaScript, and scripting languages like Python, Perl and Ruby that are much more advanced and suited to large-scale development. Even then, there's a much bigger gap between those languages and languages like C++, Java and C#, which are suitable for huge-scale development projects.
MySQL sucks? Don't use it.
PHP sucks? Don't use it.
Hackiness in the backend is not a difficult problem to solve. Most Web developers use PHP and MySQL? Well, that's because they're bad programmers, and these tools are targeted at bad programmers. Use something better.
You don't even /need/ to use JavaScript. Things won't fly around the screen and people might have to wait a microsecond for their FIOS to download an entire new page, but Web 2.0 cruft is hardly a requirement. You're free to use no JS at all, dab it in where it's useful, or be a jerk and make your whole app JS-based if you want.
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
And I can related. I used to be in the "J2EE is the only proper way to do things" camp too. Read about 4,000 pages worth of books cover to cover about everything from Struts, Hibernate, Tapestry, and EJB's on. Also thought all interfaces should be done with XML and XSLT because it was just the right way. Preached about it to people.
Then reality actually hit. I went to work for a large telecom company who's upper management constantly was obsessed with converting everything into J2EE but because I had some PHP experience I ended up doing both and got to live in both worlds.
The result was was that, of about 80 different internal and external websites that worked 75 of them were PHP, 4 were J2EE, and 1 was ASP (pre.NET). Our team of 3 developers maintained all 75 PHP sites and 1 of the J2EE apps. The other three J2EE apps each had a team of 8 people on average, dedicated DBA's (because the application "required" Oracle). The ASP app only worked in IE6 and had 3 people responsible for it.
Now, exactly what does it say about maintainability when 3 people can maintain 75 different sites and have spare time for new development. After a while, when my eyes were officially opened to the man hours / licensing fees wasted on pursuing the "right" way of doing things we convinced our VP to let us rewrite a particularly buggy J2EE app that we had to interface with a lot. This system had take 6 months for 5 people to build.
Our team rewrote the entire thing in 1 night, bug-free for at least the next 1.5 years too (I left for another job after that).
The lesson that we learned was simply this: practical abstraction.
You can strive for ideals all day long, but if the ideals are so bloated that it takes 8 people to do the job of 1 person it is no longer cost effective.
With J2EE you spend so much time learning all of the "right way" to do things that it prevents you from having any amount of time to learn all the other surrounding web technologies. You also end up with people who are literally afraid to learn anything new because they've invested so much time into learning what they already know. Ever meet Java people who think EVERYTHING needs to be done in Java? That's why.
At the same time, a language like PHP that you can be polished with in a week is a powerful tool in the hands of a good developer. It gets a bad rap because it's so easy to learn a little bit at a time that designers and other people with no formal programming background at all are able to jump in and create some bad code.
For further reading material, check out "The Top 10 Signs You're a Crappy Programmer (and don't know it)." http://damienkatz.net/2006/05/signs_youre_a_c.html
"Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson