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

41–50 of 65 posts

Re: The Future of Web Apps - Single Page Applications

#41

Post by hellweaver666 »

kls wrote: post #20
adriand wrote: post #11

I think this makes sense in a couple of situations. First, for stuff that is fairly simple and where not having page loads is highly desirable, such as a music playing app like his example. Second, for stuff that is complex but you have a team of engineers and computer scientists as well as a suite of tools that make dealing with that complexity much more manageable, as in Gmail. In most other situations though, wher…

It is really not more complex and done right it is significantly simpler. If you roll your own toolkit it is a pain, but if you utilize a framework like Dojo, it is far easier than Java(JSP, Struts, JSF, et al.) or ASP.NET or even PHP. Without the contortions of pumping everything to the server and then getting a response and trying to figure out that context, you get a far less fragmented memory model. For example l…

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?

Re: The Future of Web Apps - Single Page Applications

#42

Post by mhansen »

hellweaver666 wrote: post #41
kls wrote: post #20

Earlier quoted context omitted.

It is really not more complex and done right it is significantly simpler. If you roll your own toolkit it is a pain, but if you utilize a framework like Dojo, it is far easier than Java(JSP, Struts, JSF, et al.) or ASP.NET or even PHP. Without the contortions of pumping everything to the server and then getting a response and trying to figure out that context, you get a far less fragmented memory model. For example l…

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?

He suggests keeping the cart clientside in (e.g.) a javascript array.

Re: The Future of Web Apps - Single Page Applications

#43

Post by thasmin »

asnyder wrote: post #21
thasmin wrote: post #17

Earlier quoted context omitted.

NOLOH's tutorials are hard to find on that web site.

I'm sorry it was difficult for you to find the necessary resources. On the home there's a link to a series of around 20 YouTube videos, a developer zone with 30 extensive articles, a full and in-sync API reference, and a growing Demo section. You can also sign-up for a free hosted sandbox where you can get started right away, without the need to download or host anything yourself. If you would be so kind, could you p…

Even when I was looking around, I could see that there were a lot of resources. I'd like to see a very short app - 50 lines of code - that shows off the main feature of the framework. More importantly, I need this to be one of the links on the top of the page if it's not on the home page.

Re: The Future of Web Apps - Single Page Applications

#44

Post by kls »

lapusta wrote: post #27
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…

GWT is not a server framework.

Last I checked you write Java, and it generates the UI and the services. It is a server framework because the same tool is responsible for the development server side and the client side, it is an evolution from stuts or JSF, but in the end you are developing the UI from a backend developers perspective. I know that it generates client side code and that it uses the familiar JS client model. But it is still designed for the comfort of the backend developer. Quit honestly GWT et. al. further alienate the designer in favor of the developer.

Re: The Future of Web Apps - Single Page Applications

#45

Post by kls »

mattmanser wrote: post #39
kls wrote: post #20

Earlier quoted context omitted.

It is really not more complex and done right it is significantly simpler. If you roll your own toolkit it is a pain, but if you utilize a framework like Dojo, it is far easier than Java(JSP, Struts, JSF, et al.) or ASP.NET or even PHP. Without the contortions of pumping everything to the server and then getting a response and trying to figure out that context, you get a far less fragmented memory model. For example l…

The techniques you're describing aren't benefits of your system. They're just modern web programming techniques and certainly don't need to be used in a single page programming model. For example the majority of what you're describing as benefits has been known to anyone using MVC for a while, MVC is available in any of the languages you mentioned as your system being easier than.

MVC was conceived to account for the limitations of a view oriented development philosophy. MVC is far from modern as it is not an evented model. Modern are platforms like Node.js and the RIA toolkits who eschew MVC in favor of an evented and message oriented architecture.

http://www.appcelerant.com/mvc_is_dead.html

http://apsblog.burtongroup.com/2007/11/mvc-matrix-and-.html

http://broadcast.oreilly.com/2008/10/mvc-as-anti-pattern.htm...

http://www.sitepoint.com/blogs/2005/12/22/mvc-and-web-apps-o...

Re: The Future of Web Apps - Single Page Applications

#46

Post by kls »

hellweaver666 wrote: post #41
kls wrote: post #20

