Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future of Web Apps - Single Page Applications

happyworm.com

Post reply on HN
Print view View original

51–60 of 65 posts

Re: The Future of Web Apps - Single Page Applications

#51

Post by revetkn »

kls wrote: post #24
revetkn wrote: post #18

GWT's been around for years now - I wish more people were aware of it and just how powerful it is :(

I think server frameworks like GWT and Echo take the wrong tack, they favor the developer to the detriment of the designer. I think the JavaScript toolkits have it right by separating the concern of the UI away from the back end and placing it squarely in the hands of the designer and UX developer. It is a different discipline and given the historic nature of web development, server toolkits either favored the develo…

I mentioned GWT because the linked blog post discusses some of the first baby steps toward the idea of building a real single-page client-side app, whereas GWT has been doing some real heavy lifting in that space for a long time...I'm a little disappointed that the post received so many upvotes, since it seems like using the URL hash to preserve state on-page should be common knowledge for any web developer.

I agree that GWT is not friendly to UI people who are used to writing their own markup. But I would argue that a good UX person should be concerned with how the user interacts with the application (not necessarily by writing HTML and CSS by hand, but by sketching out the design on paper or Illustrator), and a framework like GWT often makes it simple to build complex UIs that would be difficult/labor-intensive to create and maintain with a traditional web dev stack. A decent developer should be capable of taking mockups from a designer and building out the rounded corners and other pretty bits himself in CSS.

Re: The Future of Web Apps - Single Page Applications

#52

Post by asnyder »

scott_s wrote: post #48
asnyder wrote: post #26

Earlier quoted context omitted.

Thanks for the feedback. We do have that huge header that says "Build for the Web Faster & Easier!", thus we would hope you immediately conclude it's web based. For most of those points above, the keywords are actually links to more information for each of those points. Line 3 in particular is meant to emphasize that you can deploy across all browsers and operating systems, this is in fact not what every web page doe…

It's way too much. Complete overload. And, unfortunately, as the parent poster mentioned, despite there being a wall o' text, there's not much actual information. You should be able to answer this simple question: where do you want my eyes to go first? Right now, there's a few different headlines and buttons competing for my attention. When that happens, I often don't bother figuring out where I should look and give…

It's very interesting. We use to have much more technically minded copy, but that wasn't as effective. Interestingly enough the points that were criticized are in fact some of the actual core tenets of NOLOH, it's not buzz, those are it's most attractive features.

Clearly, what's happening here is that the skeptical reader is dismissing them, and certainly not clicking to get more information when more information is available.

We'll definitely try to strike a fair balance in the updates ahead.

Re: The Future of Web Apps - Single Page Applications

#53

Post by scott_s »

asnyder wrote: post #52
scott_s wrote: post #48

Earlier quoted context omitted.

It's way too much. Complete overload. And, unfortunately, as the parent poster mentioned, despite there being a wall o' text, there's not much actual information. You should be able to answer this simple question: where do you want my eyes to go first? Right now, there's a few different headlines and buttons competing for my attention. When that happens, I often don't bother figuring out where I should look and give…

It's very interesting. We use to have much more technically minded copy, but that wasn't as effective. Interestingly enough the points that were criticized are in fact some of the actual core tenets of NOLOH, it's not buzz, those are it's most attractive features. Clearly, what's happening here is that the skeptical reader is dismissing them, and certainly not clicking to get more information when more information is…

I'm not necessarily arguing for more technical copy. I'm certainly arguing for less copy. That means what copy you have must convey more information.

Imagine you came into a restaurant and asked, "What's today's special?" And the waiter replied, "It's the best meal you'll ever have. You will be sated. You'll experience savory tastes, with a hint of sweet and salt. This meal will solve all of your hunger problems."

"Yeah, but what is it?"

"Oh, it's steak."

Give us the meat, then sell us on it. Don't try to sell it before you tell us what it is.

Re: The Future of Web Apps - Single Page Applications

#54

Post by geebee »

This was an interesting article, and I'm still digesting it.

Right now, I still tend to favor page based web applications with some client side code (Ajax, probably jQuery).

Sorry to punt to someone else's words here, but I think DHH summed it up pretty well, so I'll just give a link and a quote:

http://bigthink.com/ideas/21596

Question: The trend now is towards client-side applications, but Rails deals primarily with server code. Does Rails need to evolve to keep up?

