Best Programming Practices For Web Developers

An anonymous reader writes "Web pages have become a major functional component of the daily lives of millions of people. Web developers are in a position to make that part of everyone's lives better. Why not try using traditional computer programming and best practices of software engineering?"

Re:More than one side to this one...

[TLLOTS]

I think you're making the same mistake that the numerous anti-Flash zealots make, and that is assuming that bad use of a tool equals a bad tool. Technologies like Flash and AJAX and all the other technologies surrounding and supporting them can add a great deal of value to a website, but only if done correctly.

Of course with the bar being set so low for getting started in website development it's no surprise that we see the horrible messes that we do today.

Productivity vs. The Right Thing

[Max Romantschuk]

Most web developers I know (myself included) have a fair idea of how to do things well. But most web development is project-driven, and once the page/site/app looks and works OK telling management that you need an extra week to refactor things isn't necessarily feasible.

That being said, we all know what happens to maintainability of a big project if done the fastest way possible...

Damned if you do, damned if you don't.

Re:More than one side to this one...

[All_One_Mind]

I disagree. I do web programming everyday, 8 to 14 hours a day. I do understand your point, but there's a time and place for everything, including client side scripting. There's a ton of stuff that can't be done on the server side, and the DOM is a wonderful thing to work with if you don't go overboard.

For example, I've written a few web applications per client spec that required various effects, animation, windowing, and tab features. These are all things which are better left to Javascript, and in my preference, the jquery [jquery.com] and interface [eyecon.ro] libraries. In fact, there's no real way to accomplish most of those effects without client side scripting. Hell, even Slashdot uses Javascript in their comment system, Firehose, etc. Or look at Google Apps, GMail, YouTube. Not even possible without client side scripting. A well programmed client side script (like anything Google's coded) runs great on even a 500MHz Pentium 3.

Anyway, my point is that while I can understand minimizing client side programming, it shouldn't, and can't really be avoided completely. I personally love mixing client and server side programming to draw out the strengths in both methods. Just because the idiots at Digg can't program, doesn't mean the whole thing should be thrown out.

Theres only one programming practice :

[unity100]

1 - Do whatever your client wants you to do.

there is no 2. thats that. your client is your software development customer if you are self-employed or working as a lead developer in a software house, and your client is your superior if you are a programmer employee.

each and any other practice are only valid when you are doing your own personal projects.

Re:Productivity vs. The Right Thing

[Opportunist]

Actually, worse than that. You have it designed, created, streamlined and finished, all the while management tells you during reviews it's fine and exactly what they want, then, as soon as it's done, they want it upside down and inside out, and you get a few hours to basically rewrite it all because "It's all allready there, how much work could it be to do the few adjustments?"

And this is where it starts to get ugly.

Re:"Good practice" is an outdated concept

[Pike65]

Lemme guess - you're a contractor.

Unfortunately someone has to maintain your crappy code, and from my experience contractors all seem to be well aware that it isn't going to be them. We've stopped hiring contractors now, because frankly I'm tired of cleaning up other people's shit.

As to my advice:

- have a proper data layer (we codegen it using Entityspaces [entityspaces.net])
- have a proper business layer (we codegen most of that too with Codesmith)
- it's a database, not a spreadsheet
- XHTML will make your life easier

Re:More than one side to this one...

[Opportunist]

Good in theory. In practice, you'll run into managers who get all psyched out at the idea of dumping the workload onto the clients, because they have to pay for the servers and if the servers don't have to do the work, they can handle more clients, while you don't have to pay for the clients, the customer does that.

It's not a new idea to shift the workload to the customer. The internet did it in banking (you're your own teller in online banking), shopping (you're basically your own bookstore clerk at Amazon, doing all the work from searching, ordering and with the review system it extends even to explaining and recommending), why should it be different on the technical side?

Yes, those pages tend to stink, for the reasons you outlined perfectly. But that's not what is actually wanted by the ones who decide to create those pages. You, as the developer and the user of the page, suffer from it. As a dev, you know it's crap but that's how it is to be done (and of course, despite the client having to render and calculate it, you have to find some crafty way to obfuscate the code so nobody can steal it, making the overhead even worse). As the user, you have to suffer from insane loading and rendering times.

But we save 100 bucks on the server!

Re:More than one side to this one...

[astrotek]

The rules for a web programmer should be

1) DO NOT REINVENT THE BROWSER
2) DO NOT HINDER THE BROWSER
3) DO NOT TRUST THE USER

