The Trello Tech Stack • Hacker News Board

Re: The Trello Tech Stack

#31

Post by Rauchg » Thu, Jan 19, 2012, 6:06 PM UTC

dodger wrote: post #28

eaurouge wrote: post #20

If you could do this over again, would you still choose socket.io for websockets, or would you go with something else like PusherApp?

Today I'd consider going with a service, but first I'd see how https://github.com/LearnBoost/websocket.io looks. Most of our problems have been with abstractions in the socket.io client and scaling issues with server process chatter. The chatter shouldn't be necessary with websockets-only.

With https://github.com/LearnBoost/engine.io the abstractions are greatly simplified, which is what I'm announcing today.

The socket.io codebase has been shrunk dramatically, and it's as a result easier to scale/maintain.

Re: The Trello Tech Stack

#32

Post by edw519 » Thu, Jan 19, 2012, 6:09 PM UTC

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 advantage of impending improvements in hardware and communications?

- Avoid frameworks for which support may wane?

- Avoid technology that we may have to support ourselves?

- Avoid anything proprietary whose owner may disappear?

- Make sure that whatever you choose, it will work well on mobile technologies, even as native apps?

- Choose technologies abstract enough to minimize our costs but not too abstract to be inefficient?

- Any combination of the above?

- What considerations have I missed?

Re: The Trello Tech Stack

#33

Post by drewda » Thu, Jan 19, 2012, 6:13 PM UTC

"We custom-built a client-side Model cache to handle updates and simplify client-side Model reuse."

Is this related at all to backbone.iosync.js?* Or, if not, is it something that Fog Creek will be open to sharing in the future?

* https://github.com/logicalparadox/backbone.iobind

Re: The Trello Tech Stack

#34

Post by jcromartie » Thu, Jan 19, 2012, 6:15 PM UTC

Node.js, Redis, and MongoDB? They've gone full web-scale!

In all seriousness, though, it looks like they are using Redis for exactly the right reasons, and the larger architecture is pretty much the definition of a sane forward-looking design.

Re: The Trello Tech Stack

#35

Post by jonknee » Thu, Jan 19, 2012, 6:15 PM UTC

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 have a feeling that Javascript based NoSQL backed web development is going to be just fine in two years. Quite possibly the standard stack for a large percentage of projects.

Re: The Trello Tech Stack

#36

Post by frabcus » Thu, Jan 19, 2012, 6:19 PM UTC

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.

Re: The Trello Tech Stack

#37

Post by jeswin » Thu, Jan 19, 2012, 6:21 PM UTC

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.

Re: The Trello Tech Stack

#38

Post by wowzer » Thu, Jan 19, 2012, 6:29 PM UTC

When I first saw Trello I "felt" that something cool was going on under the hood. So I did a little poking to see what JS technologies you guys were using. The piece I was most excited to learn about was backbone. Had never seen it before and was really impressed by the space it was filling and what it's capable of. Thanks for the write up.

Re: The Trello Tech Stack

#39

Post by wildmXranat » Thu, Jan 19, 2012, 6:30 PM UTC

gecko wrote: post #3

praxxis wrote: post #2

"We use a really excellent async library" Does anyone happen to know if this is an open source or in house library?

It's open-source: https://github.com/caolan/async

Yes, I've seen it on HN before and it's the bee's knees.

Re: The Trello Tech Stack

#40

Post by jeswin » Thu, Jan 19, 2012, 6:30 PM UTC

dodger wrote: post #16

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…

- Daniel is going to write another post detailing this. The answer is that when you combine CoffeeScript and a good async library, you can indeed get rid of that stuff. - MoNsteR? =)

when you combine CoffeeScript and a good async library, you can indeed get rid of that stuff

My experience has been that you could only do this in few cases. Not an issue that can be worked around elegantly in libraries, you need language support. http://tamejs.org/