Skit author here. We've been using skit internally to build LaunchKit (https://launchkit.io/) for the past 4-6 months.

We have skit sitting on launchkit.io, with a REST API in Django sitting behind it (serving prelaunch native mobile clients from api.launchkit.io).

Logged-in requests that load data hit the API first from node, using the same JS API client that runs in the browser. The logged-in user cookie is actually an encrypted OAuth token from the backend API, so our website is actually a first-class API client just like our mobile apps. No separate session logic, etc.

I prerender the first results in the "reviews" list using a template on the server, then when you scroll down the list the additional items are loaded and rendered with the same template in the browser. It seems weird/foreign but in practice it's not that weird.

So far it's been fun, and honestly it's worked far better than I expected it to when I started tinkering.

Would love any feedback / etc., here or on twitter @taylorhughes

Haven't played with the framework at all yet, but I have to say that was the best announcement for a framework I think I've ever read. Totally subverted my knee-jerk oh no not ANOTHER one reaction I've come to expect...

Agree. It was great subversive announcement and marketing. All of our objections were encapsulated (horrible, terrible, oh no) and lightly dispatched. It was very skill full writing. Also the comments on this thread really work.

You should remove 'sudo' and '--global' from 'sudo npm install skit --global' in your getting started guide. I almost had a heart attack when I first saw it.

http://stackoverflow.com/questions/19352976/npm-modules-wont...

Otherwise, it looks very promising!

will do :)

For the routing, this seems like the traditional server-side routing where you have a 1 to 1 relationship between a page and a URL (as opposed to a relationship between an URL and a state). If that premise is correct, does this mean Skit would have difficulty doing things like deep linking?

Assuming that all webpage resources are now dealt with intelligently by the framework itself, can I inline all js and css and possibly image files using just the logic on the framework's end? for mobile clients?

That isn't built, but it's within the realm of possibility here. Other things I've thought about are some kind of automatic spriting, serving browser-targeted JS to remove compatibility layers, etc.

(Also serving all the CSS/JS on the page itself would be fairly easy with the way skit works — the other stuff I mentioned is farther flung.)

Very cool. I'm not really the target audience for this, but if you could make it work in TypeScript, I might actually try programming in JavaScript (well, TypeScript) again.

Is it used in Cluster?

Yep, the logged-in web app is skit. The logged-out homepage etc. is not, because we launched Cluster before skit existed and there's too much random stuff to move over at the moment.

First impression is this is way more straightforward than other frameworks.

First criticism, this:

events.listen(dom.get('.thing'), 'click', function() {

That is a longer way of saying

$('.thing').on('click', function(){

Which could really just be:

on.click('.thing', function(){

As in, make the most common things more concise. Your current way isn't bad at all; it's just longer than it needs to be. Could be reorganized, I think.

Yeah, all this stuff in skit is my personal preference .. as you can tell from the post, I am not big on brevity. Agree that this stuff could be more elegant, though.

I prefer the more verbose, approach. Less magic = less errors. Don't let people show you some snippet that is "less characters = must be better"mentality

I don't think that's the argument. In English, the words "yes" and "no" are very short. Why? Because they're used often. They're not particularly hard to screw up. They're quick to say and quick to write. Similarly, it's good if a framework can use, sure, brevity, in its more common function calls.

Similarly, in jQuery, the most common function call is one character that's obvious if you mess up. You don't have to go to such extremes as `$`, but you should think about that sort of thing when you're designing APIs, imo.

Skit literally means "Shit" in swedish.

Skit literally means skit in English.

Is skit the parent of the terms shit and scat? Linguistics are so interdasting to me.

Skitbra.

And stepping on shit brings good fortune in many different cultures :)

+1000

It does :)

I definitely get where this is coming from - I've been using gulp+browserify+watchify+react+express+mongoose lately, and even though I really do like all of the tools individually just wiring all of the different bits and pieces together feels like a chore and is very error-prone.

I think there's a lot of space in the frontend arena for a convention-over-configuration frontend framework that ties in ES6 & jsx transforms, jshint, css bundling, sourcemap generation, and production bundling & minification in a nice way with sane defaults and strong conventions.

That way I don't end up using http://octo-labs.github.io/snowflake/ for every JS project.

Is the absolutely horrific scrolling experience (retina MBP, Chrome) I get on the Snowflake page part of the joke?

ember(-cli) does a good job (sans jsx)

Seems like an interesting medium between Meteor/Derby.js and just a front-end framework; however it doesn't provide the same tracking of models. So it's more of a hand-off, but at least it prevents having to duplicate logic.

At the same time, I feel like this could have been done with just a plugin to some existing framework instead of creating just another. But that's just because I am losing track of everything that is out there.

There's still space for something like Meteor that instead of templates uses virtual-dom.

You can use virtual-dom diffing in Meteor. https://github.com/reactjs/react-meteor

You can just not use Meteor's built-in templating. I use Mithril instead (great combination, by the way).

Rendr (Airbnb) is a Backbone plugin/library to make this sort of thing work for them. (They are no longer working on it, AFAICT.) Otherwise there's not too much out there sitting in between the client/server boundary.

I tend to think it's because this stuff gets too complicated in a hurry, so you kind of need a more structured framework around it. But who knows.

I used Rendr at a past gig, for how little community there was around it I was always shocked at how well it worked. It was not at all a correct fit for what we were using it for, but it was still resilient and forged on!

I can completely agree though that it gets far too complicated far too fast, and doesn't easily solve the problems it is written to solve.

Ah forgot about Rendr, it is kind of the intermediary step as well. Either way, awesome work :)

I was hoping for an actual skit, parodying the Yet Another JavaScript Framework phenomenon.

Just want to chime in as another dev who's tinkered in the isomorphic area: great work, and I completely agree this area is still way too complicated. A modern framework should support this out-of-the-box IMHO.

FWIW your framework makes me think of a modern backbone.js. I'll try and find some time to take it for a spin sometime soon. Good luck with it!

Great simple concept. This + react is how all frameworks need to think.

I wonder what the first two letters of YACC stand for.

I am so sorry to not to be the last one to say this; Skit == "Poop" in Swedish.

I bet it's awesome though.

"Eventually, this webpage got so complicated and unwieldy that I started avoiding making changes to it."

Skipped unit testing didn't you? Uncle Bob Martin would be upset with you.

Without tests, someday you'll be afraid to change Skit as well.

Hi, are there any tests for Skit? How have you been testing it?

I haven't automated my testing process enough yet, and I feel terrible about it. Going to prioritize this now that the project is public. For shame, I know.

I'm skit developer #1. And it's awesome.

this framework just looks like so much fun!