> Hopefully in the future when I've built out the features that I have planned it will offer a compelling reason to allow this access!
This attitude is what I want to see in our community period. Android/Git/whatever.. tell me WHY I should give you access, without assuming your intent is implicitly good.
When you sent me this last night, I lost a few minutes getting my head around what it was best used for. Now I can't stop thinking about it as a pointer to the future of JS lib loading.
+ 1 star: Identifies inefficiencies in the sea of endless loaders & metaframeworks
+ 1 star: Zero-configuration network-based lib loading
+ 1 star: Clean presentation & clear thinking about the problem
+ 1 star: Tests!
+ 1 star: Brilliant name
This is sort of the boat I'm in now. I've been writing side-project widgets, and just putting them on my blog with commentary. I toyed around with Sourceforge over a decade ago, but just never latched onto it as a platform for publishing code.
Recently I've been doing work on Github (same handle there as my HN handle, but I won't link to it here), and had to learn git. I don't test the same way traditional developers (whatever that means) do, so Karma, node, and the rest aren't high on my to-do list.
Git and Github weren't hard to learn (in fact the hardest part was to learn what's idiomatic of a Github project), and I'm happily growing my project.
I think in some ways I might be your target audience, however I don't immediately see the benefit of using this as an add-on to my project rather than the testing suite, et al.
And were you thinking of changing the name? Or at least the logo? I think you're seriously asking for trouble from "the man" if you take a commercial logo and try to use it this way.
So let's say you're working on something and you're looking for a library that will help you out with canvas animations.
You find a GitHub project, or a package on bower, and you get the code on to your local system somehow. You then have to wire it up in to your existing code somehow. Even if you just start with a new project to try out the API or something, you still have to do a decent amount of system management to get the thing working.
Personally, I've been developing using JUST CorsLIT and the editing all code in-browser and doing the deploys using fully front-end sites like Neocities, JunoJS, and JSFiddle. My personal favorite is Neocities. :)
As per the name, well, the actual product is lit, and CorsLIT is a site built on top of the lit API. I plan on retiring the CorsLIT site and developing the second generation site on top of the data and functionality offered by the core of the product. Hopefully the next version can stand on it's own two feet and won't require the song-and-dance to get some attention. :)
The CorsLIT name itself was chosen for nothing more than being a funny marketing ploy! I would absolutely love it if it caused enough of a stir to warrant some very expensive lawyers sending me a letter!
I'm also a genuine fan of shitty American light beers.
I think I understand how this could be useful (and, if I do, I'll love it), but I don't understand:
(i) Where do I start, where do I download/install this lit thing. Do I also need RequireJS?
(ii) lit calls fo reusing existing code isn't intended for production use, so I have to manually copy the code from corslit.com/user/module to my codebase, or is it?
(iii) If I'm going to use this lit to reuse existing code various times in one page, I must call it various times and do everything inside its various callbacks?
(iv) Why can't we see a directory with all the code shared via lit? Do I need a specific url for each project?
(v) Is this for javascript code only? Why stop here?
Yeah, you do need RequireJS. I've been considering a build of lit that comes with RequireJS bundled up within in. There are future plans to remove the RequireJS requirements completely, but for now it works and I'd rather not rewrite a bunch of functionality! Seriously, most of the really heavy-lifting for the client-side system of dependencies was incredibly easy due to building on top of the RequireJS plugin architecture. Take a look at the source on GitHub: https://github.com/williamcotton/lit/blob/master/src/lit.js
Again, not super elegant, and I'd love feedback on a better approach!
It is also on bower! bower install lit
(ii)
The feature has not been released yet but lit will be great for production use allowing for static, versioned builds to be compiled for either direct linking or downloading. Also, because it is built in to RequireJS it will be able to compile with r.js. I'm also thinking of looking in to a browserify source transform. It may in fact work out of the box with https://github.com/jaredhanson/deamdify but I haven't looked in to this just yet!
(iii)
Every time you want to use a lit module you'll have to wrap it up in the loader in a manner similar to RequireJS. I've been wrapping all of my code in a single call to lit. It depends on your development style!
(iv)
There is a really rudimentary API for getting all of a users published modules but it is so crappy I don't feel like sharing it yet, haha.
(v)
Support for CoffeeScript and other languages that compile to JS is something I would love to explore depending on how many people seem to want it! I guess we'll just have to see.
I was think about this being the final solution of my reusable code problem. I can't even describe how bright my eyes became: modularizing all my code and saving everything at somewhere in the internet (not in any of the three computers I use alternately), reusing quickly and easily.
So I thought: why not doing this with my Python micro-code-features too? If this is possible with javascript, why not with Python? (In fact, you -- and RequireJS -- use eval, don't you?) Tell me, you who are far more experienced than me: is there any problem with trying to make a lit-inspired Python module repository?
I'm not familiar enough with Python to be able to make a reliable statement on the matter.
However, I would imagine that it would work fine for any language that has:
1.) The ability to eval strings as code.
2.) The ability to serialize functions or methods to strings.
3.) The ability to get and post to a web service.
As far as I can tell Python has all of these features.
Now, for a really far out idea... there is possibly a way to take functions or methods from one language and convert them to functions or methods in another language in a similar way to how C++ and other languages are compiled to JS, on top of LLVM and Emscripten.
That way, instead of having competing module repositories for each language, code can be freely shared between not only different machines but different execution environments.
I'm sure there are many caveats as I haven't explored this idea thoroughly.
I'm talking to Piotr at JSFiddle about adding lit to the drop down list on his site and one of the requirements is a single-file build, so I'll be doing that ASAP!
However, I still don't know what exactly is this tool supposed to do :(
Care to explain a bit more? (Just for the record: I know bower, npm, requirejs etc.)
I was about to reply exactly the same way. I'm well aware of the pain of trying to 'prettily' share things you've created (all the configs, etc for very little code), but I'm not really getting what this is doing to resolve that? The demonstration video actually confused me more than the lead up textual explanation.
Which is by no means saying I don't like the idea. I agree it's a problem, but how are you solving it?
I'm thinking I might need to move a lot of elements from that article to the front-page of CorsLIT!
If you did read the follow-up article, I apologize for not being able to present a clear explanation of how lit attempts to solve the problems presented in the original article!
I'm also realizing that I should make a longer form screencast, say about 5 minutes in length, that shows how I use lit on a daily basis to build applications while sharing as much modular code as I can, with as little friction as possible!
The article I didn't really see (actually I saw the link but thought it goes back to the introductionary article, didn't read properly enough).
I got now a better understanding at what you're trying to solve. What I didn't quite get yet is: How is this supposed to help regarding bower/npm json files? Or am I on the wrong track here?
Dude, no worries, I've realized I didn't do the best job of presenting the information or highlighting that link. You were not alone in your confusion, haha.
My ultimate goal is to not have to use server-side tools for managing front-end dependencies.
I would like to leave bower and npm out of it completely. Making node or any other full language stack a dependency for front-end development is the wrong way to go about it, in my opinion.
There's just too much friction between filesystems and the browser.
Sorry for not replying, I never keep up with my comments on here. I did see the article, and that helped a bit. Again, not trying to bash it -- seems like a great idea, and I'll definitely be keeping an eye on it.
I too didn't really understand what Lit/CorsLIT is supposed to do, but your writing and awesome marketing did get me excited. Definitely interested in a longer article or screencast!
Can someone explain me the pun in name lit and cors? I'm not american and I didn't understand a thing (ok, I got the beer name, but this doesn't bring me anywhere).
Great way to present this!