Re:Theres only one programming practice :

[Anonymous Coward]

1 - Do whatever your client wants you to do.

there is no 2. thats that. your client is your software development customer if you are self-employed or working as a lead developer in a software house, and your client is your superior if you are a programmer employee.

each and any other practice are only valid when you are doing your own personal projects.

Clients often have only a limited idea of what problems are connected with a certain development approach. Letting a totally clueless client micromanage the way you implement a solution is a recipe for disaster. In the end it is your role as a developer/engineer to criticize what the client wants you to do and if necessary point out better and more efficient ways of accomplishing it than the methods your client has in mind. In the end you are going to have to put this project on your CV, so a failed project that results in a bad product isn't just your client's problem it is also your problem because to some extent it reflects on your competence as a developer. Personally I'd rather bail from a project that I can see is going really badly than to stay with it to the end and have to explain why it crashed and burned when I get asked about it on my next job interview.

I am pretty confident..

[daydr3am3r]

..that a vast majority of all we see on what's out there and instantly disregard as bad practices, are the result of pressure from marketing, management, corporate interests, politics, whatever you may call it, applied to a skillful and knowledgeable handful of people that had the mischance of being skilled at their craft, but powerless to make a stand on what is best and more efficient for the actual code and most probably, for the actual target audience. Of course that applies to any product, commercial or otherwise, being created by the ones who have the expertise but controlled by the ones who are considered managerial staff and probably know next to nothing about the product in question. Can you make it great? Perhaps you can. Do you have sufficient time/permission/resources to do that? Well then, that's probably not up to you now, is it?

Well, it does make me wonder, though

[Moraelin]

Well, you bring an insightful point into how that goes downhill, but that's exactly what makes me wonder.

Engineering used to be about starting from a problem and figuring out the best solution. Well, best within the limits of your knowledge and abilities.

E.g., let's say you have to get people from A to B across a river. You'd start from that problem and figure out a solution, and not from "but I wanna build a cantilever bridge, 'cause it's the latest buzzword" and find a river in the middle of nowhere. Or dig a canal if you don't have a river for your buzzword bridge.

Then you'd look at the exact data your problem is based on. How wide is that river? What kind of traffic you expect over it? Is there barge traffic on the river that you'd have to deal with?

Then you'd look at the alternatives: do you need a bridge? Maybe a ferry is enough? How about a tunnel under it? If you decided on a bridge, should it be cantilever, suspension, or what? There is no free meal. Each option has its own advantages, but, and here's the important part, also its disadvantages and limitations.

And I think that's exactly what's missing in most of "software engineering" today. People start from what's the latest buzzword, and then work backwards to try to find some problem (even imaginary) to apply it to. They'll build a bridge in the middle of nowhere, in the style of 19'th century follies, just because they want a cantilever truss bridge, everything else be damned.

(Except the 19'th century follies were actually known to be follies, and built as a fucked-up form of social security in times of crisis. The laissez faire doctrine said that it's wrong to (A) just give people unemployment benefits, since supposedly that would have turned everyone into parasites, and/or (B) to use them to build something useful, since that would have competed with private initiative. So they built roads in the middle of a field, towers in the middle of nowhere, etc, instead. Whereas today's programs don't even have that excuse.)

And while it's fun to blame monolythic programs written by monkeys, I'll go and blame the opposite too: people who do basically an overblown cargo-cult design.

