91–100 of 151 posts
I assume that permissions are given at application level, not at module/import level? This means that if I write an application that requires filesystem access and has external dependencies, I'm essentially giving them access to the filesystem even if they don't need it. These dependencies could silently check whether they have permissions and do something fishy only if that is the case. It would be nice to be able t…
Earlier quoted context omitted.
I dislike javascript for much the reason you love it. Promises just mean having to manually build and manipulate cooperatively multitasking green-threaded call-stacks. It was a dirty necessity following the inability of the earlier callback patterns to manage the level of complexity people were attempting to express in the language.
As someone with most of my coding experience in JS/TS, what would you say is a good alternative to explore?
> Javascript is great. But... in saying that it has a few quirks and can work in some unexpected ways. Typescript has just as many[1] (in fact more, as it's a superset) quirks than Javascript. I like using it (and it makes JS type-safe-ish), but it's not really some kind of paradigm shift. Not sure how I feel about import maps. They are quite literally the same thing as package.json. In fact, converting between the t…
Frankly I find TypeScript with strict mode turned on to be a safer and saner than C# and Java because of explicitly nullable types alone. I _never_ get null pointer exceptions in my own TypeScript code. Combined with fairly strict ESLint you get something that catches a lot of problems at compile time. Of course it's still far cry from being as safe as for example Rust. And yeah the inconsistency of JavaScript/TypeSc…
For me this is a case of "too little, too late". I've been burned too much over the years by the Node ecosystem to risk investing any further interest in it now, even if it has marginally improved. I have worked extensively with Typescript, which I consider to be the minimum viable solution within the Node ecosystem. Typescript shouldn't even be seen as a 'nice-to-have. It should be seen as a required remedy for some…
This doesn't make sense to me. Javascript is a breath of fresh air after writing async code in almost every other ecosystem from Go to Java to Python to Swift. Pretty much any async code snippet in those languages can be improved by porting it to Javascript. Async/await + the ubiquitous Promise make it my go-to choice for writing anything networked. Especially over the other popular dynamically typed languages.
There are many ways of doing I/O, but nowadays everyone seems to do everything async without giving it a second thought.
Deno is on my list of tools to play with. It's sandboxing capabilities are the main selling point for me because it will allow executing semi-trusted/un-trusted code on private data sets. If I know that the code can't access the network or do anything fancy with the file system then I can treat the untrusted code as a pure function and know that the output will only depend on the input. This is a very desirable prope…
I like the concept of Deno, and especially love the shift away from NPM. NPM was probably the main reason I never fully embraced node.js. I truly hated the bloat of the modules folder, and the impending fragility the dependencies would bring. I like the idea of a standard library. This will hopefully only improve with time. It sort of brings the ease of use factor of PHP to a server side JavaScript environment. I'll…
The set of core libraries like express (fka connect) + dependencies is the stdlib. It was developed in early node.js days as part of CommonJS, which was an initiative for a portable/modular server-side JavaScript runtime with many implementations besides node.js (RingoJS, Narwhal, Helma, TeaJs/v8cgi). The existence of a community-driven lib effort, the portable nature of JavaScript, and the existence of choice was th…
Node got popular because it enabled frontend devs that only knew JavaScript to move easily to backend, not any technical reason.
This comment is a meta-critique on the blog itself. I've noticed a recent trend arising on the web of applying a text shadow to code to make it seem like it's glowing. I don't know where people started thinking this was a good idea but I hope it doesn't gain too much traction. When I saw it in this blog, I blinked and rubbed my eyes because I actually thought my vision was blurring... Another nitpick which may be tot…
Earlier quoted context omitted.
I dislike javascript for much the reason you love it. Promises just mean having to manually build and manipulate cooperatively multitasking green-threaded call-stacks. It was a dirty necessity following the inability of the earlier callback patterns to manage the level of complexity people were attempting to express in the language.
As someone with most of my coding experience in JS/TS, what would you say is a good alternative to explore?
The example on permission isn't great. It said the library you used cannot access your database password from env and send it over the internet unless you allow so. When you're putting database password in the env, most likely you need to permit env var and network access for your database client library. Then at the same time, the library in example can do that malicious thing. The problem here is, deno request the…
It's not as fine-grained as allowing libraries specific permissions, but it gets you part of the way there.