David Hansson: So Rails have actually been interested in the client side for a long time. When AJAX sort of first got its initial push, when it got its acronym, back in, I think, 2006, Rails was one of the first server-side frameworks that said, "This is going to be huge and we're going to do something about that." So we put a Java script library straight in the Rails distribution prototype and we built a bunch of helpers around that to make it easier to create AJAX applications with Rails. And today it's almost inconceivable that you'll build a new, modern web application that doesn't have some aspect of AJAX in it.

Now, some people go a lot further than just having some aspects of AJAX in it. Some people have their entire application in Java script and just use the back end as a data store for that. I don't find that development experience that pleasurable. I have come to tolerate Java script now that there are great libraries and frameworks like Prototype around it to sort of make it a little more pleasurable, but it's still no Ruby. Ruby is still my first love in terms of programming languages. And however much you paint up Java script, it's not going to beat that. Which is fine.

So, from the development side of things, I don't enjoy Java script programming nearly as much or in the same league as I enjoy Ruby programming. Okay, fine. On the client side of things, like is this better for the user? I think there's something special and appealing to me about the mix, the mix of how the web is discreet pages and you use hyperlinks to jump from place to place and AJAX is sort of sprinkled across to make certain common operations a little faster. I tend not to like very heavy, single-screen-based web applications. They can be fine for some things, but I think the Web has this unique category of applications that fit into that sort of middle ground between one screen, or mainly one-screen applications and static web pages. And that's an awesome sweet spot and I think it works incredibly well for a wide array of applications. And I wouldn't want them to be any different. There are certainly some people developing for the web who long for the days of the desktop application and finally see that now AJAX is bringing that back. Well, we've heard that story a lot of times. First it was Java that was going to do this, applets were going to bring back the desktop experience and we could get rid of this nasty HTML. Then it was Flash that would bring this forward. And now AJAX or anything else like that. There's been so many attempts to bring the desktop to the web, and none of them have succeeded in becoming the dominant approach to building web applications, and I think there's a good reason for that, because that's not what users want. Like that sweet spot in the middle is great and it's actually desirable on its own terms.

For now, I'm pretty happy in that middle ground as well... though it will be interesting to see where this goes next.

Re: The Future of Web Apps - Single Page Applications

#55

Post by kls »

revetkn wrote: post #51
kls wrote: post #24

Earlier quoted context omitted.

I think server frameworks like GWT and Echo take the wrong tack, they favor the developer to the detriment of the designer. I think the JavaScript toolkits have it right by separating the concern of the UI away from the back end and placing it squarely in the hands of the designer and UX developer. It is a different discipline and given the historic nature of web development, server toolkits either favored the develo…

I mentioned GWT because the linked blog post discusses some of the first baby steps toward the idea of building a real single-page client-side app, whereas GWT has been doing some real heavy lifting in that space for a long time...I'm a little disappointed that the post received so many upvotes, since it seems like using the URL hash to preserve state on-page should be common knowledge for any web developer. I agree…

just to be clear, this is all relative? Lets face it, in the world of creativity and development, there is no right and wrong. I have seen some beautiful applications developed in VB, a technology I despise, I am also continual impressed with what the PHP guys produce, despite the fact that I personally loath working in PHP. So in that context GWT is not right for me, and I find that it is not right for a lot of other development houses, because they are focused on design centric concerns as much as development centric. Yes, you can find a master of both worlds, but many times you can find a wonderful designer who's logic escapes him, and we have all seen the horrors of a programmer designing interfaces. It has been my experience that it is easier to find masters of one and mediocrity of both. So for me, and my development efforts separation of concerns is the right thing. For others GWT may be the right selection. I just wanted to be clear in my statement, I am not telling anyone what is right for them, I am telling them what is right for me and the developers I work with.

Re: The Future of Web Apps - Single Page Applications

#56

Post by kls »

maushu wrote: post #40
kls wrote: post #16

Earlier quoted context omitted.

It's actually simpler than that now days, you simple set up a server with a headless web browser on it and route all old-browser and crawlers to that box. They get the same functionality but with-in a page post model. There are a few architectural adherence but for the most part it works pretty well.

I always wondered about this, how does Google prevent this type of behavior? Like serving specific content to search engines and show other content to users... do they check using camouflaged bots?