(Cargo cults happened on some islands in the Pacific when some supplies were supposedly paradropped to troops fighting there, but instead landed on some local tribe. The aborigines then proceeded to worship the big birds that dropped those, and pray that they come drop some more of that stuff. And when they didn't come back, they sculpted airplanes out of wood, and kept hoping that those'll drop some food and tools.)

People who don't understand what a singleton, or a factory, or a decorator pattern, or a manager pattern are, or when they're used, go ahead and created tons of them just because they got told that that's good programming practice. Everything has to go through layers upon layers of decorators, built by a factory, which is a singleton, registered with a manager, etc. They don't understand what those are or when or why they're used, so they effectively went and sculpted their own useless wooden factory, like the tribes in the Pacific.

So maybe just telling people about some "best practices" isn't everything. Some people _will_ manage to turn any best practice into the worst nightmare. Maybe what's really needed is to remind more people what engineering used to mean.

The same goes for design before implementation. There are places which sanctified the worst caricature of the waterfall model, but again, in a form that actually is worse than no design. Places where you have to spend two years (don't laugh, I know of a team which had to do just that) getting formal specs out of every single user (who hasn't even seen a mock-up yet, and some don't even understand what the techies actually want), then have an architect design an overblown framework that does everything except what the users actually wanted, then get on with the coding, then they have 1 month allocated for tests and debugging at the end

Re:More than one side to this one...

[KiloByte]

learn Python (or Perl if you're feeling feisty) and write something that at least has a chance of being reasonably structured.

Reasonably structured perl? The mind boggles.

In Perl, you can use exactly the same structures as in most other languages, as Perl, just like English, not just borrows constructs from other languages but assaults them in dark alleys to riffle through their syntaxes. You can write near-shell, near-C, near-AWK, near-sed, etc in Perl as much as you like. And unlike Python you can, you know, use indents to mark up the code instead of placating the language's wishes.

The only problem is, Perl allows insanely terse code. One line of Perl can often replace a page of C or five pages of Pascal. This is tempting, and it's easy to get hooked up and produce read-only line-noise. Yet, with a modicum of self-control you can write readable, well-structured Perl code.

Of course, this is just like writing secure code in PHP. It is possible, yet no one practices it...

Misleading question

[suv4x4]

"Why not try using traditional computer programming and best practices of software engineering?".

Did you see the straw man? The question assumes we do NOT follow best practices already, and sends us on the wrong path to doing so, having to explain ourselves.

A quick run down of the article: getting requirements, D.R.Y., refactoring, test-driven development. Why on Earth assume we're new to this. Grab any amateur framework for web dev and see what it's about. Framework people's mantra is all about D.R.Y. and even taking it to inappropriate extremes.

But I do use best practices, and I believe many do. Here's the catch: there's no single set of best practices.

On the server side the task, dev tools, and target platform are quite classical, and hence the best practices are similar to classic development (and it's mostly classic development after all, parallelizable task).

On the client side we have several awfully inadequate standards, with several awfully inadequate clients (browsers) that interpret those standards more subtly or less subtly differently, and all of this runs in a sandbox, streamed through the tiny pipe of our site visitors/service users. It's a brand new challenge, with brand new bottlenecks, and has brand new best practices.

And I'd argue still many people get it right for what I see. If you believe you can do better than what we have, by all means don't just talk, but go on and do it.

Re:Theres only one programming practice :

[rucs_hack]

Nice idea. Unfortunately, clients do not always know what they need. They usually have an idea of what they want, but not how best to achieve it.

If asked about the development process they want, most would say 'fast and cheap'. Bearing in mind that a less than perfect website that is up and gaining revenue is better then a wonderful, fully featured website of d00m that won't be ready for six more months. A good programmer should advise the smallest possible feature set at first, so that can be tested, and decisions made as to the best way to proceed.

Besides, a cheap website can be improved over time, an expensive one that looks nice but doesn't quite do the job (find me a version 1 of anything that did) is costly even if all you do is remove stuff you paid a lot for.

Re:XSLT!

[mcvos]

Xslt takes all the need to program & process display logic out of the server-side code

XSLT should only be used to transform backend XML into different XML or HTML. It should not be used for any kind of logic, processing, etc, because it doesn't perform nearly as well as a real programming language, and becomes very unreadable as soon as you deviate from simply applying templates and doing straightforward transformations.

I program in XSLT every single day, and I use a framework (Apache Cocoon [apache.org]) that is basically designed around XSLT transformations, and the most common problems I see, are caused by people trying to do complex stuff in XSLT. XSLT is really great. Really. But it's no substitute for Java.

Re:More than one side to this one...

[TLLOTS]

That's a rather narrow-minded way to look at it. Far better to gracefully degrade if the user doesn't have Flash than to say "well someone people might not have it, so it's useless!".

Re:Theres only one programming practice :

[simong]

Not true. Take your client's requirement and interpret it in according to standards and best practise. Your client has hired you for your skills so it's your duty to do it properly and make it easy to update in the future if it's you who has to update it or someone else. Anyone can design a web page and far too often it's obvious that anyone has.

Re:Theres only one programming practice :

[someme2]

1 - Do whatever your client wants you to do.

Yes.
Elaboration:

• Define an appropriate granularity of your actions that you expose to the client.
• Ensure that each action block results in something the client wants.
• Do not do whatever your client wants you to do inside of an action block.
• In time & material based projects an action block length may be atomic (client advises you on microscopic action, e.g. client says: Now press return. Now write 10 ?"Hello World").
• In fixed price projects action block lengths can be defined by milestones (possibly with deliverables). Communication during action blocks may be a matter of tactics (e.g. misrepresenting project state as better or worse than in reality if necessary).
• Client triggered course changes during action blocks in fixed price projects result in billable change requests.

Or something to that effect...

Re:More than one side to this one...

[pedestrian crossing]

Far better to gracefully degrade if the user doesn't have Flash than to say "well someone people might not have it, so it's useless!"

By gracefully degrade, do you mean "gracefully" putting up a banner that says "you need Flash to see the rest of this page"? Because that doesn't cut it.

Once Flash enters the picture, it either becomes necessary to have Flash to access the content, or it becomes obvious that Flash was unnecessary in the first place.

Very few designers use Flash to merely "enhance" a page. Flash invariably becomes necessary to access the page's core functionality. The "graceful" degradation usually follows a pretty steep curve (ie. all or nothing).

Re:More than one side to this one...

[Eivind]

That's almost, but just almost, true.

Thing is, serverside can be made to work for everyone, which is a plus. But the flipside is it can be *slow* for everyone, because serverside you often have no other choice than redraw the entire page (which can be expensive sometimes) even for a tiny change.

So, the way we tend to do it is graceful degradation.

If there's something to click on that'll rely only change a small part of a big page (say clicking a link to expand a comment-tree) this is what will happen:

The link is a normal a href= link, fully standards-compliant, should work even in ancient lynx.

We then use a standards-compliant well-documented library, jQuery, to add an onclick-handler to the link. The handler returns false, which supresses normal link-following for browsers with javascript turned on. The benefit is that those with javascript saves a lot of bandwith and time, they'll only load the ~500 bytes for the extra comment, not the ~20kb for the entire page.

The only way someone would be screwed with this solution would be if their browser *did* support javascript (and had it turned on), yet *wasn't* correctly supported by jQuery *AND* doesn't support the relevant standards for javascript. I am not aware of even a single example where this is true, if I became aware of such an example, a single "return true" for that browser would instantly enable all functionality.

Now, if someone has a browser with javascript, and with a faked browser-header so I can't tell it apart from browsers with a working javascript-implementation, and the javascript-interpreter doesn't understand standards-compliant javascript, then they're screwed. (well, they need to disable javascript to get the site to work...) but in that case they've spent rather a lot of energy for getting screwed....

I think this solution is a fair bit better than "only serverside everything" actually. But yeah, it is extra work, because you really offer both alternatives for these functions.

Re:More than one side to this one...

[Planesdragon]

Server does data stuff, browser does monkey see monkey do stuff.

This kind of "you can have any color so long as it's black" thinking is why I had to suffer through a web form user-account system that told me "invalid password" ten times as I tried to guess what their specific rules were.

Make the user's browser guide the data, check the input once, and then send to the server. There, the server checks it AGAIN. That gives you a redundant check in case someone hacks your client-side script, and lets the non-hacker still get the benefit of an intelligent page.

Re:More than one side to this one...

[Skapare]

I can still submit comments to Slashdot with Javascript disabled. Be sure your submission system works that way as well. Javascript can enhance, and should. Lack of Javascript should not disable. It is not required to submit a comment.

As for YouTube ... totally possible without Javascript, Java, or even Flash. True, it would not look so good and would be harder for some people to use. But the way they do it, it's a broken site altogether when these facilities are not usable, and that does not have to be.

There are many sites that do just plain stupid things with otherwise great tools, mostly because they use them the wrong way, or for the wrong purpose. One example is the use of Javascript to replace hyperlinks. That breaks tabs. Instead, the design should include a genuine hyperlink that is intercepted by Javascript if Javascript is enabled. Make sure every "link" on your site works when I press the middle button to open it in a tab.

Calendar Tech

[Doc Ruby]

The most important part of being a Web programmer is knowing how to meet a deadline. Part of which is designing the project schedule, which means designing the product in terms of delivery dates and contingencies. And therefore almost as important is how to notice, and to communicate in advance when a delivery might be late, and by how much.

After learning how to use calendar tech and spoken/email languages for project communication, the rest of the development is relatively easy.

Re:More than one side to this one...

[jefu]

The problem is that the "designers" have often only learned flash, as they consider themselves "designers" and not "programmers" (who should know more than one language, programming techniques, how to debug and ...). They only want to "design" - pick their favorite fonts, make fancy navigation structures that look cool. They usually consider programming a bit icky and "right brain" (or is it "left brain"?) and somehow beneath them. Sadly, for many this attitude is taught to them in college (sometimes even by people in CS programs). Naturally, this is not true of all "designers" and the best either work hard to figure out how to do things well, or realize their limitations and use good programmers to help them.

Re:More than one side to this one...

[Keeper Of Keys]

Completely agree. Yes, unobtrusive srcipting does mean providing the same resource in two different ways, but that needn't be too much of a chore. The backend part is more than just an insurance policy against your javascript failing for some reason: it's the only way the Googlebot will see your content at all - it doesn't run page scripts. I'd say: develop a standard call-and-response website first, then unobtrusively ajaxify the parts where a full page refresh is too costly.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:More than one side to this one...

[Hatta]

I've written a few web applications per client spec that required various effects, animation, windowing, and tab features. These are all things which are better left to Javascript

Per client spec. Just because your client thinks you need those things doesn't mean the users actually do. I understand you got paid to write it that way, but that doesn't mean that's the best way to write it.

Re:Theres only one programming practice :

[grahamd0]

"If I asked people what they wanted, they would have said 'faster horses.' "
-Henry Ford

Ontology Recapitulates Whatever-It-Was

[dwye]

> Why not try using traditional computer programming and best practices of software engineering?

Because every generation has to make the same mistakes as the previous one before learning that just because it is the latest thing, that doesn't mean that you, educated in the latest thing, know what you are doing (until you actually do it for a while).

And then you learn it, everything works, and it seems a new golden age is upon us.

And then a new paradigm will come in, claiming that the only thing to do with (old paradigm) programmers is shoot them, just as we suggested doing to all the old COBOL programmers in our days of stupid youth, and in the meantime, lets skip all the cruft of the previous generation (wonder why everything is breaking, though).

And so on, and so on, and so on.