Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Trello Tech Stack

blog.fogcreek.com

Post reply on HN
Print view View original

41–50 of 96 posts

Re: The Trello Tech Stack

#41

Post by mnutt »

frabcus wrote: post #36
edw519 wrote: post #32

Use things that are going to work great in two years. This is one of those remarks that is obvious to someone who knows what it means but mysterious to someone who doesn't. So what does it really mean? - Don't use a technology that, no matter how good, is just too niche for widespread adoption? - Don't use a technology that we'll have trouble finding programmers to support? - Look for stuff that will take better adva…

My (minimal) criteria is it has to be packaged in Debian. A couple years ago I considered both MongoDB and CouchDB immature for that reason. The recent confusion of CouchDB/Couchbase etc. shows that was a reasonable view.

I'm not sure when they started, but 10gen now packages and distributes their own MongoDB Debian and Redhat packages. It seems like the right move, so that they're not beholden to the update schedule of the distros.

Re: The Trello Tech Stack

#42

Post by dodger »

edw519 wrote: post #32

Use things that are going to work great in two years. This is one of those remarks that is obvious to someone who knows what it means but mysterious to someone who doesn't. So what does it really mean? - Don't use a technology that, no matter how good, is just too niche for widespread adoption? - Don't use a technology that we'll have trouble finding programmers to support? - Look for stuff that will take better adva…

I took it to mean "be forward-thinking rather than conservative."

Re: The Trello Tech Stack

#43

Post by apg »

jeswin wrote: post #37
apg wrote: post #8

This post raises a few questions for me... and perhaps some one more versed in these stacks can provide answers. - Does the use of CoffeeScript alleviate the MC Escher-esque quality of callbacks within closures involved in working with Javascript on both the server and client (and the data store)? I can totally see the appeal of CoffeeScript's syntax. Giving the programmers something different to look (and learn) at…

1. CoffeeScript doesn't alleviate this yet. I doubt will be much progress on this until we find a good way to implement defer/async. https://github.com/jashkenas/coffee-script/issues/350#issuec... I am writing a sizable Node app myself. In the end, you just get used to the callback style.

I am assuming that CoffeeScript should be able to add new syntax where the need arises, as the number of CoffeeScript users is probably still pretty low and able to adapt to change.

From what I can tell, CoffeeScript - and the Javascript/Node world - would really benefit from something like F#'s workflow/computation-expression syntax, which will take a fairly straight-forward readable statement and behind the scenes de-sugar the hell out of it into a bunch of closures.

http://en.wikibooks.org/wiki/F_Sharp_Programming/Computation...

EDIT: search for "De-sugared syntax" on this page for an example.

Re: The Trello Tech Stack

#44

Post by dodger »

DanielBMarkham wrote: post #12

Nice job, guys. I love this architecture. This looks a lot like my dream stack for future web work. Would love to hear some more about the "bleeding" experiences you've had.

Socket.io: https://github.com/LearnBoost/socket.io/issues/686

MongoDB (on FreeBSD): https://jira.mongodb.org/browse/SERVER-3927

Redis: https://github.com/antirez/redis/issues/91

. . . are a few.

Re: The Trello Tech Stack

#45

Post by apg »

jeswin wrote: post #37
apg wrote: post #8

This post raises a few questions for me... and perhaps some one more versed in these stacks can provide answers. - Does the use of CoffeeScript alleviate the MC Escher-esque quality of callbacks within closures involved in working with Javascript on both the server and client (and the data store)? I can totally see the appeal of CoffeeScript's syntax. Giving the programmers something different to look (and learn) at…

1. CoffeeScript doesn't alleviate this yet. I doubt will be much progress on this until we find a good way to implement defer/async. https://github.com/jashkenas/coffee-script/issues/350#issuec... I am writing a sizable Node app myself. In the end, you just get used to the callback style.

After reading that ticket, I think the solution is going to have to involve more than one keyword. It's curious to see that the objection is to the hideous mass of js that "defer" compiles down into. I kind of thought that was the point of CoffeeScript.

Re: The Trello Tech Stack

#46

Post by alexhaefner »

This is a great write up. We have a very similar stack for a separate team based project we're working on. The only difference is the front end stack, and we have tornado sitting back on the backend to serve http requests when needed. What's the benefit of Mustache/Backbone over just writing your own client side templating, in a practical sense? Last time I used a KVO framework, there was a performance penalty that I did not like. Does Backbone have any performance issues? Or even mustache? What's the trade off of having these frameworks versus generating custom tempting code?

Re: The Trello Tech Stack

#48

Post by trotsky »

How vulnerable are all javascript approaches in terms of injection type attacks? Do apps like node and mongo effectively prevent them, or is it still possible to shoot yourself in the foot? I've read some off hand comments along the lines of "as long as you're not a total moron you have nothing to worry about", but that sounds a lot like what was said about sql injections and xss before exploiting them went mainstream and it turned out everyones apps were filled with them. Has anyone audited a real world app built with a stack like this and come away with any experience to share?

Re: The Trello Tech Stack

#49

Post by apg »

bluesnowmonkey wrote: post #19
apg wrote: post #8

This post raises a few questions for me... and perhaps some one more versed in these stacks can provide answers. - Does the use of CoffeeScript alleviate the MC Escher-esque quality of callbacks within closures involved in working with Javascript on both the server and client (and the data store)? I can totally see the appeal of CoffeeScript's syntax. Giving the programmers something different to look (and learn) at…

LNMR... um... LaMiNaR? RoMuLaN?

I just ran the letters modb-re-nojs-li through my handy word_solver and came up with some candidates: MoRN, NoRM, ModeRN, NiMRod, ReMiNd, MeRLiN, LiMNeR, NiMbLeR

Re: The Trello Tech Stack

#50

Post by jashkenas »

apg wrote: post #43
jeswin wrote: post #37

Earlier quoted context omitted.

1. CoffeeScript doesn't alleviate this yet. I doubt will be much progress on this until we find a good way to implement defer/async. https://github.com/jashkenas/coffee-script/issues/350#issuec... I am writing a sizable Node app myself. In the end, you just get used to the callback style.

I am assuming that CoffeeScript should be able to add new syntax where the need arises, as the number of CoffeeScript users is probably still pretty low and able to adapt to change. From what I can tell, CoffeeScript - and the Javascript/Node world - would really benefit from something like F#'s workflow/computation-expression syntax, which will take a fairly straight-forward readable statement and behind the scenes…

That's correct -- because we compile to "standard" JavaScript, we're at least somewhat comfortable introducing significant changes (even to the syntax) where desirable. Even if you never get around to updating older pieces of code, all of the compiled JS continues to be fully compatible and interoperable with the newer stuff.
Post reply on HN