Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

At the end of the day every dynamic web application does the same thing: concatenate and send back strings.


Sure, let's go down that road. At the end of the day every software that runs does the same thing: flip bits back and forth.


From 1996 to 2005 dynamic web applications concatenated and sent back strings. After that we started sending back strings and concatenating. Sadly half the web hasn't caught on to the "new" way.


> Sadly half the web hasn't caught on to the "new" way.

  s/Sadly/Gladly/
There's something gloriously simple and effective about the page-is-a-page metaphor. Solid, unambiguous URLs that do what they say on the tin. It's not the "old" way, it's the native way.


There is nothing glorious about clicking a button then watching the screen flash and slowly reload eventually revealing a tiny change. Simple I'll give you. Effective, yes, if the user can suspend reality and pretend the state change happened instantly.

How about a URL that unambiguously specifies the state of all parts of the page? Paste that in a browser and it pulls up the page with all its dynamic parts set as before.


That's an absurd example. Why did you assume that I am arguing the extreme case? All I'm saying is that the page-is-a-page metaphor is legitimate, efficient and comprehensible. It should not be dismissed simply because some over-engineered client side framework looks cool.

Obviously "tiny" changes can be performed with client side code without breaking the page-is-a-page metaphor. Look at Facebook -- a good example of an extremely mature application where the page-is-a-page metaphor remains fully intact.

And of course not all websites fit the metaphor, in which case you obviously should not use it.


Indeed it is absurd that we have known how to refresh part of a page for a decade now and yet half the internet still refreshes the whole page. I'd say this has to do with developers still relying upon server side frameworks they learned years ago.

This has nothing to do with looking cool. Your server generated dynamic full page can look great. Didn't you see Steve Jobs's Dodge site? This has to do with user experience, in particular performance. The problem with Steve's site is that a slight change in search criteria resulted in a two second full page refresh. It made me want to shop for a Ford.

Sure their are cases where full page refresh is fine. Shopping isn't one of them. Reading a news story that spans 10 pages isn't one of them. Most of what I use the internet for isn't one of them.

And then there are web applications. Without partial page refresh these feel like shopping for a Dodge in 1996.


There is nothing glorious about clicking a button only to have nothing at all happen because a fragile dependency system is broken, making the entire site less usable.

I use Ghostery to block a lot of tracking JS. This includes things like FB stuff. The number of sites that break because a call to "FB.init" throws an exception is astonishing.

It's ridiculous how quickly people (by which I mean developers) have forgotten the concepts of graceful degradation and progressive enhancement.

There are very few use cases where a web application simply cannot function without javascript.


not every application/use case needs or benefits from dependency on XHR and JavaScript




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: