My comment is civil and explannatory. You may not like my sentiments, but down votes are not intended for unpopularity. Not only that, but in this case, my comment serves to reinforce the standards of HN regarding mis-titling of links and it is being downvoted.
A house divided against itself cannot stand.
I think that perhaps the best practice for publishing a CoffeeScript project should probably be to append a .coffee to the name rather than the usual .js. This would go a long way towards eliminating the kind of misunderstanding that you refer to in your OP.
A side note, am I the only one that has noticed an increase in downvote-readiness here lately?
That's why I down voted you. Is a JS compiler beneath you? Fine. Then post about that. Don't try to slip it into a veiled complaint about title accuracy.
This isn't just about readability and comprehension, it's about contribution as well.
Come on, what kind of percentage are we talking about here? Tiny. Absolutely tiny.
I guess I don't know any programming languages whatsoever.
If you love being ignorant of CoffeeScript enough to publicly form your identity around it then stop being in denial about your tone.
First, I'll establish some modest authority on the subject by pointing out that I've worked directly with Tim Caswell, who helped create CoffeeScript, at multiple jobs now. He's explained to me how they developed it and we've discussed the merits of it.
Third, I understand what CoffeeScript is and how it works, but have chosen not to learn it. That's my prerogative and I make no claims to the superiority of that choice apart from my choosing it.
Fourth, I _could_ talk about how time is not free. Installing a CoffeeScript compiler, learning CoffeeScript, undertaking the mental frame of reference change necessary to switch between context, are equally not free, but I don't feel the need to further this defense as it has been made many _many_ times before, especially here on HN.
What made me downvote both your original and this comment is that I can't accept that you (seemingly) write a lot of code in JS, but don't want to spen just 1 hour to learn CS properly (I know it takes this short, because I just did it a while ago. I haven't written any JS code since I was 14 - 6 years ago - but started reading coffeescript.org and in 3 hours was able to do everything I wanted in CS. So for a JS master like yourself it wouldn't take longer than an hour to master CS too).
To me, your comment sounded like an abacus master who doesn't want to learn Arabic numbers and multiplication table, because he's too busy. And again, I have nothing against you and downvoting a comment on HN !== hating you and/or disagreeing with everything you say or think.
Why on earth is this disturbingly so objectionable?
I've never disliked the fact that it was built, everyone has fun playing around with little transpiler things but it's turned into some retarded religious warfare. The show-stopper for me is when it gets to the point of pull-requests containing "Add coffeescript support". Once you go that far it's just flat-out wrong
It's also easier to remember JS libraries as Blah.js instead of having to worry that it's Blah.js or Blah.coffee.
Yes it is somewhat dishonest. But users of a lib or framework should not be reading its code in most circumstances. Otherwise it's crap API/documentation.
If you need to read coffee code as JS for some reason, compile it. If you need to submit a patch, doing it in CoffeeScript will indeed be a minor inconvenience. Not so for Clojure, Obj-J or whatever else will come along.
And on another note. These languages compiling to JS are essentially causing fragmentation. If ClojureScript gets as popular as CoffeeScript is now it won't be pretty. I'll bet that CoffeeScript will reach critical mass at some point. The newest libs and tutorials will all be Coffee. JS.next should adopt as many features as possible or promote it as the new standard to stem the tide and make fragmentation less obvious. CoffeeScript would be more stable as a language, hard to make JS semantics prettier.
Ruby dev here with limited JS/CS knowledge. Are there any sections of CS where the semantic mapping to JS is not obvious? It took me about five minutes to figure out what was going on.
I wish you the best regardless of your scripting language of choice! :)
He never said anyone else should not learn CoffeeScript nor that CoffeeScript was bad, but that for whatever reason in his own personal life it hasn't become valuable enough to do so. And yet still, the point of his comment had nothing to do with that, and instead simply requests that stories be labeled accurately. Seems completely uncontroversial to me.
in the last part, my emphasis was on the word everything. If you divide that comment into two different comments (first being 'misleading article' and second, (implicitly) 'I don't want to learn CS, though I write code in JS regularly'), I'd up vote the first and down vote the second comment.
It is true that his decision does not affect anyone else, but I don't believe that even such decisions can't be criticized. And I'm arguing that his decision of not wanting to learn a dialect of a language he uses on a daily basis (that would take a very short time) is not a good one, and is un-hackerish. If he had taken time to learn and have decided that CS is not for him, I neither would've down-voted him, nor would I comment on his decision.
I'm sorry if I wasted your's or any one else's time by my comments on this unimportant matter. I know that HN's comment section is meant to be a place for constructive arguments, but I couldn't help it. I read that an unseen friend is doing something that I think is really wrong, and I can't help mentioning it.
Maybe it is a good idea to have the value of downvotes diminish the more you use them.
I think another way could be to decrease a users karma by 1 for every 5 downvotes he makes... and also limit the number of downvotes a user can make in a day.
This is generally true of most CS projects. I can't speak specifically to whether or not you can use Tower.js without coffee, just saying don't discount a project because the author wrote it in CS. Spine.js (http://spinejs.com) is a great example of what I'm talking about.
If you're a half-way decent js dev, it's hard to believe CoffeeScript could be a cognitive stumbling block for you. Inferring custom baked inheritance in js libraries surely is more difficult.
I just want to point to this comment and its children as the reason that HN should have comment thread collapsing.
There's no reason the majority of people checking the comments for this link should have to see the language debate. It's not relevant to the Tower framework. The only reason this debate is so high up is because people chose to upvote the original comment.
By comparison, think about Python. Some libraries use C for performance gain. Does that mean you can't use them with Python? No. These are still perfectly valid Python libraries.
The analogy about Python is that you don't have to know C to be able to use a Python library written in C..
Sure, I may not be proficient in everything, but I try to have a working knowledge of all of the latest popular technologies so that I am not ignorant to what's going on around me. Like others have stated, 30min is all you need to really grasp what's going on in coffee script. Is that kind of time investment really that challenging to come by?
I think OP will get by without your career advice pretty well.
There is something of a schizophrenic behavior at work here. I am a Rails dev, I love the framework for all its strengths and would choose to live with its (relative) shortcomings any day but I think there's something not healthy about how it seems that a new (web framwork|language|paradigm|whatevs) always has to (kill|take a dump on) the competition to claim the spotlights.
The two technologies can co-exist without a problem, there are many pieces of software to fill that gap without having to reinvent the wheel where Rails does the job just fine.
And to anyone saying Rails has become "bloated", quit the catchphrases-based rhetoric already, a Rails project is nothing more than a set of conventions and classes, the developer (that's you) has a choice of tools every step of the way, so if your app is bloated, stop producing bloated code or hopelessly waiting for a silver bullet, IT IS NOT HAPPENING. NEVER. NODE WON'T BE IT EITHER.
Three years from now, some clever dude will come up with a new fresh concept, Node will suddenly be so 2012 but deep down you'll know.
You'll know it's the same old caper below the latest layer of paint and glitter.
Props to the people who worked hard on Java frameworks who make tons of people happy in the heavy infrastructure enterprise realm, props to the people behind PHP and associated frameworks, props to Rails dev for pushing the envelope and making me enjoy programming again and props to Ryan Dahl, Google and Joyent for making Node happen and shaking the bottle once again.
It does NOT have to be X VS Y VS Z.
This means that if there is a file ./lib/foo.coffee, the following code in bar.js will work:
var foo = require('./lib/foo');
i like node because it lets me build small standalone programs/apps which i can link together to act like on big project.
i - for one's part - found that having one master-overlord framework kills a lot of the joy of programming.
ok, there is the "it's much more manageable" argument, but well, my experience is that big apps on RoR need much more maintenance work then similar programs on much uglier stacks (i.e. webprojects using LAMP)
said that - after reading some of the docs - i will probably give towerjs a try.
Ahem, you're exaggerating there just a little bit. There are probably around a dozen web frameworks that are competing for the spotlight right now. With Zend, CI, Django, Symfony, Struts, Cake, etc. all equally if not more popular it's hard to say Rails has the "bulk" of today's web devs. I wouldn't even go as far as saying that the bulk of today's web devs appreciate MVC.
Some of the Node people like things small but when applications get bigger putting things into an MVC structure often makes your code more organized. Until someone comes up with a better idea that takes off this is how things will be done and I think it's great that Node has a few choices now to do this.
The types of projects that benefit from being in node.js instead of Rails, Django, etc, don't really benefit from having all those decisions made in advance. If the "Rails Way" works for your project, you'll probably benefit from doing it in rails. There's certainly more library support and it's easier to find more experienced developers for Rails than node.js.
There's a tendency to put all kinds of projects in node now, just because it's "hot". Some projects benefit from node, and some would be easier to do in some other language/framework. If you're experienced with Rails and are working on a project that fits that style, you're probably better off just doing it in Rails rather than switching to node and using a Rails flavored framework.
By the project, I presume you mean Rails. Because Rails doesn't force ORM on you. It assumes that by default, but if you don't want to use an RDBMS and ORM, you simply remove the inheritance from ActiveSupport::Base from your model class and write a class that talks to whatever you prefer.
Rails makes the reasonable assumption that most people will be talking to an RDBMS. It could omit that and instead you could "build it out and customize it like you need", but that way lurks 7,000 line XML config files and all the other crap lots of Rails folk were trying to escape from. The point of convention over configuration is that for some baseline assumption of normal, it comes ready to rock and roll.
I'm neither anti-Rails or anti-ORM. But the types of projects that actually benefit from being in node, rather than Rails generally benefit from not being tied to those conventions. If what you're doing fits the Rails pattern, that's probably a better solution than anything in node. If you're doing a project that doesn't fit that, and you need lots of customization, you're probably better off doing that from scratch (or with a minimal un-opinionated framework).
I think both have their places. It really depends on the project.
There is express, geddy, railwayjs, djangode, drty, Locomotive, spludo and probably a few others that I missed. All of them are modeled after rails/django.
The last thing the node-ecosystem needs is yet another half-baked rails-clone.
This may come across harsh but I really don't understand why people keep beating that dead horse instead of tackling the node-vision: Build a framework that spans client/server. Make it good. Start by not pouring your time into yet another rails-clone...
But, a framework that spans client/server could be really interesting. Have you seen Derby? http://derbyjs.com/
I hope this grows. I'd love to contribute too.
While avoiding any new FUD, and since Tower.js is Coffeescript and jQuery top heavy, wouldn't this inevitably lead to conflicts?
(Side note, at the bootcamp the framework recommended was Express.)
The one feature that you might find yourself relying on in a project like Tower.js is easy access to the prototypal inheritance found in CoffeeScript's "class" keyword ... but you can easily have your library expose that as a helper function.
> The one feature that you might find yourself relying on in a project like Tower.js is easy access to the prototypal inheritance found in CoffeeScript's "class" keyword ... but you can easily have your library expose that as a helper function.
Those two statement contradict each other. People who make libraries for CoffeeScript don't go to the trouble of writing a helper function. This doesn't. Batman.js doesn't.
I agree with you that Tower and Batman.js should both have "extends" functions built-in (*Ahem: http://backbonejs.org/#Model-extend). It would be a line or two of code for them to add, and make it easier for folks that don't have other library or CS support for setting up prototype chains.
Personally, this was how I was creating sites 3 years ago. I made my own framework that does pretty much the exact same thing.
I've completely dropped this in favor of using bidirectional message passing, because imo that's what Node really excels at and it's not something you can get with RoR. If you are using Node.js, it's a good thing to have a framework that does bidirectional real-time communication out of the box. I'm not sure if tower.js supports this or not.
At a very basic level, this is all I need to think about in terms of the API to get some data passed around in my current workflow. I've yet to find something more suitable for myself personally.
CLIENT (mobile or web)
// request data
request = messenger.request('get me a list of things', message);
// listen for events from server
messenger.on('someone got something', (message)->
// listen for data
messenger.on('get me a list of things', (message)->
// emit data
messenger.send('someone got something', data)
- DRY! Use the same templates/models/controllers/i18n/validations on server and client! I can't underestimate how awesome that would be.
- One fewer languages to learn and switch back and forth between
- Team flexiblity. No such things as "front end guys" or "back end guys" (sorry girls)
- MASSIVE improvement in debugging. Debugging in Ruby is just bizarrely crappy. Really WTF? How is this possible. Anyway it sucks badly but is pretty decent in JS. (assuming stack traces were decent, this is easy to screw up in js)
Plus there are the inherent benefits of using node (arguable) where you could do push notifications/websockets/etc trivially and in a well integrated way instead of having to... use node (or faye/whatever) or running some other server.
Some people might argue that js/coffee script suck compared to Ruby and cite that as an advantage but I for one love js (and ruby but less so) so I don't care.
This builds on top of two other frameworks (Connect and Express) so I imagine the dependency stack for this framework is really long which might make debugging painful.
He is unfamiliar with just one of those.
Why the downvote? His comment contributes to the discussion, unlike yours.
Source for towerjs.org (written with Tower.js) - https://github.com/viatropos/towerjs.org
I'm not sure a pure MVC (or a Model2) is the best way to architect node web applications. The config part looks great, I'll read that more carefully tonight.
It's strictly focused on the backend, and remains strongly view and database agnostic.
Here's the project repo:
I've used Backbone and played with Spine - I just can't help but feel as though they could go all the way. I wonder whether that's viable?
For example, if you look at the definition of the App.User here: http://towerjs.org/models, trying to do the same kind of thing where you can quickly declare a class that extends a base class and adding things to it can become quite awkward.
You'd have to manually construct the prototype chain (or use the library-specific class DSL) and have to repeat the class name in order to call the "field" method there.
Tower.coffee - CoffeeScript Framework ...