Bug in Visual Studio 2015 JavaScript Node.js debugger. In the following both variables "xx" and "yy" show in the "Locals" -inspector. But when I halt inside the inner block, only "bb" does, "aa" does not.

function testLet ()
{ let xx = 123;
var yy = 321;

if (6 < 9)
{ let aa = 123;
var bb = 321;

Post has attachment
Customization flexibility has always been an integral part of Auth0. Today, we are introducing Auth0 Hooks, a new and improved mechanism to extend the Auth0 platform using NodeJS, powered by Webtasks!


Post has shared content

Post has shared content

Post has shared content

How can i build a rest api with nodejs without express??

Arrow -syntax could be shorter

The ECMAScript 6 arrow-syntax is great for making code simpler, easier to write easier to read, easier to understand. However I think it could be made even shorter.

I can now write "a => new Date()" to create a simple function which returns a new Date representing the current date and time. I don't need to write "function" any more to create a function, as was the case before ES 6.

However you may wonder what is the "a" doing in "a => new Date()"? Nothing really. It just seems some argument-name must be provided before the "=>", always.

What I would really like to write is " => new Date()". That would be just as clear and in fact clearer because the unneeded argument-name is just noise, is confusing because it is not used for anything after all.

We can write :
function (){return new Date()} // no args!

so why not also:
=> new Date() // wish this would work

EcmaScript-6 arrow-syntax is a great convenience. But I think there's room left to make it even better. Or who knows? Maybe there's some good reason why the argument-name always must be there, even when not needed.

Post has attachment
Needed: "errorOnFailedWrite"

Setting writable to false in Object.defineProperty() makes it impossible to replace the value of the property afterwards, as explained in the documentation below.

But when you try to assign a new value to it it SEEMS to work. There is no error, the assignment simply silently does nothing. Reading code like that then is very misleading. You see an assignment, which doesn't do what it seems to be doing. That's a recipe for misunderstanding the code, which is a recipe for hard- to-fix bugs.

This would even seem to be a security concern, code not doing what it "says". Hard to find hacks in such code, the behavior being hidden in some defineProperty -statements somewhere else.

It seems as if it is possible to modify the semantics of the assignment-operator by using defineProperty().

I think this should be changed in the standards, or if that is impossible because of backwards-compatibility by adding a new configuration attribute "errorOnFailedWrite", or something.


Post has attachment

Post has attachment
Wait while more posts are being loaded