Offler

(However, It's also worth mentioning that Discourse is, if anything, even more of a JavaScript project than a Ruby on Rails project.

So why not Node.js? Presumably it's down to maturity.

Where I work we have build a framework which is quite powerful for handling large JavaScript codebases. http://www.caplin.com/developer/component/bladerunner

I'm surprised there isn't an equivalent OS one, I think Yeoman is a pale comparison of it.

Of course you can use JavaScript to express OOP patterns. You say it yourself that you need those patterns to develop large apps. Anyone who does otherwise either leaves behind a mess of a code base or is being naive. You can have classes right now in JavaScript, it's just a matter of educating developers.

I understand the evented nature of Node.js and I'm not taking that away. In the code example I gave I'm still using the async methods.

DirectoryScanner.scanLibraries = function(librariesRoot) { // Asynchronous Function Callback function // | | fs.readdir(librariesRoot, this.onLibrariesDirRead.bind(this)); };

All I've done is pass in a bound method on an object as the callback function. OOP does work for Node as far as I can tell I broke nothing with my code, it's all async/evented...

Can you give me an example as to how my coding style would break Node? I'm genuinely confused.

Author here: I like promises and I think they have their uses but I think for most cases simply writing well structured and encapsulated code will make them superfluous. You also have the problem of working with APIs that don't return promises.

I just don't understand the issue people are having here. Nested callbacks are a design choice, if you do not want nested callbacks stop writing code with them in it.

Here is a simple example in some Node.js code I've just written (I've never written any before this little project).

https://github.com/Offler/node-bundler/blob/master/lib/bundl...

As you can see you just need to write in an OO manner and use function.bind(this) and Bob's your uncle. Really don't get the difficulty.

Yes, it's a conspiracy! They're out to get Webkit.

Indeed, 'terrible', 'evil' but not 'lazy'.

Nothing could cause such pain without a lot of hard work.

Then I suggest you read the article as he gives a very good explanation.

I believe they've said never. They don't want just one major rendering engine.

Could not agree more with the idea that people should write more well designed, OO code. This exact same issue is prevalent in JS land and it leads to people saying JS can't be used for real development, when in fact the problem is that the code they write is a mess and that's what's holding them back.

We have a framework more than a library, we basically ship a framework that our clients use to create their own web trading applications. This framework covers many asset classes and many use cases.

It's not likely that any client would use all of our code and so we have build a tool framework that only pulls in the JS code that your application uses, this is done without a build and is immediately available (add a 'new namespace.sub.Class()' line and hit f5 and it will be in the js bundle you get.)

We bundle js, css, xml, i18n tokens etc.

All automatic and requiring no build.

I think those eras had browsers that weren't capable of delivering on the promise.

If you only work with IE9+ (all the other browsers are quite good now) you will be working in a run time environment that is far superior to those available in the DHTML/Ajax era.

Another issue is that very few people know how to do large scale JS applications, where I work we do (130,000K+ lines of code, 900+ classes) but it has taken us several iterations to get to this stage.

I believe we are planning on making our tools open-source so hopefully people will start to see that large scale JS apps are very doable. www.caplin.com if you want to keep an eye on the open sourcing of our tooling.

I would suggest using a modern browser, it looks fine in FF 18.

Could you back up your statement with some examples? I have friends with the SII and they are very happy with it.

Be careful about A/B tests, from what I understand Amazon relies on the extensively and they have helped it produce its Amazon website.

Enough said.

If you have two choices one bad and another less bad you will chose the less bad, when instead you may just want to step back and ask is either choice the correct one.

The problem may be down to their poor conversations.

We have both wide ranging general knowledge and focused technical conversations in my office involving groups of people and I would be sad to lose that.

Talk about something that can deliver value or engage people and then the conversations are worthwhile.

" Sarah Houghton 10 Dec 12

The ironic thing is that as a librarian, I can tell you that for the last decade (at least) most libraries don’t enforce “library silence.” We encourage people to talk, to collaborate, to discuss. As long as you’re not annoying the hell out of the people around you, we encourage a low level of conversation and noise. "

I read Justice Breyer as Justin Bieber for a second, I immediately had to double take!

Not if other platforms grow faster than it i.e. Smartphones or Tablets.

This looks interesting but the website seems to lack information, could I have just walked up to this place one day and offered my services as a developer to any idea that took my fancy?

Because it takes time and CPU cycles for them to figure out what is a Type and what is not. They don't know how much memory to allocate to these objects for instance, but now with classes they will know types immediately.

It's called Type Specialization http://dl.acm.org/citation.cfm?id=1542528

I'd bet you they will allow browsers to optimize their compilation steps, so they are more then just sugar.

Why is that not the default way to access preferences? It just seems so much nicer than a dialog box. Death to all dialog boxes.

We build online trading applications with KO (we use it only for the view, we have our own Presentation Model were we have observers which pretend to be KO observables) and we have found it quite helpful.

The components built are FX tiles, trade and order tickets.

If Mozilla succeed then there will be a common standard for all developers to code to, there will no longer be any worry about an app not working on Linux/MacOS because the targeted environment is the browser.

The browser becomes a VM, in fact it's already one but they want to make it far, far more powerful. This is a very good thing.

Correct, this looks like a less capable Popcorn.js