You certainly can do this. Though keep in mind that your functions are running on Windows, so make sure to compile your native binaries to target Windows.
This is super high on my priorities since I still at least attempt to impersonate a Node dev. I can at least sleep at night knowing I didn't launch a product on 0.10.x. :)
As a heads up, node will pick up destructuring the next time they bump v8. That's the last feature keeping me on Babel so I expect adoption to be fairly quick.
I primarily use Firefox for browsing, but for development I usually use a mix of Firefox and Chrome.
It might be just me, but it's very common when I use the JavaScript debugger in Firefox that it either freezes the site, the debugger, or Firefox itself. That causes me to give up and head to Chrome.
I also wish they put a visual queue on the web page when you pause the debugger like Chrome does. Everytime the site get's unresponsive I have to click around few times, wonder what I screwed up, and then realize that the debugger was paused.
> It might be just me, but it's very common when I use the JavaScript debugger in Firefox that it either freezes the site, the debugger, or Firefox itself.
If you have a test case and steps to reproduce, please file a bug! We can't usually fix the bugs we don't know about.
It's just very inconsistent. It just happens sometimes and I either restart firefox or close and open the tab and it goes away. I can try to take a memory dump when that happens. I don't know how useful that might be for you. If I ever get something consistent I will make sure to file a bug.
Thanks for all the amazing work though! nothing beats the visual tools and network traces in Firefox.
I think you may have fixed it since I haven't had a problem in awhile but I sporadically had problems where the debugger didn't trigger on a break-point after awhile in a long debugging session. Is there a way to report heisenbugs like that which isn't going to waste your time?
For crashes, definitely submitting the crash report found in about:crashes helps a ton.
Checking the browser console for an error message + stack and pasting that in a bug + description of bad behavior can be useful.
Finally, in extreme cases you can enable all the devtools logging[0] and then run firefox while piping stdout into a log file. This is a firehose of information, but it should hopefully point to the part of the code base that is misbehaving.
While that is absolutely true for IIS and the Shared tier in Azure Websites (although it's fully configurable if you own the IIS box[1]), Dedicated tiers (when you own the whole VM) in Azure have a feature called Always On[2] Where there is no idle Time-out on the app itself, so even if the app remained idle for days, w3wp process won't be killed. Also if the app happen to shutdown for any reason (machine restart, Azure Update, Windows Update, app crash, etc) Azure Websites will make sure to send a request to the app to start it up and warm it, then the app can use Application Initialization[3] to do any more complex warmup
I think he is referring to running different versions with different CLRs side-by-side. It means Platform-as-a-Service friendly. Since in PaaS you usually don't own the machine, you just run code somewhere. You don't want to be tied in with is framework X installed on the machines or not. You want to be able to pull in what ever framework you like, as you would do with node.js for example
I sort of remember that the core CLR didn't really rev that much, in that it spent the longest time on 2.x, with only the data access technologies built on top changing what seemed like every other week. LINQ was the next nice additive.
I don't recall exactly why now, but I know that the term 'strong naming' can still instill terror in me. I guess that all goes away if you can distribute a statically linked lump per app. The cycle continues..