Earlier quoted context omitted.

It is really not more complex and done right it is significantly simpler. If you roll your own toolkit it is a pain, but if you utilize a framework like Dojo, it is far easier than Java(JSP, Struts, JSF, et al.) or ASP.NET or even PHP. Without the contortions of pumping everything to the server and then getting a response and trying to figure out that context, you get a far less fragmented memory model. For example l…

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. Further session by nature has no way of self governance. For example, I cannot wire an object in session to be cleaned by an observer once an action happen, so a natural byproduct of this is that you get "junk" in the session that all live processes that have reference to it have terminated thereby leaving a zombie.

Re: The Future of Web Apps - Single Page Applications

#47

Post by kls »

simonw wrote: post #38
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.

That's simple? Do you know of any sites that actually do that?

Here is the Google page on the subject:

http://code.google.com/web/ajaxcrawling/docs/faq.html

All of the apps I am currently working on do not have a SEO or old browser requirement, but I have used this technique in the past.

Re: The Future of Web Apps - Single Page Applications

#48

Post by scott_s »

asnyder wrote: post #26
jmtulloss wrote: post #25

Earlier quoted context omitted.

When I clicked on the link, I almost clicked off before seeing what language this was even targeted at. The first point is "Develop in a single, object-oriented language." That's just buzz. Line 2: "Stop worrying about HTML, JavaScript, AJAX, and Comet." More buzz. Everybody says I can stop worrying about these things, but I still don't believe you. Is it web based? Line 3: "Deploy seamlessly across all browsers and…

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 up.

I think you have the attitude that someone is already interested in what you've done. If that's true, then more information is better. You need to come at this from the perspective that most people won't care what you've done. You need to convince them you did something cool. Make sure that after five seconds of being on your site, they know what you think is most important.

Re: The Future of Web Apps - Single Page Applications

#49

Post by sqrt17 »

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…

Well, nowadays you can encrypt and sign sessions and store the signed/encrypted data on your client side (or non-encrypted cookies if you want them to be modifiable from the client side). As long as it's more difficult to fake session data than to buy working credit card numbers, you're fine (at least once you've taken care of XSS attacks, which I take to be no less of a problem in a single-page site).

Wow. Did I just point out that cookies have legitimate and valid uses? My self from 10 years ago would run after me with a shovel and yell that cookies are evil. (Incidentally, the opinion of my self from 10 years ago about Javascript would be exactly the same).

Re: The Future of Web Apps - Single Page Applications

#50

Post by asnyder »

prodigal_erik wrote: post #36
asnyder wrote: post #34

Earlier quoted context omitted.

You're basing your assumptions on a broken premise. You're clearly not browsing normally, but rather are crippling your browser in some way, after which you decide to bash whatever you can, without clearly identifying your methods. As I mentioned earlier it's at the developer's discretion as to whether they want to enable JS degradation or not. Sometimes when an application is sufficiently complex a developer may cho…

Firefox 3.6.8 on Vista Home Premium x64 without js on. That's all. If I were in the market for a web framework, I would not take it on faith that I could rely upon interoperability features the site claims but does not demonstrate. And I wouldn't write the demo myself unless I had already ruled out your competitors. If you decide to drop it, I have no doubt you can still find a large potential market of developers ei…

There we go, without js, which you didn't identify at first. Rather, you just started to list things that seems like they weren't working.

The best way to determine if something lives up to its claims is to try it. You can't look at sites done in NOLOH and then expect them to have implemented or turned on every feature.

Furthermore, it's amazing that when our competitors 280north, or Sproutcore, or whatever else is "cool" posts something nobody complains that you HAVE to have js. No degradation options, no text-based browsers. Nobody complains that their sites aren't in their tool, or that they have significantly less resources than we do.

As soon as we post something there's usually somebody that steers the conversation to a different topic and then criticizes us for one reason or another. In this case you successfully diverted the conversation from "single page" websites into a conversation on js degradation, which in the case of NOLOH is really irrelevant to most users.

Search engines get a different version from the js, non-js versions, thus the non-js version is only for humans that specifically decide to turn off their js. Could it be better, yes, will it be better, yes, can we mandate it, no.

Post reply on HN