

Common misconceptions in web application development - arthurk
http://www.techfounder.net/2008/07/20/common-misconceptions-in-web-application-development/

======
sh1mmer
I think he makes some really good points.

However I, personally, would add one more.

#6 You can't be a ninja at both front and backend

Following on from 2. if you focus on the skills to do the backend you are
never going to learn or keep up to the date with all the intricacies of
browsers quirks. Vice versa if you spend all your time dealing with browser
quirks you may not pick the best architecture.

It's not that we aren't capable of doing either, it's more that you can't be
amazing at both at once.

------
ibsulon
While I agree in principle that #1 is correct - that OOP is not necessarily
less performant than procedural languages, the argument provided is a bit of a
strawman. No OOP-antagonist that I know would consider that a proper argument.

The arguments that I see are this:

1\. Encapsulation makes code less performant because large, overdesigned
objects are created to pass around information rather than designing the code
to the data. Consider sending XML around (SOA) rather than a pointer to a
struct, for example, because of proper encapsulation.

2\. Inheritance tends to be poorly used in OOP, causing poor performance
without gaining many rewards in maintainability except for an ideological
category system. This ties into complaints about polymorphism and inversion of
control systems and the words "bloated piece of shit Spring" come to mind. :)

3\. OOP encourages architecture astronauts due to the ideological supports.
Further, it hides poor algorithmic decisions because it separates a processing
function into multiple files and functions.

------
edw519
Excellent post! Sometimes you just gotta say those things that _should_ go
without saying.

 _1\. OO code is less performant than procedural code_

Never forget, the primary purpose of OO is to help _us_ , not our users. OO is
a great way to get junior people thinking a certain way, set standards, and
make maintainability a little more manageable (usually). The only thing it
really does for our users and customers is help us help them by making our
lives a little easier.

 _2\. The backend is the most important part of development_

Sometimes I think we get this backward. Think about it. You can do almost
anything you want on the back end and no one notices unless there's a problem.
The client side is a whole different story. It has to work perfectly no matter
what browser or resolution your user arrives with, and it has to do it using a
limited number of technologies, a small footprint, and with limited round
trips to the server. It's almost like it's 1965 all over again.

 _3\. Graphical designers are good at user interface design_

UI design != UI function. It doesn't matter how pretty it is if the user can't
figure out what to do or if it doesn't _function_ as expected.

 _4\. The existence of a superior programming language_

Yea, some languages are better than others for certain things, but a expert
practitioner of a seemingly inferior technology is almost always better than
an average practitioner of a superior technology. To this very day, my mother
can still _print_ faster than any of us kids can _write_. Amazing.

 _5\. XML is more economic than a DB_

XML serves its purpose of being autodocumenting quite well. That's all it does
well. If you need to parse for any reason, almost any other format blows it
away.

~~~
boucher
"UI design != UI function"

I would say, UI design != Graphic Design. UI design is inseparable from UI
function. They are one and the same. Design isn't how something looks.

It shouldn't be confused with graphic design though, which is really how
something looks. Graphic design is purely in the realm of the aesthetic.

~~~
oz
"Graphic design is purely in the realm of the aesthetic."

This is not strictly true. For example, when designing for print, a good
designer pays strict attention to information architecture and type
readability and legibility (which are two different thing). These things are
both form and function.

But then, as I think Donald Norman says, "Beautiful things work better..."

------
stranter
#7 - Data driven web apps (who doesn't have one these days?) can do a million
things (probably an understatement) but the key is to do a few things really
well.

Write down the features you want (what you want your app to do) and then cut
it in half - than cut it in half again - than identify the three hardest
features left and cut one of those - and than you probably have a lightweight
app that will get off the ground so you can work to stay off the ground.

------
vegashacker
This site treats XML as a database. Well, it uses the s-expression (XML's slim
cousin) instead, but still.

------
andreshb
UI design != UI function - I have had to explain that way too many times.
Interface Design = Interaction Design + Visual Design + Information
Architecture

------
gm
I love the last one: XML is not a database, so don't treat is as one... Major
pet peeve for me...

~~~
newt0311
A related pet peeve of mine: treating the DB as a dumb object store. Its
not!!! Thats what file systems are for.

