Skit author here. We've been using skit internally to build LaunchKit (<a href="https://launchkit.io/" rel="nofollow">https://launchkit.io/</a>) for the past 4-6 months.<p>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).<p>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.<p>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.<p>So far it's been fun, and honestly it's worked far better than I expected it to when I started tinkering.<p>Would love any feedback / etc., here or on twitter @taylorhughes
First impression is this is way more straightforward than other frameworks.<p>First criticism, this:<p>events.listen(dom.get('.thing'), 'click', function() {<p>That is a longer way of saying<p>$('.thing').on('click', function(){<p>Which could really just be:<p>on.click('.thing', function(){<p>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.
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.<p>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.<p>That way I don't end up using <a href="http://octo-labs.github.io/snowflake/" rel="nofollow">http://octo-labs.github.io/snowflake/</a> for every JS project.
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.<p>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.
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.<p>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!
"Eventually, this webpage got so complicated and unwieldy that I started avoiding making changes to it."<p>Skipped unit testing didn't you? Uncle Bob Martin would be upset with you.<p>Without tests, someday you'll be afraid to change Skit as well.