anotherangrydev

>WSDL/SOAP are not REST

Well if you define REST as "Web Apps developed with RoR" then I guess you're right, Rails is definiteley the pioneer of Rails development.

>You've yet to refute that argument

There was (at least) Tomcat deployed and quite popular, and yep, everything moved through REST interfaces. Even with that one and the huge success it had in the enterprise world, I wouldn't dare to say that the success of REST relies on Tomcat anyway.

REST hit it big with the www, www is REST's killer app. Those things are quite literally the first ones you should know when you start developing for the web.

2006? Come ON!

How about the whole WSDL/SOAP services that appeared way before that? You're telling me that Rails was the one who came out with the modern REST ideas?

That's total tech illiteracy right there. Damn, you even had the nerve to defend that feeble argument.

REST was either popularized or outright invented by Ruby?

What the f* are you on? Or were you born a few years ago and just worked with Ruby since then?

Really, how could somebody be so oblivious to this field in order to state stuff like that?

Tell her that two wrongs never make a right.

Even if it were a database of known murderers (or sex offenders , or whatever crime you consider to be the worst), it is still private information. So it's a shame that those 'hackers' got away with it.

Good, thanks.

Do you override 'require('fs')' or do you do some magic at the OS level ?

I was impressed by the Time Travel.

If I delete a file through there, and "go back in time" would the files would still be there?

Don't be so naive. Do you think you can just walk up to Mozilla and tell them: "Sup guys, just bundle this crap into your browser. Please."?

It is not valid. I found it amusing that it even went through.

And its pretty much the same thing now.

Try WebGL on any Mac (Safari is the worst performer of them all btw). You will see a bit of lag, frame drops, CPUs at 100%, a lot heat and your battery will die in two hours max.

Open the same site on a Chrome/Windows machine (with comparable specs of course) and you don't see any of that trouble.

Why? Because Apple wants everything done "The Apple Way®©™" and other people just don't care so they just create a substandard implementation and call it a day. And it's only going to get worse now that they want to push Metal everywhere.

How many different HR departments?

The runtime is pretty awesome as well. I remember the work of people like Joa Ebert exploiting the platform and the language to the max, really cool stuff. The world is barely coming closer to what Flash was capable to do... 8 years ago.

IMO Apple killed Flash not because of the "battery, security, etc..." "issues", but because they didn't want their devices to depend so heavily on another company. It was business, and strangely, Adobe didn't even put on a fight. And they just spread FUD and all the developers that didn't know better went with it, but I agree with you, shitty flash developers will now just be shitty HTML developers and everything will be the same in another 5-6 years or so.

Ok, thanks. Haven't read the spec, that's why I was asking.

>However, the general consensus is that promises should be part of the microtask queue, and for good reason.

That's the only bit I found in the post regarding that. Didn't sound like 'it's in the spec' to me.

Regarding the example, (I'm gonna sound like the SO posters that I hate but) there are other appropiate places where you should hook up that callback. If the one you chose does not play well with Promises yet (because you want to access an object thats at the end of its lifetime and not guaranteed to exist), then ¯\_(ツ)_/¯.

I asked for an example where the program breaks because I thought that if you queue up things 'for later dispatch' you shouldn't be worriyng about the order where they dispatch. If you're actually worried, then chain them together with the classic callback stuff.

But, I'm not demeaning your post (I see you're the author), it was really good. The main issue is see is (as you stated in your comment) that Promises as microtasks would increase their performance. It is a shame, however, that we as developers are not able to queue microtasks directly (like when using setImmediate, process.nextTick) :(