

Show HN: A Wiki written in 80 lines of JavaScript - mckoss
http://wiki.pageforest.com/#mckoss-3535

======
technomancy
80 lines, huh? I guess that's cool.

    
    
        #!/usr/bin/ruby -rcgi
        H,B=%w'HomePage w7.cgi?n=%s';c=CGI.new'html4';n,d=c['n']!=''?c['n']:H,c['d'];t=`xx
        cat #{n}`;d!=''&&`echo #{t=CGI.escapeHTML(d)} >#{n}`;c.instance_eval{out{h1{n}+
        a(B%H){H}+pre{t.gsub(/([A-Z]\w+){2}/){a(B%$&){$&}}}+form("get"){textarea('d'){t
        }+hidden('n',n)+submit}}}
    

[http://www.joe-
bowers.com/static/mirror/thisHackWasNotProper...](http://www.joe-
bowers.com/static/mirror/thisHackWasNotProperlyPlanned.html#b)

~~~
somebear
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.

~~~
jrockway
_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.

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

~~~
moe
_\+ 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!

~~~
axod
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.

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

~~~
jchrisa
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>

~~~
mckoss
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.

~~~
TheIronYuppie
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.

~~~
jchrisa
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.

------
antimatter15
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:

    
    
        <iframe src="javascript:unescape('%3Cbody%20contentEditable%3E')" style="width: 500px; height: 500px"></iframe>
        <button onclick="var x=new XMLHttpRequest;x.open('POST','/update',1);x.setRequestHeader('Content-type','application/x-www-form-urlencoded');x.send(frames[0].innerHTML)">Save</button>
    

On JSBin: <http://jsbin.com/ebiju3> (don't try saving, there's no server part
here!)

~~~
jasonkester
Have you actually tried using ContentEditable in a production system? If so, I
think you'd withdraw your comment.

It's hairball.

------
mckoss
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-1231390ec091)

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

~~~
mckoss
Thanks! I really like this model too.

------
Raphael
How is this a wiki? Does it only have the one page?

~~~
mckoss
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.

------
jrockway
Not a fan of <span>s that I'm supposed to click. If it's a link, make it an
<a>, please.

~~~
alanh
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.

~~~
jrockway
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.

------
jhrobert
Looks like building a wiki is becoming the modern "hello world!"

~~~
simonsarris
Well, I sincerely hope no "hello world!" ever needs to pull libraries.

~~~
joshwa

      #include <stdio.h>

~~~
chc
In fairness, that's just including the function prototypes. You don't need to
explicitly link in libc most of the time.

~~~
jrockway
But it's being implicitly linked in, so what's your point?

~~~
chc
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.

