×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

HTML Web App Development Still Has a Ways To Go

kdawson posted more than 3 years ago | from the walled-gardens-keep-the-wind-out dept.

Programming 279

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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

279 comments

This just in... (5, Insightful)

sunking2 (521698) | more than 3 years ago | (#32207512)

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

Web development is hard for even talented people. (4, Interesting)

Anonymous Coward | more than 3 years ago | (#32207636)

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.

Re:Web development is hard for even talented peopl (1, Offtopic)

drachenstern (160456) | more than 3 years ago | (#32207664)

Way to troll. It's so sad that every one of your points is fairly well wrong and could earn you a post nearly as long in refute for each. If you read that post and thought it was insightful, you've been trolled.

Goodbye.

Re:Web development is hard for even talented peopl (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#32207734)

"It's so sad that every one of your points is fairly well wrong and could earn you a post nearly as long in refute for each." - and to demonstrate this, you'll refute precisely none of them? Whether you agree with GP's points or not, at least he gave his reasons for feeling that way, strange for someone throwing the troll accusation that all you did was attack his post without backing up your own views in any way.

Re:Web development is hard for even talented peopl (-1, Flamebait)

Anonymous Coward | more than 3 years ago | (#32207832)

Way to troll. It's so sad that every one of your points is fairly well wrong and could earn you a post nearly as long in refute for each. If you read that post and thought it was insightful, you've been trolled.

Actually, having done some web development, I'd like to see some actual refutation of the parent post instead of just some implied snarkiness that the poster must be an idiot because you disagree with him. In fact, I'm not even sure I agree that it was a troll.

In my experience, the tools for web application development are overwhelmingly crufty, and a stateless, connectionless protocol is a nuisance. There's a whole slew of bolt-ons that try to hide the fact that the underlying HTML is completely unsuited for the task at hand, and they don't work consistently across browsers.

From a user perspective, I find that web interfaces frequently lead to way more clicking and waiting that an actual local app would. Layouts are crufty, and for reasons unknown to me, occasionally a page renders in completely fucked up ways.

I'm more inclined to agree with the article and the poster you replied to -- web development tools suck, and they frequently produce results that suck.

Re:Web development is hard for even talented peopl (1)

K. S. Kyosuke (729550) | more than 3 years ago | (#32208172)

In my experience, the tools for web application development are overwhelmingly crufty, and a stateless, connectionless protocol is a nuisance.

Then make your application architecture stateful! Use continuations, Luke.

Re:Web development is hard for even talented peopl (2, Interesting)

mini me (132455) | more than 3 years ago | (#32207698)

although it lacks many of the most basic features necessary to do that sort of development effectively.

Which features are missing, exactly? Cappuccino [cappuccino.org] , for example, implements almost exactly the same APIs and conventions that native Mac/iPhone developers use, only in Javascript.

Re:Web development is hard for even talented peopl (1)

tepples (727027) | more than 3 years ago | (#32207922)

Which features are missing, exactly?

How about procedural audio? Say I want to write a speech synthesizer in JavaScript. How do I send the samples to the speaker?

Re:Web development is hard for even talented peopl (4, Funny)

mujadaddy (1238164) | more than 3 years ago | (#32207970)

Say I want to write a speech synthesizer in JavaScript.

There is no emoticon for what I am feeling.

Re:Web development is hard for even talented peopl (1)

tepples (727027) | more than 3 years ago | (#32208124)

JavaScript on the HTML DOM is the lowest common denominator in much the same way that Java applets used to be. If not in JavaScript, then how else should I make an app that synthesizes speech on the client side without requiring me to write a native app for each platform, get the app digitally signed by the platform's controlling organization (in the case of non-PC platforms), and convince PC owners to allow its installation?

Re:Web development is hard for even talented peopl (1)

mini me (132455) | more than 3 years ago | (#32208230)

You can use data: URIs to send the generated audio data to the browser's media player. Not exactly pretty, but it is possible. Wrap it in a sane API and it needs to be no more difficult to use than a native audio API.

Re:Web development is hard for even talented peopl (0)

Anonymous Coward | more than 3 years ago | (#32208018)

although it lacks many of the most basic features necessary to do that sort of development effectively.

Which features are missing, exactly? Cappuccino [cappuccino.org] , for example, implements almost exactly the same APIs and conventions that native Mac/iPhone developers use, only in Javascript.

Holy mother of god. That's so incredibly scary ... from their site ...

Cappuccino was implemented using a new programming language called Objective-J, which is modelled after Objective-C and built entirely on top of JavaScript. Programs written in Objective-J are interpreted in the client, so no compilation or plugins are required. Objective-J is released alongside Cappuccino in this project and under the LGPL.

Fucking hell. This is a hack built on top of a kludge built on top of a monstrosity and then delivered through your web browser. Make it stop!!

This is just shit piled on top of shit, with HTML and HTTP still sitting at the bottom. The web has done more to mangle software development than almost anything else. It's all workarounds to try to overcome the fact that the underlying technology is outdated and useless.

There's been so many attempts to make something workable on top of this mess -- having one's browser running an object-oriented framework and platform abstraction layer in an interpreted language is about as boneheaded as you get.

It's all one big giant steaming turd.

Re:Web development is hard for even talented peopl (1)

mini me (132455) | more than 3 years ago | (#32208102)

Yes, it is a mess, no doubt. But the features are not missing.

Re:Web development is hard for even talented peopl (1)

Dishevel (1105119) | more than 3 years ago | (#32208168)

having one's browser running an object-oriented framework and platform abstraction layer in an interpreted language is about as boneheaded as you get.

Sorry. I thought that was how 50% of the web "worked". :)

Re:Web development is hard for even talented peopl (1, Insightful)

Anonymous Coward | more than 3 years ago | (#32208262)

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.

Re:Web development is hard for even talented peopl (1)

K. S. Kyosuke (729550) | more than 3 years ago | (#32208138)

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.

Uhm, deficiencies of MySQL and PHP don't necessarily mean that web development in general has to suck. What about the Seaside [seaside.st] framework? To me, Seaside is a clear demonstration how much it helps sometimes to step away a bit and rethink an old thing.

Re:Web development is hard for even talented peopl (1, Insightful)

Anonymous Coward | more than 3 years ago | (#32208222)

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.

Re:This just in... (0)

Anonymous Coward | more than 3 years ago | (#32207660)

90+% of web developers fall into the first category.

I belong with the other 20% [bash.org] .

Re:This just in... (1)

Saishuuheiki (1657565) | more than 3 years ago | (#32207748)

I have to agree.
As with any programming, proper commenting can clear up misinterpretations and confusion.

The greater problem with web programming is not the inconsistency or complexity of it, but rather how easy it is. People who don't know the fundamentals of programming make a mess, and the people who hired them don't know any better until it explodes.

Re:This just in... (1)

Imagix (695350) | more than 3 years ago | (#32207946)

As with any programming, proper commenting can clear up misinterpretations and confusion.

I prefer some of the statements made by Fowler in his Refactoring book. To paraphrase, code sometimes has bad smells. There's two ways to fix it. First would be to refactor it into something that doesn't smell, or apply a liberal dose of deodorant known as comments. They don't fix the smells, they just hide them. Generally speaking it's better to rewrite the code into something that's understandable rather than commenting it. (and then later on, the code gets changed and the comments don't, and the world gets worse....)

Re:This just in... (1)

Mongoose Disciple (722373) | more than 3 years ago | (#32208008)

On the other hand, cleanly written code can make obvious what the code is doing, but it still sometimes requires good commenting to explain why.

Was this code just never correct? Did the requirements change? Is there a good reason for what it does that may not be apparent to the coder? Will something break downstream if it's changed? (Ideally the answer to that last question will always be no, but the reality lies somewhere else.)

Re:This just in... (5, Insightful)

ducomputergeek (595742) | more than 3 years ago | (#32207752)

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

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

Re:This just in... (2)

abigor (540274) | more than 3 years ago | (#32207898)

This is a great post and deserves to be modded up. Well-designed, maintainable software is kind of timeless (barring the obvious) and is orthogonal to the technology used.

The corollary to this is too many developers aren't taught how to design software. Instead, they learn about "features" and technology-specific stuff, when in reality the technology is just not that important.

Re:This just in... (1)

gorfie (700458) | more than 3 years ago | (#32208070)

I disagree that this is a problem with Web developers. Rather, it's a problem with non-Web developers stuck in the role of a Web developer. They are always trying to find ways around the stateless nature of the Web with the new "Ohh shiny" of the month. True Web developers are comfortable working with PHP, Classic ASP, and other technologies that don't try to obscure the fact that you're working with the Web (i.e. webforms). Up until the introduction of jQuery and ASP.NET MVC I hadn't really been excited about any of the "Ohh shinies" over the past decade.

Re:This just in... (1)

drooling-dog (189103) | more than 3 years ago | (#32208098)

One of the hardest aspects of starting a new project is just deciding which languages and tools - with their respective ecosystems - to employ. There is always pressure to jump to the new language du jour that all of the cool kids seem to be using, and as a result everyone spends half their time climbing one learning curve after another. How many developers out there have used 4 or 5 languages in the past two years? More than a few, I'll bet. Each new environment is the panacea for all of the frustrations encountered in the last project.

OTOH, sometimes making a switch does pay dividends, despite the learning curve. The trick is to recognize those opportunities without simply succumbing to fad and fashion.

Re:This just in... (1)

MaWeiTao (908546) | more than 3 years ago | (#32208238)

I find it's the opposite. The vast majority of web developers seem overly eager to avoid extra work, routinely compromising the quality of the end product. This means they wont bother to clean their code, and instead of researching and learning more efficient ways to get something done they'll instead go with some clumsy approach that doesn't work well, but does work. And forget about expecting them to learn something new.

Re:This just in... (5, Insightful)

R_Dorothy (1096635) | more than 3 years ago | (#32207782)

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

Re:This just in... (4, Insightful)

Migala77 (1179151) | more than 3 years ago | (#32207902)

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

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

Re:This just in... (0)

Anonymous Coward | more than 3 years ago | (#32207956)

From my experience, those that actually are in the top 10% don't think they are. Can't find the source, but there was a research study done on engineers. The bad ones always thought they were better than they were while the good ones always downplayed their accomplishments.

Re:This just in... (1)

eabell (398690) | more than 3 years ago | (#32208256)

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

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

This is because of the Dunning-Kruger Effect (http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect [wikipedia.org] ), which has been studied.

The more you know.

Re:This just in... (4, Insightful)

Junior J. Junior III (192702) | more than 3 years ago | (#32208024)

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

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

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

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

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

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

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

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

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

It's a matter of economics. If it becomes easier and better and therefore cheaper to whip up a web application interface in XAML than it is to do the equivalent in HTML5, web application developers are going to do that, and accept that users will have to bite the bullet and install Silverlight on their systems in order to use the web. Perhaps at some point browser vendors will capitulate and integrate an (open?) implementation of Silverlight directly in the browser, so it won't be an add-on anymore. If that happens, Microsoft basically owns the world wide web. Game over.

At this point, Microsoft is well on its way to winning the battle to usurp the standard. They will have made W3C HTML obsolete, and W3C will have in no small part contributed to this by failing to advance the state of the art in as rapid a fashion as Microsoft has been able to advance Silverlight.

The best way to preserve open standards is to advance them. W3C needs to do this faster than they have been able to. No, it ain't easy. But it is necessary. The opportunity exists for others to come in and steal W3C's lunch, and unless they're strong enough to compete, rest assured, it will get stolen.

Re:This just in... (1)

jellomizer (103300) | more than 3 years ago | (#32208050)

Agreed...
Most of my programs are Web Applications but I wouldn't call myself a Web Developer. I am a software developer first who happens to use HTML for the data output and Javascript to streamline the User Interface. But most of the real work is behind the scenes. Creating database procedures (Yes there is a big debate about stored procedures if you should use them or not, I tend to like them), creating server side programs to gather the information correctly, manage security, and do any additional stuff that you can't or shouldn't do on the client. I use HTML, Ajax and Javascript as the last level to actually get the program to display and be useable (granted there is a lot of work on that side to) But I would be taking about the same amount of time in other languages making a solid UI in it anyways.

HTML, javascript, AJAX (which is still javascript) and the server side development tools, are all good tools and if you know how to write software vs. just knowing how to code it means you can make a robust programs for the Web. It doesn't require all this extra stuff, it just requires good developers.

There are a lot of junky apps that are hanging on by a thread that are non-web based too... No matter what tools you give them they will still make crappy software if they don't know how to make good software.

The great thing about standards (-1, Flamebait)

Anonymous Coward | more than 3 years ago | (#32207524)

there are so many to chose from!

Hmmm? (2, Funny)

drc003 (738548) | more than 3 years ago | (#32207534)

"Neil McAllister was helping out a friend whose Web developer disappeared."

What? Can you DOS people now?

Is this flame bait? It makes no sense. (-1)

Anonymous Coward | more than 3 years ago | (#32207548)

Is this flame bait? It makes no sense.

C Development Still Has a Ways To Go (4, Insightful)

Gudeldar (705128) | more than 3 years ago | (#32207552)

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

Re:Book Development Still Has a Ways To Go (0)

Anonymous Coward | more than 3 years ago | (#32207606)

It is an ever-growing jumble of different publishers, style manuals, and editions.

back to perl! (1, Insightful)

slashnot007 (576103) | more than 3 years ago | (#32207644)

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.

Re:back to perl! (0)

Anonymous Coward | more than 3 years ago | (#32207712)

Except for one minor detail - perl isn't an acronym.

Re:back to perl! (1)

just_another_sean (919159) | more than 3 years ago | (#32207836)

Sure but's been backronymed [wikibooks.org] so many times I tend to think of it as an acronym now. The best part is depending on mood and how coding is
going there are a plethora of acronyms to choose from!

Perl - A high level scripting language common on Unix-like systems, with the common backronym of "Practical Extraction and Report Language", but jokingly referred to as the "Pathologically Eclectic Rubbish Lister". Both expansions appear on the man page. More recently, "Parse Every Random Line", in honor of the extensions proposed for Perl 6. Another less colorful one is "Pathetic Excuse for a Real Language"

from: wordIQ [wordiq.com] .

Re:back to perl! (0)

pantherace (165052) | more than 3 years ago | (#32207804)

I've been doing something in python, and I have to ask someone who thinks it's 'pretty' why there appears to be no for loops with floats (or hell, ints). You can write your own, as I have, but that's far from pretty, compared to almost any other language.

Though, I don't think anyone would describe perl as pretty.

Re:back to perl! (1)

kallisti (20737) | more than 3 years ago | (#32208274)

what exactly is wrong with

for x in xrange(start, end, gap):

that's a for loop with ints. If you thinking of writing a loop of the form for(float x=start; xend; x+=gap) then you really shouldn't. That's how rounding errors accumulate. You can make your own for loop with a generator

def floatloop(start, end, gap):
    val = start
    iter = 0
    while(val end):
          yield val
          iter+=1
          val = start + iter * gap

then the code is
for x in floatloop(start, end, gap)

so, floating loop in 7 lines of code with protection against accumulated rounding errors. Not bad.

Re:back to (UGLY) perl! (2, Insightful)

xanthos (73578) | more than 3 years ago | (#32207840)

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

Re:back to (UGLY) perl! (1)

Machtyn (759119) | more than 3 years ago | (#32208068)

I think the problem with looking at html code from many webpages today is that it is all auto-generated by a back-end server. And, IMO, auto-generated code is almost never pretty, producing a jumble of hard to read code.

Re:back to perl! (1)

bigredradio (631970) | more than 3 years ago | (#32207998)

I love Perl for web programming. That is my primary language. It is the one interpretor that is on almost every system (awesome for those who sometimes live outside the windows and linux world). One perl module that I cannot live without is objToJson . http://linux.die.net/man/3/json [die.net]

"tightly controlled ecosystem"? Bullshit... (5, Insightful)

Assmasher (456699) | more than 3 years ago | (#32207560)

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

Re:"tightly controlled ecosystem"? Bullshit... (2, Interesting)

Aladrin (926209) | more than 3 years ago | (#32207706)

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.)

Re:"tightly controlled ecosystem"? Bullshit... (4, Insightful)

Assmasher (456699) | more than 3 years ago | (#32207960)

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.

Re:"tightly controlled ecosystem"? Bullshit... (1)

fusiongyro (55524) | more than 3 years ago | (#32207976)

You mean PUT and DELETE, which came in HTTP 1.1 [w3.org] , significantly after HTTP 1.0 had defined all the methods as GET, HEAD and POST. [w3.org] These deal with the HTTP's resource model, which only deals with the URL notion of thing, not page-level interactivity which is what I think the OP was talking about.

Still, I do like HTTP 1.1 and one thing I like about REST is that it builds on what appear to me to be fundamental assertions about the HTTP model. You're not fighting the model, you're working with it. Still, I do wonder about how we got where we are today. Things are much harder than they need to be. Many of the things that help initially wind up hurting in the long run, and staying current is a constant battle.

Re:"tightly controlled ecosystem"? Bullshit... (1)

mini me (132455) | more than 3 years ago | (#32207856)

Java was on the right track, but was, perhaps, a little ahead of its time. Instead of rendering HTML, the browser needs to provide a virtual machine environment in which applications can be downloaded over the network, much like how web applications are loaded today, but implemented in languages suitable for development (which can include, but should not be limited to, Javascript).

HTML does not need to go by the wayside, of course. If your goal is to display an HTML document within the browser, you can link to the appropriate rendering engine application. The cool thing about this is that you would have the power to instruct Internet Explorer, for example, to download the WebKit renderer in order to display your HTML. If your need is HTML with some wiz-bang feature that nobody has thought of yet, you can write or extend your own HTML rendering engine and have the browser use your engine instead.

Where Java failed is that it tried to mimic the way native applications were installed and executed. It provided no benefit to the end user over a native application. WebStart attempted to solve the problem to some extent, but still did not hit the mark. We do not need to replace the browser, we just need to rethink what the browser needs to be capable of. A full virtual environment accessible to developers through the browser opens up a world of possibilities.

It's just new (2, Interesting)

copponex (13876) | more than 3 years ago | (#32207980)

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.

The problem is with the serverside code, not html (1)

TheSunborn (68004) | more than 3 years ago | (#32207566)

The problem in his example is with the serverside code not html.

And if you want to, it it simply to choose just a single vendors framework and use only that.

Re:The problem is with the serverside code, not ht (2, Insightful)

dingen (958134) | more than 3 years ago | (#32207704)

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.

Re:The problem is with the serverside code, not ht (1)

xclay (924789) | more than 3 years ago | (#32207850)

Upon reading the article more carefully, it looks like it was mostly administrative configuration problems. Take a look at what he's saying:

If I copied the site to a new server, it broke. If I moved it to a different directory, it broke. If I tried to tweak the primary navigation, the page layout blew up. If I disabled a JavaScript function, suddenly all the images stopped loading

Merely copying a site to another server won't do, you need to make sure you have correct extensions, and hopefully, the developer was conscientious enough to allow for easier relocation of the site so you can just change some settings on just one file rather than do a full-blown hunt throughout the code. Tweaking the primary navigation also heavily depends on the architectural design of the website. In summary, I think the developer just did a poor job of doing some basic designing prior to the creation of the website. Therefore, I think the article is just a big complaint to write something before the drop time for his article.

Mostly (5, Insightful)

Poodleboy (226682) | more than 3 years ago | (#32207570)

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...

Re:Mostly (1)

xtracto (837672) | more than 3 years ago | (#32207814)

The article is just pointing some things that we real software developers have known from a looooong time: it is easier to develop and maintain software that uses an integrated framework than a collection of frameworks.

This is part of what software companies have been selling for some time, such as Microsoft's "solutions" like the DirectX platform, or the VisualStudio/WinForms/MicrosoftSQL platform. My preferred technology is however Java/JDK/JDBC/etc...

Not that it is not possible to develop using bits and pieces from projects here and there... however in the long term and all other things equal (like the quality of the developer itself), having an integrated framework makes the code more robust.

All that of course, in my opinion.

Re:Mostly (1)

FooAtWFU (699187) | more than 3 years ago | (#32207862)

The glory of your vision may be more widely appreciated when a major vendor can hammer it into the thick skulls of the rest of the world's development community until they come around to appreciate it on their own. :)

(Just sayin'. I mean, otherwise, why would they have even heard of you? Remember that these people aren't necessarily in on the Hot New Stuff in the grassroots developer community, and their employers probably are even worse.)

Re:Mostly (1)

theshowmecanuck (703852) | more than 3 years ago | (#32207892)

What I got from this is that he is saying that there is a preponderance of 'flavour of the day, week, etc.' as far a what the new silver bullet language or tool is. And when a company has a site that is any kind of old there can often be a jumble of all these silver bullets. It is better to stick with one technology if you can so that your code base is maintainable (my main complaint with the way most agile projects are implemented... the 'documentation is the code' doesn't help much ten years from now). If you use one vendor's solution, usually it means that the technology/implementation methods stays stable, except for any added functionality the vendor may add. That way the code base is coherent and people ten years ago don't have to learn all the languages that were considered silver bullets over the same time span. Granted, it doesn't mean you need to use a solution from a closed source vendor. I'm sure there are open source ways to go. Just don't switch to the language du jour all the time. But then again, I think we have heard the same thing many times here. And we will likely hear it again since people, especially programmers, like shiny new things. Meanwhile, businesses just want things to work, and don't care how, as long as it doesn't impede their revenue stream (like happens when something breaks and you can't find a programmer who knows some framework a programmer used on their system five years ago because he/she thought it was cool).

Re:Mostly (1)

malkavian (9512) | more than 3 years ago | (#32208022)

All the management aside (sounds like this server many not suffer from a coding problem; it definitely suffers from a design/management issue though), the "backed up by a major vendor" doesn't even come into it.
If you end up with a loose scrabble of .net, asp and whatever other techs Microsoft have released as web development languages over the years, I don't think a call to Microsoft would have helped in the slightest.

Yeah, IE6 failed (-1)

Anonymous Coward | more than 3 years ago | (#32207572)

And we don't ever want to go back there again.

Web development is easier than it should be... (0)

Anonymous Coward | more than 3 years ago | (#32207648)

The suggestion that "Web application development [is]harder than it needs to be" is a false premise. It is because of this assumption that many developers choose the web application framework du jour, and then move on when something 'easier' comes along.

In 6 years we haven't had to change our procedural plpgsql backends to our web apps. Changing from PHP smarty templates to Django templates is relatively hard.

HTTP is the problem (1, Interesting)

Anonymous Coward | more than 3 years ago | (#32207656)

HTTP needs a replacement for application development. It was designed for document retrieval not applications. For the past 15 years all these frameworks have been a hack to get over the limits of HTTP as a protocol used in application development. AJAX is the latest hack to overcome limits in this aging protocol.

So we should all be .NET monkeys? (0)

Anonymous Coward | more than 3 years ago | (#32207674)

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.

So if that's the best ecosystem to work in... and Visual Studio is one of the best IDEs out there... we should all be .NET programmers?

Are we trying to copy GUI apps too early? (1)

bigredradio (631970) | more than 3 years ago | (#32207708)

I have built web applications that attempt to mimic already established GUI applications. One of the biggest problems I face is trying to recreate the GUI experience with widgets that are not available. Take for instance a true combo-box. This is a widget that looks like a dropdown, but allows the user to type in the text field as well. In trying to recreate a simple widget that is available in GUI toolkits, I have to mix javascript with a traditional select input field along with changes to the css and div tags. It is a lot of code to perform a basic GUI functionality. If we are moving toward a world of web apps, then the html standard needs to provide GUI-like widgets. Displaying video natively is great, but I want all the different selectors, calendar widgets, etc. to be standard. Otherwise it is still a lot of code to perform smoke and mirror tricks to look like an application.

"a ways" to go? From a veteran editor... (0, Offtopic)

mi (197448) | more than 3 years ago | (#32207720)

Is not "ways" a plural? Can article "a" be used in front of it? Ever?..

Could a native English-speaker kindly explain it to this Ukrainian immigrant?

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

RJFerret (1279530) | more than 3 years ago | (#32207874)

"a ways to go" might be an idiom? Heck, "a ways" might be.

In this case, "ways to go" might be thought of as singular, so "a ways to go" makes sense in a roundabout way.

"He has a ways to go" would mean he needs to grow.

"They have a ways to go" would mean they are far from reaching their goal.

"They had a ways to go yet" would mean the destination is still quite a ways off.

I don't know the proper grammar terminology/explanation for it, but it's correct.

Re:"a ways" to go? From a veteran editor... (1, Insightful)

Anonymous Coward | more than 3 years ago | (#32207974)

None of those sentences make sense, because "a" is used for singular words.

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

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#32207918)

I think that it's just an idiom. Or, possibly, a phrase that was, at one time, correct under current usage rules, and has outlasted that set of usage rules. If something "has a ways to go" this means that it is a significant distance from where it needs to be. Occasionally, it contains a polite, if slightly pointed, suggestion that it may never get there.

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

bsDaemon (87307) | more than 3 years ago | (#32207942)

Chances are, no, most native English speakers couldn't really explain it, at least not accurately. I'm a native English speaker, and I have a degree in Literature. I didn't really learn grammar in school until I took Latin and Spanish in high school, and more Latin and Japanese in college. I spoke and wrote well before the foreign languages, but largely because I have educated parents and grandparents and just sort of internalized it early on; it wasn't really taught to me. Like in 'My Fair Lady,' oh, why can't the English teach their children how to speak? The French they learn their French, the Greek they learn their Greek.

Of course, countries such as France and Spain have "official" linguistic standards academies which are responsible for determining what "grammatically correct" French and Spanish are. Do the English still recognize RP and "the Queen's English" as official, or is that no longer politically correct? At any rate, its not as if Americans would go for it anyway... we can't even apparently settle between MLA, Chicago and AP style guidelines... and then the American Psychiatric Society has their own rules as well. A fat lot of b.s is what it is.

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

BitwiseX (300405) | more than 3 years ago | (#32207992)

Could a native English-speaker kindly explain it to this Ukrainian immigrant?

Sorry dude. I'd help you but I'm American (southern at that).

Re:"a ways" to go? From a veteran editor... (2, Informative)

Kickassthegreat (654117) | more than 3 years ago | (#32208064)

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 [wikipedia.org] , so I understand your confusion.

"too many frameworks" (1)

Aladrin (926209) | more than 3 years ago | (#32207724)

Has the 'too many frameworks' argument every held water? 'Too much choice' is not a problem, especially for a seasoned developer.

Re:"too many frameworks" (1)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#32207938)

"Today, we celebrate the first glorious anniversary of the Information Purification Directives. We have created for the first time in all history, a garden of pure ideology. Where each worker may bloom secure from the pests of contradictory and confusing truths. Our Unification of Thoughts is more powerful a weapon than any fleet or army on earth. We are one people, with one will, one resolve, one cause. Our enemies shall talk themselves to death and we will bury them with their own confusion. We shall prevail!"

Re:"too many frameworks" (3, Interesting)

coryking (104614) | more than 3 years ago | (#32208080)

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 :-)

Re:"too many frameworks" (2, Interesting)

DrgnDancer (137700) | more than 3 years ago | (#32208282)

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

The problem is not the tools... (4, Interesting)

khendron (225184) | more than 3 years ago | (#32207728)

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.

Re:The problem is not the tools... (1)

RJFerret (1279530) | more than 3 years ago | (#32207958)

The problem might have been the client. The second developer might have said, "I'll have to spend X hours to recreate the existing framework and add your new requests."

Client balking at cost, "Could you just add the new features using what's already in existence?"

Developer, leery, "Technically that's possible, but it creates a mish-mosh you'll have problems maintain in the future."

Client, believing the Developer is trying to make more money, "I'd rather just add the new features than rebuild what I already paid for please."

Developer, "Okay, we'll do that then, but don't say I didn't warn you!"

The THIRD developer saw that this was a problem client and did the wise thing, cut his losses, oh I'm sorry, as the summary put it "disappeared".

Now this guy gets part of the story and is stuck with the cleanup. Meanwhile, the site owner never learns that it's cleaner/cheaper/more efficient to do invest a little bit extra up front to ease maintenance down the road--investing in the future almost always pays off.

PS: Any wonder the "client" keeps needing new developers instead of one wanting to continue working with him?

Re:The problem is not the tools... (1)

cowscows (103644) | more than 3 years ago | (#32208056)

Exactly. Badly organized and poorly written code is certainly not exclusive to web development. A truly bad developer can practice his lack of craft in any language, and throw together a poorly designed system for any platform.

Or as your analogy illustrated, while computers allow us to make mistakes more quickly than ever, humanity has been finding new and creative ways to do a crappy job at things for a long time. It's what makes us different from the animals.

His anecdote seems orthogonal to his point... (5, Insightful)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#32207754)

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

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

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

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

Re:His anecdote seems orthogonal to his point... (0)

Anonymous Coward | more than 3 years ago | (#32207908)

Story: I recently saw some crappy C code..yada yada yada..C development has a long way to go.

This guy has seen nothing. Almost all companies have lousy codebases like an explosion took place and then someone tried an implosion to put back everything together. In a Spaghetti restaurant.

Re:His anecdote seems orthogonal to his point... (2, Insightful)

toxonix (1793960) | more than 3 years ago | (#32208036)

You said what I was thinking, without all the expletives. Thank you sir. I should have stopped reading at the title '... still has a ways to go'.

Meh (4, Insightful)

SmallFurryCreature (593017) | more than 3 years ago | (#32207962)

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

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

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

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

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

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

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

Re:Meh (0)

Anonymous Coward | more than 3 years ago | (#32208072)

>>> If you are building a house, you don't tell the brick layer to tear the walls down again because you want to try a different look do you?

You havn't met my wife, have you?

Re:Meh (0)

Anonymous Coward | more than 3 years ago | (#32208268)

This probably has to be one of the most insightful posts on development (not just web, actually...some of these same problems happen in application development) that I have ever read. Brought tears to my eyes. Wish I could mod you up myself.

Don't know what he's talking about (2, Funny)

abigsmurf (919188) | more than 3 years ago | (#32208004)

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!

The problem is that their code is bad. (1)

quietwalker (969769) | more than 3 years ago | (#32208026)

I've been around for a while, dealt with a lot of code that had a missing developer, and one thing I noted was this simple truth:

Every significantly complex piece of code you didn't write, every system you didn't design is "bad".

It doesn't matter if it's well formed, makes sense, works well together, you'll always find a way to complain about the coding style used, the design choices made, the libraries used or ignored, and until you've sat in it for a while, none of it will make sense to you. Not sure what I mean? Try spending some time in a few of the programming centric IRC channels, and watch everyone rip into someone else's code. The #python channels are especially funny since the loudest individuals there appear to be some sort of religious adherents in the church of python. In general, these folks won't even answer simple questions until the code is reorganized in the manner they're accustomed to.

The thing is, we're all like that. It's the same each time you pick up a new language, or you're tackling a new library. This isn't a web-based phenomenon - this is every piece of code ever, regardless of it's actual quality of lack thereof.

This is the sort of thing that you can't fix with single-vendor lock-in, or strict adherence to protocols, and it's not exacerbated by mixing and matching OSS projects. Inside a given company, it can be regulated to a point by having architectural guidelines, strict coding conventions, and well spread code reviews that ensure conventions are used - but the code will still be 'bad' to people outside the company.

I do have a fix for it, but I don't think the author will like it. You should make sure that YOU as a developer experience as many of the frameworks and languages and systems and such that are out there, continue to expand your awareness of program design from data structures to lifecycle management, and that way, when you experience one of these 'bad' systems, you'll be able to absorb what the previous developer was thinking a little quicker than otherwise.

of course, it could just be terribly written code, and not just subjectively bad, in which case I always end up voting 'slash 'n' burn'.

Wanting better tools??... (2, Interesting)

Tei (520358) | more than 3 years ago | (#32208058)

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? :-)

"backed by a major vendor " (0)

Anonymous Coward | more than 3 years ago | (#32208116)

Fail. And he was doing so well up to that point. A decent software engineer doesn't need the software equivalent of a drug pusher (IBM, Microsoft).

Commie! (1)

rbrander (73222) | more than 3 years ago | (#32208120)

There's also something to be said for a tightly-controlled economy backed by a government with absolute power. Nobody starves, and all that.

Alas, that situation turns out to be unstable in the long run because it can't cope with an ever-changing, inherently uncontrollable world, the "absolute power" thing corrupts absolutely, and various other defects not visible within the tightly-controlled system, even after they are visible to everybody else.

Long run, it appears that the unplanned, unmanageable, chaotic, unstable, failure-allowing "free" system actually works better. It even let fewer people starve, oddly enough.

Since communism provably killed and tortured more people than Nazism, the rhetorical device is at least as offensive and overblown, so I would now like to claim the fastest implementation of Godwin's Law in Slashdot history!

Smells like corporate propaganda to me (1)

walterbyrd (182728) | more than 3 years ago | (#32208128)

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."

So whatever you do, don't use open standards, open standards screw up everything. Only develop for MSIE, and other "standards" used by major corporations to embrace-extend-extinguish.

And this coming from infoworld? Why do I smell a corporate propaganda thinly veiled as some sort tech commentary?

JS (0)

Anonymous Coward | more than 3 years ago | (#32208140)

The problem is JavaScript. It's the tranny hooker of web development: looks like OOP, wants to be OOP, and you can try to use it like OOP, but once you get her skirt off you want to run from the building screaming.

FUD (0)

Anonymous Coward | more than 3 years ago | (#32208160)

Not pictured: The author's big fat cheque from Adobe

"Neil, we don't care that you don't know much about web dev. Just make up some really bad anecdote and hope it sticks"

Web Development (3, Interesting)

hackus (159037) | more than 3 years ago | (#32208174)

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

Humans can only learn so fast (1)

mangst (978895) | more than 3 years ago | (#32208180)

There are so many web frameworks out there, like the author says. New ones are released and existing ones are updated on a regular basis. The truth is it takes time to learn a framework and become comfortable with it. We can't possibly keep up with it all.

Ask Slashdot: PHP/JS Dev environments (1)

QJimbo (779370) | more than 3 years ago | (#32208304)

Are there actually ANY good development environment for working with PHP and Javascript simultaneously? I use NetBeans but it doesn't really keep track of say, when a javascript function loads data from a php with the xml loader and things like that. I always end up with a strange hybrid of serverside and clientside code that is impossible to sensibly keep track of. Any suggestions?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...