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

How Basecamp Next got to be so damn fast without using much client-side UI

37signals.com

Post reply on HN
Print view View original

61–70 of 135 posts

Re: How Basecamp Next got to be so damn fast without using much client-side UI

#61

Post by losethos »

rkalla wrote: post #30

Are you guys taking care to send as-plain-as-possible markup from the server to the client and then style it up to keep most the UI development in CSS or are you just sending through raw, styled HTML that gets inserted as-sent directly into the page? This reminds me of the early days of Java Servlets when people would stream back HTML from inside their Java Servlet code to JSP pages to build it out... made it impossi…

LoseThos has a document format "Ltf". The format supports local file links and graphics and trees and colors and page settings. It's kinda like an HTML language.

This file converts to HTML.

http://www.losethos.com/LTHtml/Adam/ToHtml.html

Your small minds cannot imagine something besides html or what? Short circuit?

Don't get me started on arrogant Indian airheads. I tell them I wrote a compiler and they start talking down to me clearly having no clue they should be talking up to me.

Re: How Basecamp Next got to be so damn fast without using much client-side UI

#62

Post by jashkenas »

dhh wrote: post #44
jashkenas wrote: post #24

This is all fascinating ... but does it feel like a sustainable approach going forward, or more like a turbo-charged horse and buggy? Developer happiness aside -- there are plenty of folks who like JavaScript just as much as Ruby -- and assuming that we're talking about an non-public-facing app (like Basecamp Next), is there still an argument that can be made in favor of doing your UI on the server side? Even just in…

I'm not sure what qualifies as sustainable or not in your book. We've achieved our speed goals (sub 100ms pages for the most part), our development goals (Ruby, Rails, server side pleasure), and our UI goals (app that feels like a web page, not just a single-page JS app). I'm sure Flash or Silverlight or other RIA people would argue that anything that's not a compiled native experience isn't as flexible or as fast as…

By "sustainable" I'm getting at the point that if you're already doing 50/50 Ruby/JavaScript ... it makes you wonder which direction that ratio will tend to go in the future. Will Basecamp Next Next still be rendered as chunks of HTML that are sent over the wire to be inserted into specific spots on the page in 2015?

Either way, I'm very much looking forward to using the new version.

Re: How Basecamp Next got to be so damn fast without using much client-side UI

#63

Post by bradleyjg »

hello_moto wrote: post #32

I find GWT to be the best platform to do full-blown fat client-side paradigm due to several reasons: 1) UI Templating (like XAML) 2) MVP Pattern + JUnit = test automation as part of your build with minimum investment to infrastructure (most JS based solution requires investment on infrastructure) 3) Resource Bundle (similar to Asset Pipelining) cut down HTTP requests 4) Resource splitting (follow up from #3) to reduc…

I like GWT as well, but its development history makes me a bit nervous about its future.

It is open source, but doesn't have a developer ecosystem outside of google employees (in fact they outright state that no one else can be a committer). That in itself wouldn't be the end of the world, but unfortunately google has a) reduced resources devoted to GWT dramatically in the last year or so (many team members were reassigned to the dart project), and b) has a history rapidly changing 'paradigms' and semi-abandoning the code and documentation for the old way of doing things.

Re: How Basecamp Next got to be so damn fast without using much client-side UI

#64

Post by dhh »

jashkenas wrote: post #62
dhh wrote: post #44

Earlier quoted context omitted.

I'm not sure what qualifies as sustainable or not in your book. We've achieved our speed goals (sub 100ms pages for the most part), our development goals (Ruby, Rails, server side pleasure), and our UI goals (app that feels like a web page, not just a single-page JS app). I'm sure Flash or Silverlight or other RIA people would argue that anything that's not a compiled native experience isn't as flexible or as fast as…

By "sustainable" I'm getting at the point that if you're already doing 50/50 Ruby/JavaScript ... it makes you wonder which direction that ratio will tend to go in the future. Will Basecamp Next Next still be rendered as chunks of HTML that are sent over the wire to be inserted into specific spots on the page in 2015? Either way, I'm very much looking forward to using the new version.

In terms of client-side MVC vs server-side renderings, the ration is more like 90/10 or 95/5. We have one major section that's all client-side MVC, which is our calendar. We have one tiny section as well, which is a little invite widget. Everything else is server-side renderings.

To me that's like how we in the past used Flash to play sounds in Campfire. Or reimplemented a poller in Erlang. Or use nodejs for the development Pow server. Use all the great tools available in the niches where it makes sense.

But the bulk of Basecamp is exactly the type of application that makes wonderful sense to do in Ruby and Rails. We've been sending down chunks of HTML in response to Ajax requests since we started doing these types of apps in 2005. So far I haven't seen anything to make me reconsider that approach for the majority cases.

