
Skit: A pure JavaScript front end for building better web clients - nej
http://skitjs.com/
======
benaiah

        > > You seriously made another module loader?
        
        > Yeah. There are several reasons why:
        > To create a new-feeling environment that is clearly not node,
        > because you’re writing code that runs in node and IE9 and Chrome
        > etc. It shouldn’t feel like any old node.js module.
    

Why shouldn't it feel like any old node.js module? Nearly all the work in JS
packaging of late has been to abstract the differences so that we can use the
well-established node packaging system on both ends. We're already able to do
it with stuff like babel and browserify.

~~~
taylorhughes
[skit author here] -- skit handles CSS and multi-file module definitions (with
submodules) in a novel way, that's probably more important to me than the
reason you pasted.

------
vans
Pre-render on server side is the way to go, no more empty html skeletons
taking a while to fulfill after the first request, and you still get the
reactive style of modern web app.

~~~
taylorhughes
❤

------
enahs-sf
given that your handle is nej, i'm assuming you know that skit means literally
"shit" in swedish. men jag tycker den har är en faktiskt bra ide.

~~~
techwizrd
It's mentioned at the bottom of the page and in a Github issue[0]

0:
[https://github.com/clusterinc/skit/issues/4](https://github.com/clusterinc/skit/issues/4)

------
pdkl95
Thank you for actually serving up a proper web page (initial server-side
rendering)!

Using javascript to enhance the page to provide faster loading or other
features is great, but it is important to have at least _something_ on the
page when javascript is not available.

------
amelius
> Featuring nearly 100% shared server and client-side code

If the code can run on the client as well as on the server, does this mean the
client has direct database access?

How well does that work out for the number of required round-trips?

~~~
taylorhughes
the skit frontend abstracts only a few things for server- and client-side
code: http requests, cookies and redirects. so you write a REST API client in
JS and populate the initial page state with it, and when you wake up in the
browser you don't have to make any more requests (until the user does
something).

------
taylorhughes
Wow just saw this was on HN again — I was traveling yesterday. There was a fun
discussion thread a few months ago here:
[https://news.ycombinator.com/item?id=9342133](https://news.ycombinator.com/item?id=9342133)

------
kellysutton
Looks neat. For those looking for this functionality in a more mature
framework, check out Ember FastBoot: [https://github.com/tildeio/ember-cli-
fastboot](https://github.com/tildeio/ember-cli-fastboot)

------
Egregore
How is this framework similar/different with Meteor.js ?

------
DaGardner
this might be cool until you have to debug some weird bug and do not know if
it has to do with client or server code...

~~~
taylorhughes
so far in building LaunchKit with skit
([https://launchkit.io/](https://launchkit.io/)) that hasn't happened. (I was
worried about that, too.) it's surprisingly natural. I find the server-side
parsing/running actually catches a ton of stupid typos (with nice error
messages) quickly before I have to find them in the Chrome developer tools...

------
curiousjorge
Two years ago I would've been excited but now I've developed a filter for
anything with javascript and front end or framework in the same sentence if
they are not backed by a major corporation, simply based on the reason that
there have been so much abandonware in this landscape, I think even for Google
it's been tough sell. I think that React is the way to do it but slow to adopt
it especially because I'm so comfortable with jQuery and never had the need to
invent new ways of doing things.

~~~
taylorhughes
I wrote a post about how ridiculous it was to write another javascript library
(about skit):
[https://news.ycombinator.com/item?id=9342133](https://news.ycombinator.com/item?id=9342133)