It is not a matter of preventing it, Google is the one that actually conceived of and is promoting this approach.

Re: The Future of Web Apps - Single Page Applications

#57

Post by kls »

kls wrote: post #46
hellweaver666 wrote: post #41

Earlier quoted context omitted.

In your post you say: >> create a cart in the session (bad, bad, bad) Sorry to be a total n00b, but why is it bad to keep the cart in a session? What do you suggest as an alternative?

Server side session is a outcrop of the idea that the client is dumb philosophy, as such, the server has to "approximate" the client, this leads to many counter intuitive patterns like session. By far the worst evil is the fact that you have no guaranteed destructor because you have an approximation. So if the client wanders off, you have no way to clean up based on that event other than a brute force timeout. Furthe…

Sorry for replying to my own post but I did want to touch a little further on this subject. above I stated:

So if the client wanders off, you have no way to clean up based on that event other than a brute force timeout.

A common rebuttal to this is well just sprinkle in an AJAX call. Which in my opinion is the worst decision one can make. Now not only are you supporting a server model but you also have client mode sprinkled in which compounds the complexity of you application significantly, in essence doubling your technology stack. This is the choice a lot of developers make when trying to dabble in RIA and it is my held belief that this is a fatal mistake. It doubles the required skill set and creates convolution in the sequences of application communication.

Re: The Future of Web Apps - Single Page Applications

#58

Post by [deleted] »

maushu wrote: post #40
kls wrote: post #16

Earlier quoted context omitted.

It's actually simpler than that now days, you simple set up a server with a headless web browser on it and route all old-browser and crawlers to that box. They get the same functionality but with-in a page post model. There are a few architectural adherence but for the most part it works pretty well.

I always wondered about this, how does Google prevent this type of behavior? Like serving specific content to search engines and show other content to users... do they check using camouflaged bots?

[deleted]

Re: The Future of Web Apps - Single Page Applications

#59

Post by revetkn »

kls wrote: post #55
revetkn wrote: post #51

Earlier quoted context omitted.

I mentioned GWT because the linked blog post discusses some of the first baby steps toward the idea of building a real single-page client-side app, whereas GWT has been doing some real heavy lifting in that space for a long time...I'm a little disappointed that the post received so many upvotes, since it seems like using the URL hash to preserve state on-page should be common knowledge for any web developer. I agree…

just to be clear, this is all relative? Lets face it, in the world of creativity and development, there is no right and wrong. I have seen some beautiful applications developed in VB, a technology I despise, I am also continual impressed with what the PHP guys produce, despite the fact that I personally loath working in PHP. So in that context GWT is not right for me, and I find that it is not right for a lot of othe…

It's certainly relative :)

Everyone has their preferred toolsets and frameworks and of course they should use what they feel is most effective. Case in point: my shop uses very little GWT - my coworkers prefer different tools (and often so do I; GWT is overkill IMHO unless you're building something big).

But this is all not really relevant to my point:

I was talking more about how the linked-to blog post was kind of web-development-101 stuff that everyone already knows and somehow, sadly, still received many upvotes/comments. I only brought GWT into the mix because some guy wrote a blog post about listening for URL hash changes and is presenting it as the future of web development, while (using GWT as an example) people with PhDs have written an optimizing Java to Javascript compiler and engineered very good solutions to difficult client-side web development problems that completely trivialize something as basic as hash change history tokens.

Re: The Future of Web Apps - Single Page Applications

#60

Post by xiongchiamiov »

scott_s wrote: post #53
asnyder wrote: post #52

Earlier quoted context omitted.

It's very interesting. We use to have much more technically minded copy, but that wasn't as effective. Interestingly enough the points that were criticized are in fact some of the actual core tenets of NOLOH, it's not buzz, those are it's most attractive features. Clearly, what's happening here is that the skeptical reader is dismissing them, and certainly not clicking to get more information when more information is…

I'm not necessarily arguing for more technical copy. I'm certainly arguing for less copy. That means what copy you have must convey more information. Imagine you came into a restaurant and asked, "What's today's special?" And the waiter replied, "It's the best meal you'll ever have. You will be sated. You'll experience savory tastes, with a hint of sweet and salt. This meal will solve all of your hunger problems." "Y…

And by god, please don't use a screencast as the primary way of telling us what the meat is. Don't even consider it.
Post reply on HN