IF OP had removed all whitespace and used since letter variables he could have squeezed the javascript down to almost nothing too. Personally, I think it's a bigger achievement to write something that other people can look at and actually understand what is going on.
I think it's a bigger achievement to write something that other people can look at and actually understand what is going on.
Then you probably wouldn't title your article, "in XXX lines of code". But the author of this particular author did, so it's assumed that he considers this to be a big achievement. technomancy merely points out that this is not really an amazing achievement.
Hate to nitpick, but blatant linkbait headline. It's not 80 lines of JavaScript. It's 80 lines of javascript + thousands more lines of JavaScript in the form of libraries.
Point taken. Some of the libraries are like the air we breath (e.g., jQuery) - I even forgot to mention it on the link page.
My point was with 80 lines of "purpose built" code - you can create a functioning wiki. But we do stand on the shoulders of giants - I hope I gave proper attribution.
It's a great concept. Question - why not just use CouchDB? We've been doing similar app platform stuff with it for years. Check out this wiki that is hosted directly out of CouchDB, with no other server side component: http://couchapp.org
I must admit that I'm not very familiar with CouchDB. From what I have read think there are a lot of similarities - and with the same goal of building complete web apps using only client-side JavaScript.
Pageforest has a focus on building a multi-tenant application hub. I think of it as kind of
distributed Google Docs infrastructure:
- Users' data is stored in a unified document store that is owned by the user. They can
view and manage all their "documents" created from applications from one place.
- They can use their Pageforest account to grant permissions to each application they
want to use to write into their document store.
BTW - Pageforest is currently hosted as a Google AppEngine app - so it picks up the scalability
benefits of BigTable with a datacenter managed by Google.
I'm surprised to see a suggestion of CouchDB - with the deep integration of BigTable with App Engine, I think it'd be unnecessarily hard to use anything else.
PageForest uses App Engine to provide a key value storage API with user authentication. CouchDB has these out-of-the-box, so a CouchDB version should be much less code than this version. Not to mention all the things Couch supports that would be a major challenge to implement within App Engine.
Er, well CouchDB is kind of a different animal and is very far from supporting the kind of development workflow he's doing. CouchApp is very, very cool but very different and saying that things like this have been done is kind of pointless - web apps have been written in _everything_.
I get ya - sorta. I do think we are running headlong into NoSQL 2.0, where everyone ends up writing very similar but incompatible HTTP accessible key/value stores. Seems like a waste to plow energy into writing web-based key value stores when there are already plenty of good ones.
Pageforest is a pretty thin wrapper on top of a AppEngine's BigTable implementation. It does have to add things like a user accounts, user permissions, and caching layer.
The client library (JavaScript) is also design to make it very easy to write "single-page" web apps. You basically just need to write a setDoc() and getDoc() function to persist your document as a JSON blob in storage.
etherpad was awesome! Difference here is that the app lives client-side - and uses a "generic" server implementation for user authentication, storage, and push notifications.
As the author, I can tell you how we've designed it (I'd welcome any other critique - it's all open source too, so you can look under the covers).
(1) Users sign in on the www.pageforest.com domain only. Applications are not given access to a users's credentials.
(2) Users must specifically grant access to each application for an app to write data on
their behalf.
(3) We create an app-specific authentication token in the app sub-domain you are signed in to.
(4) To protect against cross-side request forgery (CSRF), we require the REFERER to be from the application domain (and NOT from the /docs sub-directory) for authenticated requests.
(5) Our authentication cookies are HTTP-Only. This makes is impossible for injected javascript to
access the authentication cookie.
(6) Our app-based authentication cookies expire in 24 hours. Users can get a new cookie by re-authorizing the app from www.pageforest.com.
(7) We don't require ssl use for sign-in. This is probably our biggest security hole. But apps can be used on an SSL domain at https://appid.pageforest.appspot.com.
(8) We never transmit a user's password over the web - we use a challenge/response protocol that hashes the username/password on the client, and only sends the SHA1 of the user's response to a challenge.
I should add that since your application's assets are publicly viewable, there is no way for your app to store a secret key. Also, all your source code is visible to anyone wanting to look at it. This may preclude those that want to keep their code a trade secret.
One benefit of having this based on AppEngine is that Google auto-scales the servers. While I normally have just one server active, Google has stood up 7 front-ends now to handle the Hacker News traffic.
I love the idea of developing in the cloud with only js and a db api. The option to "view page source" makes each js app kind of "open" and more trustable. Thanks for sharing pageforest.
Good catch - the app is one page for now ... but you can embed links from one wiki page to another.
I'm planning to extend this app (no longer just 80 lines), so it supports multiple pages PER WIKI. This will use the "Blob" storage feature of Pageforest. Each document has a top level JSON object intrinsic to it - but can have any number of child Blobs stored beneath it.
I'll also have to extend Showdown to enable auto-linking via CamelCase references.
Assuming you are actually referring to buttons or JavaScript triggers instead of honest hypertext references, it doesn’t matter a lick what element you’re using, as long as CSS styles apply `cursor: pointer;` to it (and possibly consider ensuring it has a tab index). I don’t see why you need to make needless criticisms.
Because random spans don't get hinted, and to click the link, I have to actually reach for my mouse. a and form elements are clickable. Everything else is just plain text.
In this case, the "edit" link looks exactly like a link (inline element with underlining and a different color when you hover over it), but it's a span instead. Why invent your own tags when they already exist? All you do is break things for people that aren't you. Follow the standards and everything will work for everyone. Make up your own, and you can only ensure that what you test works.
The point is that it's already included unless you specifically exclude it. If we take "pull" as a volitional action rather than a passive allowance, then we don't need to "pull" any libraries.
I'm really just playing devil's advocate here (which is why I prefaced it with "To be fair…"). From the considerable amount of hate (rather than calm dismissal) the comment seemed to be getting, I felt that people weren't bothering to think it through. joshwa's response seemed to indicate that "#include <stdio.h>" was pulling in a library, which is at least as wrong.
