2.0

[adamjgrant]

Continued from here

To see progress on 2.0, fork the repo and switch to the "2.0" branch or view the files here

[adamjgrant]

It's hard to give an ETA or even a featureset at this point, because we're still at the philosophical stage of asking ourselves what Kickstrap 2 (K2) is supposed to be. But here's where my head is:

• "Easy for beginners, powerful for experts"
  -- The parts should work together so intuitively, beginners are drawn to it, yet in such a loosely-coupled, hackable way, experts love it even more.
• No install/config
  -- While you should be able to use advanced build tools like r.js and installers like volo.js with K2, out-of-the-box it should continue to be ready to go by dropping on any server.
• "Hackathon ready"
  -- While you can use K2 in a robust production environment, the hackathon should be the test scenario for whether or not it has met its goals.
• Better apps
  -- The apps in 1.x are a bit of a novelty and we notice many devs playing with them but ultimately (and wisely) using directly-referenced js or their own framework's bundler.
  -- Currently talking with creators of http://zestjs.org/ and http://requirejs.org on the best way to use apps as AMDs http://en.wikipedia.org/wiki/Asynchronous_module_definition The devs on each of this projects have already spent a lot of time and troubleshooting on this and I'm looking forward to collaborating with them.
  -- The working model for this is that each open source project you use ought to be called as a single unit. Even if the project has multiple css files, js files, and are required to be loaded in a certain order, the project can be referenced by the user as a single word.
  -- Each project or module (what Kickstrap calls an "app") is smart enough to know what it depends on as well.
• Decoupled
  -- I want to improve the user's ability to "drop in" Kickstrap into an existing project. Currently, making a site from scratch works very well, but it's very finicky when introducing into an existing project.
• Honest
  -- In 1.x, we used a clever trick to write JavaScript in CSS by loading it into the markup's style and extracting back into JavaScript. It's a neat trick, but it doesn't offer a performance advantage, much of a UX advantage, and causes this feature to be so tightly coupled it's tricky to customize one's Kickstrap website.
  -- In 2.x, JavaScript will be JavaScript. The file structure will reflect the user's mental model of dividing the site into apps, extras, and themes.

[snoepkast]

Thanks for taking the time to type all that out! Those all sound like nice improvements to me. Below I typed out some thoughts I had while reading. I understand that you have put a lot of thought in this and I haven't (yet) so it could be this is all old news, or even bad suggestions, but in that case I would love to hear the explanation behind the choices and be a little smarter for the future :)

On the easy for beginners, powerful for experts point:
Is it possible to provide settings in an external less/js file? Preferably you want to be able to customize your settings without having to edit kickstrap source, because if you ever want to upgrade and replace your files with new files it would be overwritten.
Also at this point there is no settings file for javascript (which I assume will come with the implementation of the last point) and settings like the app folder are inline :( It would be sweet if we could just set an environment variable to 'development' or 'production' to automatically handle the console/cache import and stuff, thus making it easier, but I don't know if this kind of configuration is technically possible/desirable.

On the decoupled point:
I think it would be easier to drop kickstrap in existing projects if the files were divided based on file type, it's what I ran into with the rails gem, where the assets pipeline expects js to be in 'javascripts' and less/css in 'stylesheets'. Also if kickstrap used such a structure it would be easier to understand where everything is for beginners. But I assume the current structure was no accident, so maybe this is not wise.

On the honest point:
I noticed this little trick while making the ruby gem and it prevented me from easy app configuration using the gem (this is also because of my lack of experience in ruby btw), I agree with you that javascript should just be javascript.

[adamjgrant]

K2 reaaaally needs to get more RoR friendly, so I think I need an advisor on that end (points to you inquisitively?)
I don't use it myself, but I do know that it has a similar appeal as Kickstrap as it automates many common development patterns.

In the 2.0 branch, I have three main folders: lib, dist, proto, and tests. Dist may not appear until you build. Maybe we could work on this in the proto folder?

lib = uncompiled files
dist = compiled, deliverable product
proto = non-functioning prototype of file structure, purely for determining the best way to organize files and folders.
tests = tests

[adamjgrant]

Definitely want to group certain settings under "development" and "production" I'm actually just now starting to get that to work, if you look at the latest on 2.0. It's still buggy though and I'll have to figure out how to get it to "come in" at the right time. That is, some of the code requires values from settings to come in afterward (to override) and other parts require it to come in before (to provide variables) there is probably a workaround for js settings but less will be tricky.

Great idea on making the directories customizable. I think this is a lesson learned in 1.x, by supposedly supporting different frameworks, K2 should acknowledge that they have their own unique directory structures.

[adamjgrant]

https://github.com/ajkochanowicz/Kickstrap/tree/2.0/proto/kickstrap

Maybe settings.less and settings.js should be moved outside the KS folder? The user could then set the directory of Kickstrap relative to the settings file.

[adamjgrant]

https://github.com/ajkochanowicz/Kickstrap/blob/2.0/proto/kickstrap/settings.js

Is this what you mean in terms of custom settings for the directories (there would be more than this, of course).

[snoepkast]

Oh how frustrating I don't have the time to help you develop kickstrap further right now, all I can do right now is play the role of advisor (more than happy to do so btw). At this time I am developing a new (my first) application in rails but I can only work on it in my free time so I'm still at the beginner stage of learning ruby and rails. So far I have been a python/django developer and my day to day work is still in django.

I will continue to work on the kickstrap gem since I will be using that in my project, also I think this is the most developer friendly way to make kickstrap available for rails, so let's focus on the gem for rails.

A thought just popped up in my head: a pip package for django would be awesome as well. But in django it is not possible to add static files through pip packages afaik (never seen such a package at least) but it could provide some template tags/management commands to make things easier. I'll take a look at this in detail later on, see if it is possible and has added value over manually doing stuff.

I'll think about the settings file some more, in an ideal situation it would work just like the settings file in django, however that is technically not possible in this case I think... I'll come back to you on this. Setting the directories like that is what I had in mind yes :)

[adamjgrant]

Ha, no problem. I understand, and I'm a django dev myself.

Technically, all of Kickstrap is static for django. Getkickstrap.com, built in Django and Kickstrap, uses "/static/" as its rootDir, so I would probably just advise folks use npm's volo to install it.

Adam Kochanowicz
UX Designer
Ipreo

Le mercredi, mars 13, 2013 à 10:24 AM, Allard Stijnman a écrit :

Oh how frustrating I don't have the time to help you develop kickstrap further right now, all I can do right now is play the role of advisor (more than happy to do so btw). At this time I am developing a new (my first) application in rails but I can only work on it in my free time so I'm still at the beginner stage of learning ruby and rails. So far I have been a python/django developer and my day to day work is still in django.
I will continue to work on the kickstrap gem since I will be using that in my project, also I think this is the most developer friendly way to make kickstrap available for rails, so let's focus on the gem for rails.
A thought just popped up in my head: a pip package for django would be awesome as well. But in django it is not possible to add static files through pip packages afaik (never seen such a package at least) but it could provide some template tags/management commands to make things easier. I'll take a look at this in detail later on, see if it is possible and has added value over manually doing stuff.
I'll think about the settings file some more, in an ideal situation it would work just like the settings file in django, however that is technically not possible in this case I think... I'll come back to you on this. Setting the directories like that is what I had in mind yes :)

—
Reply to this email directly or view it on GitHub (#76 (comment)).