Show HN: A Wiki written in 80 lines of JavaScript(wiki.pageforest.com)
wiki.pageforest.com
Show HN: A Wiki written in 80 lines of JavaScript
http://wiki.pageforest.com/#mckoss-3535
42 comments
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.
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.
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.
Yup, same as any language that has libraries. It's not that surprising.
The point is that you can create similar feats with a similarly small amount of code.
The point is that you can create similar feats with a similarly small amount of code.
+ thousands more lines of JavaScript in the form of libraries.
And let's not forget the millions of lines for the browser and the underlying operating system!
And let's not forget the millions of lines for the browser and the underlying operating system!
My point, is that "80 lines of javascript" is technically incorrect.
There's no point to mention how many lines of code it is, unless it's actually true.
There's no point to mention how many lines of code it is, unless it's actually true.
The point of this share was to show how Pageforest (my project) can be used to create a full web-app with very little code.
Pageforest is still a work in progress, but I'd love to get more feedback on it if you'd like to try building your own apps on the platform.
Pageforest is still a work in progress, but I'd love to get more feedback on it if you'd like to try building your own apps on the platform.
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.
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.
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.
PageForest looks pretty cool. Anyone want to comment about security concerns of the pageforest model, vs traditional web apps?
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.
(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.
You could build a nicer WYSIWYG Wiki interface with one line: contenteditable="on" without any libraries.
Here's my take. WYSIWYG, AJAX, and no libraries in two lines:
Here's my take. WYSIWYG, AJAX, and no libraries in two lines:
<iframe src="#" style="width: 500px; height: 500px"></iframe>
<button>Save</button>
Have you actually tried using ContentEditable in a production system? If so, I think you'd withdraw your comment.
It's hairball.
It's hairball.
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.
http://www.aviary.com/viewfull?fguid=b6286c3c-228d-11e0-81ea...
http://www.aviary.com/viewfull?fguid=b6286c3c-228d-11e0-81ea...
[deleted]
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.
Thanks! I really like this model too.
How is this a wiki? Does it only have the one page?
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.
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.
Update: now supports multiple (sub) pages per "Wiki".
Not a fan of <span>s that I'm supposed to click. If it's a link, make it an <a>, please.
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.
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.
Ahem, accessibility.
Looks like building a wiki is becoming the modern "hello world!"
Well, I sincerely hope no "hello world!" ever needs to pull libraries.
#include <stdio.h>Get off my lawn! In my day, we coded straight in hex, because we couldn't trust assemblers to properly align instructions on the drum memory!
-mel
-mel
In fairness, that's just including the function prototypes. You don't need to explicitly link in libc most of the time.
But it's being implicitly linked in, so what's your point?
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.
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.
http://www.joe-bowers.com/static/mirror/thisHackWasNotProper...