Would you build a pure client-side JavaScript App using Pageforest?
pageforest.com
pageforest.com
Off the top of my head the biggest early concern I'd have would be how are you going to handle server side validation, since relying solely on client side validation is pretty much just as good an no validation at all. Especially complex validation involving multiple fields. The next would be interacting with things like third party APIs that have access keys that need to be protected or just can't be accessed from the client (because they don't offer a JSONP interface).
I would say our sweet spot is smaller, document-centric apps (games, puzzles, document editors). Anything that can use a simple document persistence model.
I'm not saying their API is good enough for this, since they just launched, but from a theoretical standpoint I think the concept is sound.
That being said, I agree with andrewjshults that sooner or later you will need to write server side code, even if it is to proxy client side requests to another domain.
mckoss, would it be worth making a server side implementation of your service for http://www.akshell.com - a server side JavaScript platform with syncrhonous I/O and a browser based IDE. We're open sourcing the whole stack, so there would be a lot less lock in than with AppEngine. Drop me a line on our mailing list if you're interested: http://groups.google.com/group/akshell
Relying on the the platform to handle the user authentication and document storage is something I wouldn't be comfortable with, though I'd use it as an option (as facebook connect, google or any other authentication service out there).
In general, I think this would have been a hit 5 years ago. Now, with services like heroku, phpfog, app engine, even github having free plans, the "hosting" part seems to be solved, and something pretty similar can be done these days with some sparkle from FB Connect and a bit of rails/php for the client side storage.
Don't get me wrong, I like this kind of services because [I think] they push innovation in different directions. It's just that I think there are a few pretty well stablished and provide similar (or equivalent) functionality and I just don't see any obvious advantage between this service and the others, though I see a few drawbacks.
There's a lot to learn to build applications that span database/web server/client - so I'm trying to build a "generic" backend, and let the application developer concentrate on the client side only.
Maybe it's really only applicable to "toy" or "prototype" applications. Like this one, for example:
What Services does Pageforest Provide? <snip> Cloud-based Document Storage - Each Pageforest user is given storage for their own document collection in the Cloud. When a user authorizes your application, your App can create and store documents to the user's collection.
They asked for comment and I think they need to be more specific that's all. If they're using the GAE db imho they should say so.
In addition, each document can have as many child "blobs" as you want (each blob is up to 1 MB using any format - can be text, png, json, xml, etc.).
Interestingly, each "App" is very similar to a "Document". E.g., you index.html file is a "blob" in the application.
App writers don't have to worry about authentication - just redirect the user to the www.pageforest.com/sign-in/appid page, and the will redirect back to the app if the user has granted the application permissions to save on their behalf (much like a 3-legged oAuth).
A simple example, I set up a survey app. Several of the questions contain user input in the form of dates or numbers such as, date of birth, number of years living in the united states, years employed, etc. To help weed out bogus answers I want the fields to be validated/filtered. Date fields should be dates, numeric fields should only contain digits. In a traditional client server app I can validate this on the client side before submission in javascript, but I would still need to validate it on the server side as the clients input cannot be trusted. There is no guarantee that the validation code was ever run, that the user didn't modify the code as/before it was executed or that the user didn't simply post bogus data via a script.
Much more importantly, if I'm taking user input and then pushing that data back into the page for other users to see how do I prevent someone from submitting malicious javascript that is then executed by the next users browser when they view the document? The pitch is that my application is 100% client side javascript so it would seem to preclude the vast majority of apps that I can even think of since the users input would need to be processed/validated server side before I would be willing to store it or make it available for others to consume.
For you second example, why the heck would you run javascript eval on the document data? As explained by mckoss, the storage format is JSON, not raw javascript that is executed. This is an important distinction: jQuery and other client libraries contain special commands for handling JSON that exist specifically to resolve the kinds of problems you are describing.
EDIT: It looks like the other reply explains that there is no "trusted agent", so this is clearly a limitation of their system (though not a theoretical limitation, as far as I can tell- No reason they couldn't allow the app creator to log in with pseudo-admin privlidges to do reporting.)
As to the second point: Who said anything about _me_ running a javascript eval on user supplied data.
Go look at their wiki example click edit and in the text box type: <script>alert('boo');</script> then click the hide button.
Notice two things. The first is that when you type the last > on the ending script tag the included script executes and you get the alert popup. When you reload the page you'll still see the alert('boo'); in the wiki display (in <code> tags) but the <script> tag is still live in the page as there's either no or very limited output sanitization. In a typical client/server application this is hopefully going to be sanitized or eliminated prior to ever being stored. The storage format is irrelevant if the data being stored is spit right back out into the page as in the wiki example.
But that is indeed a good argument in your favor, ktsmith.
As client-side JavaScript gets more mature, I do expect there to be more frameworks that will just "do the right thing" for developers who write code like this.
BTW, can you explain why you can't do page rendering in JavaScript for accessibility? Is there reason screen readers can deal with dynamically generated HTML?
This is going to be less of a problem for some companies than others, I just happen to be working on software that's designed to help HR departments with their hiring process and specifically with the accurate completion of certain federal forms. Getting complaints about violating the ADA could lead to lawsuits against my employer or our clients. Similar to the complaints that Google is receiving about accessibility problems in Google Apps and specifically gmail.
Here's a pretty good survey that has some more information if you are interested in the topic: http://webaim.org/projects/screenreadersurvey2/
I would love to find some tools, like a Chrome extension, that could display an accessibility score for a web page and provide guidance on solving problems. For those of us not using screen readers, it's easy to overlook errors without realizing it.
http://webaim.org/projects/screenreadersurvey3/
There's a few addons for firefox that focus on section 508 compliance but many of them are poorly maintained. You might want to look into this one, which I have not used myself however.
http://wiki.pageforest.com/#pageforest-api/storage
Simpler apps will save their state in a document created for the user (up to 1 MB). But you can do more using the "Blob" storage interface.
This is exactly how a web app should be created- All the apps I've been creating lately are 95% client-side javascript and 5% of annoying server code that could obviously have been implemented using a generic REST-based data store.
I will be using pageforest extensively (Assuming it's not buggy, etc :-) Hats off to you guys for being first to market on this!
Seriously, thanks for giving it a try - I'd love to get your feedback on problems you have using the platform...
Friday night networking! :-)