> > 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.
[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.
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.
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.
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).
so far in building LaunchKit with skit (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...
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.