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.
Thread beginning with comment 377891
To read all comments associated with this story, please click here.
Sorry, don't agree
by google_ninja on Mon 10th Aug 2009 13:18 UTC
google_ninja
Member since:
2006-02-05

I'm a bit tired of people trash talking the web as a platform. It did suck to develop for 3 wildly different browsers 10-15 years ago, especially since we didn't have things like firebug.

Nowadays that pain is virtually non-existent, especially compared to what it used to be. Javascript is an absolutely wonderful language, and CSS + semantic html is (in my mind) a much more elegant UI development experience then anything else I have run across. Given the choice between client side or web development, I will choose web every time, not for any other reason then I enjoy working with the technology.

Now, there while there are A LOT of people who think like me, you may know a large group of them, they are called google. The most important company on the net is 100% behind web technologies, is not trying to reinvent the wheel or displace them with new protocols, and is choosing web technologies over client apps in its upcoming client os. The leader in people who don't agree with me (adobe with flash), is ALSO now choosing to push web technologies on to the desktop with AIR, which uses html/javascript/css. The palm pre, which is the only one to come close to being an iPhone killer, also is choosing html over other choices for its SDK.

I don't think the web is ripe for disruption, in fact I think the opposite is true. Way back when java applets were used, they were only used because people had no other option. As soon as they had an option, there was a mass exodus to flash. With web technologies not only is that not happening, but given a choice, people would rather use them for things other then websites over the alternatives.

Reply Score: 8

RE: Sorry, don't agree
by FunkyELF on Mon 10th Aug 2009 15:32 in reply to "Sorry, don't agree"
FunkyELF Member since:
2006-07-26

Given the choice between client side or web development, I will choose web every time, not for any other reason then I enjoy working with the technology.


I will choose client every time. Creating a client side app that dynamically creates tabs is easy. Creating rounded buttons is easy.

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.

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.

Don't get me started on layouts.

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.

If you dissect a native app you may find complications as well. You could say every click needs to travel round trip through layers of APIs down to the kernel and system interrupts back up to the userspace program. The thing is though, that this is transparent to the user as well as the developer. Maybe the web just needs better tools to make development nicer. GWT looked pretty good from the beginning and is looking even better with the changes that Google Wave needed. Maybe GWT or other technologies like it are the answer. Haven't read about SproutCore since it came out...not sure if it is similar to GWT or not.

Reply Parent Score: 5

RE[2]: Sorry, don't agree
by google_ninja on Mon 10th Aug 2009 18:34 in reply to "RE: Sorry, don't agree"
google_ninja Member since:
2006-02-05

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

RE[2]: Sorry, don't agree
by snowbender on Mon 10th Aug 2009 22:49 in reply to "RE: Sorry, don't agree"
snowbender Member since:
2006-05-04

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.


This is simply BS. You don't need roundtrip for showing tabs and layout. And you also don't need AJAX for that. You can use AJAX to dynamically update a page. That means you load a small amount of data from the server and add that dynamically in your page. That is cheaper than web1.0 roundtrip and reloading the page.

You don't need roundtrip at all for showing tabs. You can do that with Javascript, playing with the DOM and CSS. And using a javascript library such as Dojo will give you a set of predefined components that makes it really easy to show tabs on your page, and to have buttons with rounded corners.

Don't be mistaken. I am definitely not of the opinion that every client application has to become a web application. I do think that the big power of web applications is related to deployment. Deployment or roll-out of web applications is much much easier and cheaper than for desktop client applications in for example a big company with hundreds of desktop computers.

In any case, your post shows that you are not really familiar with the technology used in web applications.

Reply Parent Score: 3

RE[2]: Sorry, don't agree
by ddc_ on Tue 11th Aug 2009 06:22 in reply to "RE: Sorry, don't agree"
ddc_ Member since:
2006-12-05

While I also believe the web apps to be too complicated for now, I canĀ“t really get Your point. Why the hell should I bother with some special sort of buttons style? The thing user needs most is the coherence, so if all sort of buttons and font (except for generic serif/sans/monospace/symbol) customisations migrate from CSS/whatever_on_server_side to browser/whatever_server_independent, this will be the gretest day in webdev history.
P.S.: Same for client-side-only apps actually.

Reply Parent Score: 1