creationix (Tim Caswell)

Name
Tim Caswell
Email
Website/Blog
http://creationix.com
Company
Creationix
Location
Richardson, TX, USA
Member Since
May 27, 2009 (6 months)

Following 0 githubbers and watching 23 repositories view all →

Public Repositories (16)

  • node-persistence

    A high level persistance/database system for node.js

    legend

    Last updated Sun Dec 20 08:07:31 -0800 2009

  • haml-js

    Haml ported to server-side Javascript. This is a traditional server-side templating language. Te...

    legend

    Last updated Fri Dec 18 13:17:03 -0800 2009

  • sousaball

    social networking game project using html5 canvas for the front end and node.js/V8 for the backend.

    legend

    Last updated Wed Dec 16 14:12:24 -0800 2009

  • node-topcloud-chat

    A real-time chat demo for nodeJS and TopCloud

    legend

    Last updated Wed Dec 16 12:15:27 -0800 2009

  • rack-php

    A php 5.3 framework with built in rack support. You can serve the php site using thin, mongrel, ...

    legend

    Last updated Mon Dec 14 20:16:51 -0800 2009

  • node

    evented I/O for v8 javascript

    legend

    Forked from ry/node Thu Sep 17 08:25:48 -0700 2009

    Last updated Fri Dec 11 08:38:19 -0800 2009

  • numbercatcher

    A simple app for Techtronix that manages critical numbers like public ports and project ids

    legend

    Last updated Thu Dec 03 10:37:44 -0800 2009

  • postgres-js

    The postgres backend protocol implemented in pure JS for use with node.js

    legend

    Last updated Wed Dec 02 13:50:23 -0800 2009

  • node-router

    A simple http server for node.js that has sinatra like qualities. Ideal for generating web servi...

    legend

    Last updated Wed Nov 18 08:20:16 -0800 2009

  • underscore

    Functional programming aid for Javascript. Works well with jQuery.

    legend

    Forked from documentcloud/underscore Mon Nov 09 14:41:57 -0800 2009

    Last updated Mon Nov 09 14:46:41 -0800 2009

  • topcloud

    High level application framework for Javascript (built on top of jquery-haml and modeled somewhat...

    legend

    Last updated Tue Oct 13 15:40:37 -0700 2009

  • creationix.com

    source code to creationix.com

    legend

    Last updated Mon Oct 12 14:52:26 -0700 2009

  • jquery-haml

    jQuery-haml is a haml like language written in JSON. This allows for easy dom building so that w...

    legend

    Last updated Fri Oct 09 07:26:03 -0700 2009

  • milk

    Milk is a rack based cms system built for ease of use and simplicity. Milk tastes great with and ...

    legend

    Last updated Sun Jun 28 00:46:44 -0700 2009

  • Calix

    A nice frontend to xgamma using pygtk. Nice way to calibrate the screen in Linux

    legend

    Last updated Wed May 27 21:08:28 -0700 2009

  • SkimMilk

    This is the initial version of milk, built around sinatra. It's more simple.

    legend

    Last updated Wed May 27 19:53:55 -0700 2009

Public Activity feed

creationix commented on ry/node Tue Dec 22 06:18:07 -0800 2009
Comment in 7873639:

I see this argument was already had elsewhere, but John Resig put an end to it. I respect John and Douglass Crockford, they've done a lot of good for JavaScript. I will comment no more as I now see this is simply flame bait. I apologize I didn't see sooner. http://github.com/jquery/jquery/commit/ddb86f8d5bd1bd21b2beeeea55baf505b47dfed5#comments

creationix commented on ry/node Mon Dec 21 18:30:59 -0800 2009
Comment in 7873639:

Ok, so to get back to my original point. Joshaven uses JSLint to clean up code. We've discussed this with Ryan quite a while ago, and he's fine with using it to clean up node's internal code. The official code conventions for node are posted at http://wiki.github.com/ry/node/contributing. While it doesn't specifically require semicolons, it does mention the other fixes that Ryan got straight from JSLint from what I presented to him.

I don't understand where all the hostility is coming from. It's just a simple fact that these are the conventions for node, and Joshaven't commit was accepted by Ry and pushed into the main code. I don't see why the big fuss.

creationix commented on ry/node Mon Dec 21 09:44:26 -0800 2009
Comment in 7873639:

I'm not saying that anyone is evil for not putting semicolons in their javascript. They were made optional intentionally so that it's easier for beginners to learn the language. I'm just saying that it's better for us that know better to follow the grammar and not rely on hacks that were added into the language to help beginners. There are dangerous situations where it guesses wrong. While these situations happen a little less in a controlled environment like node, they still happen.

Also, as far as the technicality of my statement. From the spec:

"..is also not a valid ECMAScript sentence, but is transformed by automatic semicolon insertion into.."

Or in other words, the code missing semicolons does not follow the grammer, and so the pre-parser/parser tries to fix it. If the parser actually fixes the code in one pass or does it in a separate pre-parser pass doesn't matter. The point is that code missing semicolons is invalid and must be repaired before it can be executed. Either we can do the work and explicitly put the semicolons where we meant for them to go, or we can trust in the implementation to do the right thing. Since the spec tells implementations to basically "If you see an error, than back up and add a semicolon to see if it fixes the error", I don't trust it one bit.

You're welcome to do whatever style helps bring beautiful code to pass, but don't accuse others of being nazis for not trusting this terrible algorithm to insert the required semicolons for us.

creationix commented on ry/node Mon Dec 21 08:15:24 -0800 2009
Comment in 7873639:

@raggi, The language does have a standard, it's terrible and specifies that the parsers implement these crazy rules. If you understood the history of JavaScript and how it was never really thought through or designed it would make sense.

Ryan has made it clear that he wants to use vanilla V8 Javascript, I think that's a good idea. The V8 guys have made it clear that they want to keep in sync with JavaScriptCore, and so basically, not following the spec, or even patching bugs in V8, if there were any, is not the place of node.

And to clear up what I mean by the spec specifying the crazy whitespace sensitive rules, here is the relevant part of the official spec.

https://gist.github.com/4658280967e5a1fba668

Basically it says that semicolons ARE NOT optional to be valid code, but parsers are required to implement a pre-parser that tries to guess where to put the semicolons. Hence, omitting them is both dangerous and slows down the parser because it has to "repair" your code first.

creationix pushed to master at creationix/node-persistence Sun Dec 20 08:07:31 -0800 2009
HEAD is 2b428078ceb8f55da76bfc67763f423c115bf6c1
creationix closed issue 1 on creationix/haml-js Fri Dec 18 13:17:42 -0800 2009
String replace only replaces one element
creationix pushed to master at creationix/haml-js Fri Dec 18 13:17:03 -0800 2009
HEAD is 72625711e81678e8aca1abe950d1cd3039021dc8
  • creationix committed 72625711:
    Use global replaces since JavaScript defaults to single replace.
creationix commented on ry/node Fri Dec 18 12:37:57 -0800 2009
Comment in 7873639:

I coded for years in other languages with braces on new-lines instead of at the end of the line like is common in JS. When I started doing heavy javascript work I forced myself to switch to the new style. At first it felt ugly and wrong, but then with time I learned to actually prefer it.

I believe that it is good to like how the code you write looks, but it's perfectly possible to train our eyes to "like" something that follows conventions.

Besides, most everything in the Crockfordian conventions has technical roots, not based on taste or preference. Half those technical reasons aren't valid in the world of node, but it's common to write client-side code too on a node project and there it does matter.

It's just a matter of taste, I prefer to use the same style on both sides if possible. Also after many large JS projects, I've learned to like and enjoy the conventions. They are beautiful to me and I'd guess to many others.

@brianmario: innovation is awesome.

creationix commented on ry/node Fri Dec 18 10:45:45 -0800 2009
Comment in 7873639:

I agree that the conventions are a bit strict and verbose, but that makes it easiest to understand for most people.

Javascript is a verbose language, get used to it. I think consistency is what matters most when talking about code conventions. Doug's stuff is good enough, especially if you know when to break the rules. I think it's a good idea for Node's core javascript to follow a common convention. And the widely accepted, and strict conventions from Doug are probably a good way to go. We can of course adjust and ignore the stuff that doesn't apply to us since we're not in the browser.

Also assignment expressions can be dangerous even though they're clever and concise. I know from personal experience. People aren't used to looking for side effects in expressions. Use them when it's best to do so. There are cases when using a with statement is the only way to accomplish something. It's fine to break the rules in these cases, but being sloppy about braces and semicolons just because it makes your code a few characters shorter isn't a good idea.

creationix commented on ry/node Fri Dec 18 10:17:36 -0800 2009
Comment in 7873639:

If it were just conventions, I might agree, but it's more. While those semicolons and braces on line ends are optional sometimes, this isn't always the case. Remembering the cases where they are needed and where they aren't needed can be terribly confusing. Not to mention that this changes a little across implementations.

Saying that JSLint is a crutch that keeps us from learning the language means you completely miss the point of JSLint. You shouldn't take any advice from the program unless you understand why it's telling you to do something. There are cases where some of the suggestions are wrong. It's a tool for people who do understand the language.

If you really learned and understood the language, you would understand why most of the JSLint "best practices" really matter. Sometimes Douglass Crockford goes a little too far towards strictness. JavaScript as a whole isn't that good a language, but there is a subset of it that's really nice and reliable. These best practices help up stick to that good subset.

creationix commented on ry/node Fri Dec 18 08:13:42 -0800 2009
Comment in 7873639:

Besides, I use JSLint.org to check my code, and it helps find real bugs as well as petty formatting issues. It reduces the noise of the error report if you go ahead and follow the formatting rules. JavaScript is a very misunderstood language. For example, the rule in JSLint that says that only one var statement is allowed in a function seemed silly at first to me. Then after debugging some nasty issue in my TopCloud framework for a week, I found it was related to having a var statement late in a function body. JSLint would have saved me a week of pain and suffering.

creationix commented on ry/node Fri Dec 18 08:10:59 -0800 2009
Comment in 7873639:

Because that's the accepted JavaScript best practice. Sure it doesn't matter since V8 has good and reliable parser, but when doing client side work, they're essential. Especially for IE. It's just easier to keep the same strict style everywhere.

creationix pushed to master at creationix/sousaball Wed Dec 16 14:12:24 -0800 2009
HEAD is 234afcbcb9b2b5c1e50fc408ae44a29892621e38

3 commits »

creationix pushed to master at creationix/node-topcloud-chat Wed Dec 16 12:15:27 -0800 2009
HEAD is 7e7852b4f2cbbe85c5fdd25253092e09dca8fb44
creationix pushed to master at creationix/node-topcloud-chat Wed Dec 16 12:07:32 -0800 2009
HEAD is b72bf56dbd4e219cb93daba4cf5bd469871ed89b

2 commits »

creationix commented on creationix/haml-js Wed Dec 16 10:42:57 -0800 2009
Comment in 845ad21:

Ok, I merged in the changes from express. I like the new separation of concerns better. Also I tagged it as the first stable release.

creationix pushed to master at creationix/haml-js Wed Dec 16 10:40:53 -0800 2009
HEAD is bb252602279070f34778dbfe7e841cb93aa80b34

2 commits »

creationix created tag 0.1.0 at creationix/haml-js Wed Dec 16 10:40:53 -0800 2009
creationix commented on creationix/haml-js Wed Dec 16 10:10:03 -0800 2009
Comment in 845ad21:

Agreed, I think I'll change it to not do any file/io but simply take in text and output text.

creationix pushed to master at creationix/haml-js Wed Dec 16 08:54:39 -0800 2009
HEAD is 845ad21d7f4a629024905fa2961f6add1101a6f2
creationix pushed to master at creationix/node-persistence Wed Dec 16 08:40:06 -0800 2009
HEAD is 8d04bd4626ddb8ffd87fc878b7175f0a8f2638b6
  • creationix committed 8d04bd46:
    Update the readme to reflect the status of the postgres driver.
creationix created tag 0.0.2 at creationix/node-persistence Wed Dec 16 08:38:29 -0800 2009
creationix pushed to master at creationix/node-persistence Wed Dec 16 08:38:12 -0800 2009
HEAD is 220a07a32a5550a83e03a64c6a4d7a43751cd9ec

6 commits »

creationix pushed to master at creationix/node-persistence Tue Dec 15 18:34:38 -0800 2009
HEAD is 38974fc4837a1f9991cf8e614f99149004b99645

4 commits »

creationix pushed to master at creationix/node-persistence Tue Dec 15 17:59:57 -0800 2009
HEAD is 20f7a0768954dd0b02d304aa711b926977d0f71a

3 commits »

creationix pushed to master at creationix/node-persistence Mon Dec 14 20:27:46 -0800 2009
HEAD is 8ae6ed39e03eab7745ffd56f16441e4eae1fc093

4 commits »

creationix pushed to master at creationix/rack-php Mon Dec 14 20:16:51 -0800 2009
HEAD is 1434484c264e13c9e7527408465e68514412d3f7

9 commits »

creationix started watching dantebronto/picard Mon Dec 14 19:17:18 -0800 2009
picard's description:
A Micro-framework for node.js
creationix created tag 0.0.1 at creationix/node-persistence Sat Dec 12 15:02:19 -0800 2009
creationix pushed to master at creationix/node-persistence Sat Dec 12 15:02:11 -0800 2009
creationix pushed to master at creationix/node-persistence Sat Dec 12 14:56:15 -0800 2009
HEAD is 1bce675ca1270435f543008b338b46887bc56e0e
creationix pushed to master at creationix/node-persistence Sat Dec 12 13:52:52 -0800 2009
HEAD is 9d3802acabf35f558f0215c4e976b9d24acbce43
  • creationix committed 9d3802ac:
    Implement and write tests for each, all, and nuke on store objects.
creationix pushed to master at creationix/node-persistence Sat Dec 12 12:14:24 -0800 2009
HEAD is e92ebf04e245df2c6830ac186d18091db64dafeb

3 commits »

creationix pushed to master at creationix/node-persistence Sat Dec 12 11:42:45 -0800 2009
HEAD is 3555c835fc50861f15297d704f9820b324478503

3 commits »

creationix created branch gh-pages at creationix/node-persistence Sat Dec 12 07:05:17 -0800 2009