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