jnowlan

For all these 'bubble' cities (Vancouver, S.F., Seattle, London, ...), I wonder if the bubble ever pops? Are there examples of the prices/avg. income getting so far out of whack that things collapse?

http://www.economist.com/blogs/dailychart/2011/11/global-hou...

Detroit probably experienced a R.E. bubble in the day...

While I completely agree, since it will never happen, why not strip javascript out of a browser (FF?), come up with a new catchy name, and market it as a safe browser. Just need a catchy name..., hmm, maybe Lynx? ;

Great article. Funny and knowledgeable. I know it's impossible but many of the comments here make it look like they didn't read the article. I guess if we followed 'best practices' we would be good.

So caching. Doesn't the db do that? And as much as I hate to say it, are the added complexities (webserver caches) better than the even more traditional approach - throw hardware at it? Always lots to think about. Thanks!

Zeek,

I've been lucky enough to have benefitted from Sqlalchemy and Mako (but it's been awhile). Thanks.

This article looked like it was going to hit the sweet spot of stuff I'm curious about, but I found I was still left with questions. If you (or anyone) will indulge me... I'll try and ask a question to help clarify matters.

I work at a University on legacy ERP system(s). During registration there are 800+ concurrent connections but normally it floats around 200. Most all of these connections are idle. As you pointed out, a db may not be io/context bound (still hazy on that one). At the end of the day I consider myself technically astute, but basically a crud business programmer. I understand ACID and transactions; threads and async, maybe not so much.

Where I've always thought async could provide benefit would be in the following scenario. Our apps make a large # of procedural db calls today. If after studying them I realize that many are independent (i.e. reads) and could be 'batched' could that not provide a big performance/latency improvement? I.e. instead of the serial sequence of calls that happen now (even if a stored proc), async allows me to submit multiple sql calls. What I'm calling batch. In this ideal world, sqlalchemy would take care of the details (perhaps with some guidance directives as to whether ordering of results was important) and assemble the results.

Is this not a possible future 'async' sqlalchemy with superior responsiveness? Don't threads block on each sql request?

Are there any plans for a coffeescript/python implementation of Dart? Could that be done as a preprocessor?

As trivial as that sounds, that is part of what has hindered its adoption. I seem to remember reading about the Dart team learning that many early adopters were not c++/java people but Pythonista's. You'd think they would have adapted to that.

So widgy could by used with Pyramid via sqlalchemy?

Would this allow python to be run in the browser (by going through Emscripten and asm.js)? Is that a goal that makes sense?

Couldn't hard copies be outsourced to No Starch if a set amount was donated? I'd much rather buy a book - and would make a higher/set donation.

This point needs to be stressed more. Not so much that it is 'open' but that you can write an app and it will run everywhere: Mobile, WEB and DESKTOP. If there are good solutions for this now I am unaware of them. Desktop is still important.

Open is great, but is part of the larger, political issue(s). The marketing has to appeal to the 'what does it buy me'?

From a non-expert, but avid observer, this looks like where things are going. I support Mozilla, but wonder if this is a Hail-Mary pass, with something like Dart and Web components being the 'engineered' approach.

At this stage, if asm.js is to succeed, they need to show how us mortals can use it. I.e. it needs to part of a complete toolchain, or an ide.

asm.js using qt (without hacks) would be amazing. How do I help (when I can hardly wrap my head around it)?

I would like to see the adoption, if not formally at least informally, of a javascript ux toolkit. This toolkit would work across platforms - mobile, web, desktop. Ideally it would be modeled on qt. Maybe using dojo/Maqetta if this is possible or makes sense or Qooxdoo.

ZUL offered much promise but was never really developed imho. And now there are too many js toolkits out there -- too much choice! I can understand not wanting to favor one toolkit over another, but I think there is nothing wrong with informally adopting one -- and consolidation will happen eventually anyways. Web components may be a way forward here, but I would think Mozilla, with its emphasis on standards, could be a leader in uniting these elements.