Re: How Basecamp Next got to be so damn fast without using much client-side UI

#66

Post by adeelk »

I think in the whole client-side rendering debate, a lot of people miss the fact that there is a one-to-one correspondence between JSON and a certain subset of HTML, that can be illustrated by the following example:

    {"user": {"first_name": "David",
              "last_name":  "Hansson"}}
    
    
      David
      Hansson
If, as 37signals basically seem to be doing, you restrict yourself to this subset of HTML and use CSS to do _all_ presentational styling, then honestly it’s all the same either way.

Re: How Basecamp Next got to be so damn fast without using much client-side UI

#67

Post by hello_moto »

bradleyjg wrote: post #63
hello_moto wrote: post #32

I find GWT to be the best platform to do full-blown fat client-side paradigm due to several reasons: 1) UI Templating (like XAML) 2) MVP Pattern + JUnit = test automation as part of your build with minimum investment to infrastructure (most JS based solution requires investment on infrastructure) 3) Resource Bundle (similar to Asset Pipelining) cut down HTTP requests 4) Resource splitting (follow up from #3) to reduc…

I like GWT as well, but its development history makes me a bit nervous about its future. It is open source, but doesn't have a developer ecosystem outside of google employees (in fact they outright state that no one else can be a committer). That in itself wouldn't be the end of the world, but unfortunately google has a) reduced resources devoted to GWT dramatically in the last year or so (many team members were reas…

I think the biggest danger of using GWT is when it breaks on newer browsers and this has happened once in the past with the release of Safari 4 (or 5?) there was a minor hiccup in which they quickly fix it the next day.

That is definitely a major glare. Other than that, if the community decided to fork it (and have the time and capability to do so) it'll be a safe choice for a long time.

GWT as of today is definitely very polished and well maintained and fulfil the needs of Single Page App smoother than having to hunt different tools and libraries and to set them individually to be a part of the build tool.

Re: How Basecamp Next got to be so damn fast without using much client-side UI

#68

Post by edw519 »

I love posts like this, not just for what OP has done, but for what you guys have to say about it. I'm continually asking myself 3 questions:

  1. Should I do it on the client or the server?
  2. What should be travelling between the client and the server?
  3. Based on the answer to #2, what else do I need on the client?
Even though I've read all your great discussion points, I'm not sure I'm that much smarter. But it's nice to know I don't suffer alone. :-)

Re: How Basecamp Next got to be so damn fast without using much client-side UI

#69

Post by zaidf »

jonknee wrote: post #43
zaidf wrote: post #27

Earlier quoted context omitted.

I have to agree here. A major problem with client-side json is the need for additional documentation and likelihood of things breaking because of simple html edits. For example, if you are populating a bunch of divs inside a parent div with the data returned using json, you would describe this using something like jquery selectors. Now if someone else comes and moves around the div during a redesign, he must go throu…

That's nonsense, the same issue would apply on the server side templates. If you go around messing with DIVs without an idea of the consequences, you will get in trouble regardless of your templates being on the server or client. If you try to have the designer do a redesign without testing the application afterwards, you're always in for trouble.

you will get in trouble regardless of your templates being on the server or client

My view is that you will get in significantly less trouble because manipulating an HTML template that is rendered on server side is much easier to manage and adapt to a new design than finding nitpick jquery selectors across the app that depend on a specific div structure.

Btw, my post doesn't imply anywhere that a designer should redesign an app without testing. Therefore, your argument about testing is garbage.

Re: How Basecamp Next got to be so damn fast without using much client-side UI

#70

Post by jondot »

Joeri wrote: post #60
jondot wrote: post #33

Earlier quoted context omitted.

With all of the backbone and node.js hype going around, people tend to forget that client-side development is developing on the client's side. Sooner than later you will have to deal with * nondeterministic testing, * interactive testing (leaving machines on to run interactive testing at night), * most of the bugs will live on the client side, * you'll have to support each and every machine's quirks (you can't preten…

You can still do unit testing of your client-side code if you wrap everything in components that separate state from rendering. The rendering itself you can only test with a human looking at the page anyway (or by comparing to reerence renderings). Extjs uses this approach. I can easily unit-test my forms written on top of extjs. Fundamentally this is a bikeshedding debate. Whether you're programming on the client or…

Great! You may have put it better than me with the closer to server - closer to user analogy. So to complete my goal I'll ask a question.

You already are at the server. It cost you almost nothing to manage yourself there (monitor, analyze, etc).

Do you have the resources to handle the complexity of being closer to the user? Is a "true" client side SPA worth it over what 37 are doing?

In terms of value for development investment, I'm not entirely sure, which is what I think David refers to as pleasure of development!

Post reply on HN