Linked by mufasa on Mon 10th Aug 2009 12:25 UTC
Web 2.0 The web browser has been the dominant thin client, now rich client, for almost two decades, but can it compete with a new thin client that makes better technical choices and avoids the glacial standards process? I don't think so, as the current web technology stack of HTML/Javascript/Flash has accumulated so many bad decisions over the years that it's ripe for a clean sheet redesign to wipe it out.
Permalink for comment 377932
To read all comments associated with this story, please click here.
RE[2]: Sorry, don't agree
by google_ninja on Mon 10th Aug 2009 18:34 UTC in reply to "RE: Sorry, don't agree"
Member since:

I'll admit, a lot of this has to do with taste. My point still is that the majority of people are not going to jump ship the second an alternative is available.

On the web, you can dynamically create tabs on the server side with PHP / Python / CGI / whatever. But then you need to use CSS somehow to have the currently selected tab appear highlighted. If each entry in your menu has its own CSS class you now need to dynamically generate CSS. What a pain. Alternatively you could use Javascript to make it appear highlighted. Now you're using three different technologies all loosley bound together. [/p]

Most frameworks have ways to easily generate a page fragment instead of a full page. An example in rails would be "partials" with a "link_to_remote" helper, which instead of generating a link that will reload the page, creates a link that will do an ajax call.

The css for highlighted tabs is simple. Tabs will be in an unordered list. You need 3 css definitions; ul.tabs li, ul.tabs li:hover, and ul.tabs The first is for inactive tabs, and has no class on the items themselves. The second uses the hover psudoclass, and will automatically apply itself when the mouse is over the tab. The third is the active style, that can be applied in your onclick handler with the line "this.class = 'active'".

it actually takes more typing to describe the code then to write it out.

[q]Now, go and create a nice rounded button. You need all sorts of CSS hacks to do that. You need 5 different image files. Go change the color of it and you need to split it up again.

In css3, border-radius is defined. Works for the latest version of everything except IE, which will ignore it.

Changing the color of a tab requires changing a single value on a single line. If its a gradient, you will need a new image. gradient is a part of CSS3, but webkit is the only browser implementing it at the moment.

Don't get me started on layouts.

I actually find layouts far simpler in html then with layoutmanagers in client apps, and require a lot less coding.

Web sites that try to act like native apps with tabs and layouts all get over complicated. Every click needs to travel roundtrip and to make it appear that it isn't you use AJAX to further complicate things.

AJAX is insanely simple nowadays. In rails, for a form to submit asynchronously you just use the form_remote_tag helper instead of the regular form_tag. As I said be before, link_to_remote is also available. Both of these are about as hard as making the actual form or link tags normally.

The biggest problem I find people have programming for the web is that they spend an hour looking at it, assume it is easy and that they get it, and then get frustrated when they hit a wall. My stand-by interview questions for web related jobs are "Explain prototypical inheritance in javascript" and "Explain the difference between block elements and inline elements" or "How would you write a selector for all p tags inside a div with an id of "paragraphs"". These are very basic questions, and if you cannot answer them it means that you didn't know how to write web applications. It is downright shocking to see how many people can't answer them, especially the one on javascript inheritance. These are the people that then turn around and write mountains of awful code, or long blog posts about how much html and javascript suck.

Reply Parent Score: 2