Hey kd people,

I've spent most of the last week working on kd framework and just came out to introduce you to kdmodules, a very humble attempt of my own to modularize this beauty for future generations :)

I actually have applied for a job interview in Koding last week and seems like it didn't work out as expected :) But anyhow it was fun to dive into the this beast and see what you guys are up to. It kept me busy for a while and I didn't want to throw away this effort.

Following is my original proposition to @devrim. I'd love to read your opinions one way or another, and kudos- keep up the good work :)

a guide to kdmodules

This document covers a quick introduction to kdmodules and discusses its application to workflows for building modular web applications.

introduction

kdmodules is an ongoing project that aims at modularizing the kd framework.

what is kd framework?

kd framework, an open source community project led by Koding, introduces a nice set of ui widgets and serves as the base library for kdapps.

It resembles the early stages of the mighty Google Closure Library. One major difference is that it is written in CoffeScript with object-oriented paradigm in mind all the way down to its very core; thus allowing easier abstraction over classes and brings joyful tears to our eyes which already lost half of its sight due to long hours of struggling with inheritance, prototype chains and etc. in javascript, infamously the bad parts.

But most importantly it is a thin integration suite under the hood and provides the necessary tools to integrate your applications into existing Koding ecosystem. It is one of the many solutions to build beautiful things on Koding if not the easiest.

kd, the bad parts

We have seen the good parts, now let's talk about the other way around.

It's been roughly a week since I have introduced myself to kd. Not forgetting the huge effort that took from many many well programmers and designers to build these crazy collection of widgets; if I may put my two cents in, that among not being well-tested and documented it lacks the structure to support modular applications of the future web, so to speak.

the future of the web

We, as front end engineers, we have suffered a lot. We have spent many precious hours building workflows, managing assets, keeping our 3rd party libs up to date, destroying workfows, fixing compatibility errors, building workflows again, fixing cross browser issues and not being able to test anything before building something useful, if not already got fired.

You see, it was like zombie apocalypse back then, we hardly had time to breathe.

A combination of Grunt+Bower, Yeoman, RequireJS and several others have eased the pain a bit, but unfortunately they introduced a far more complexity than needs to be.

Hopefully with the introduction of Web Components, this will end. We will just whip up a main.js, require some stuff, emit some events here and there, and bam ready! your next ground-breaking idea is live on the web!

Actually I lied, it won't end; because most of the libraries around are not quite compatible with modularity yet. Anyways, we should not worry about tomorrow's problems until tomorrow, each day has enough trouble of its own already. But it's never been the worst idea to start building tomorrow's strength today.

back to today and the future of kd

We don't have our Web Components spec ready yet. But there are alternatives, most notably Component.

Component community put a great deal of effort into this issue and built one of the most-awesome solutions to tackle building modular applications on the web. (See tj's blog post, smalljs site offers some beginner introduction too.)

And there are others inspired by Component, Duo, normalize, webmodules, npm-dom...

Frankly kd framework doesn't quite fit in with this emerging philosophy of modular web application development.

And this is where kdmodules steps in to the scene.

brace yourselves, modularity is coming!

Long story short, kdmodules organization on Github acts as a registry for all of the libraries within kd framework.

Paired with kd.js, kdmodules builder tool, it makes extremely easy to build kd applications.

Let's see how easy it is.

getting started with kd.js

With npm do:

npm i kd.js -g

This will install kd command globally, if you don't want to install globally just remove the -g flag.

kd -h shows some help on usage. But actually it is easier than you think.

You build kd applications like this:

kd index.coffee

kd uses browserify by default. However all kdmodules are compatible with component spec, and therefore kd provides an option to build your modules with component-builder.

kd -c

benefits over using big ol' kd

• Semantic versioning (npm & component)
• Allows incremental builds with component & watchify
• Use any component builder plugin or browserify transform, thus use any css preprocessors, templating languages you'd like
• Easy maintenance, no need for huge testing stuff, coverage libraries and stuff
• UNIX philosophy in mind, "Write programs that do one thing and do it well"
• Supports npm/github/bitbucket
• Ability to require over 1600 components

examples

For browserify builds, install the kdmodules you need with npm first:

npm i kd-core kd-header --save

And start coding right away:

core = require 'kd-core'
header = require 'kd-header'

main = new core.KDView
main.appendToDomBody()

foo = new header.KDHeaderView
  type: 'big',
  title: 'bar'

main.addSubView foo

And build it with kd:

kd index.coffee -o output.coffee

If you choose the component path, you won't even have to install a single library manually.

Just make a component.json, something like:

{
  "name": "some-awesome-site-name",
  "version": "0.1.0",
  "dependencies": {
    "kdmodules/core": "^0.1.3"
    "kdmodules/header": "^0.1.2"
  },
  "scripts": [
    "index.coffee",
    "*.js"
  ],
  "styles": [
    "whatever.sass",
    "css-preprocessor.styl",
    "you-like.less",
    "or-all-combined.css"
  ]
}

roadmap

• modularize all the way
• bring stylesheets into the party, allow devs to just fork an official kdmodule repo and use a custom theme
• cleanup global namespace pollution
• tests
• remove jquery, devs should install it if they need
• api consistency
• improve kd.js so it can uglify
• support sourcemaps and all that nifty debugging stuff

notes

https://github.com/tetsuo/kd.js/issues/1

I am to blame for pasting that thing into the utils, because before that it was to be found in multiple places throughout our codebase. What it does is not good, and having it on utils encourages its use. We should change the handful of places where it is being used—which are mostly related to forms—and then remove it from utils

Running gulp --docs results in an error, as seen on Travis:
https://travis-ci.org/dokngh2621/kd/builds/43877843

I was curious to see if places where mouseup/mousedown is used, could it also allow for touchstart/touchend events for mobile users?

In 0.1.19 version of KD framework had all test suites for entire codebase, we would like to add them back to current version.

Using coffeelint and integrating it with github hooks using ghooks plugin, will make this framework a much more cleaner place. What do you think?

npm prepublish tasks should be disabled on travis builds to improve build time.

Since i manually published with npm@5 the prepublish script didn't work therefore build folder didn't get pushed.

remove the borders and get rid of the overlapping pixel on the arrow edge.

I would like to start a discussion around this issue. I believe we should have some kind of guideline for writing tests. Not only writing tests, but also writing testable code is an issue as well.

Having said those, I am not anything near to a test expert. But I would like to have this kind of discussion so that everybody would be on the same page.

/cc @sinan @gokmen @humanchimp @fatihacet @szkl @burakcan

When will it support ubuntu 6?

a long waited feature for the scrollviews, should be addressed soon.