I am Frank Lemanschik a German Engineer sticking with JS since it exists I started Computer Science in the late 80th and I was always amazed by the concepts of HTML + JS because I know how BTX was made :). I am Also an IRC user and Server Operator since it got public. I learned coding via Reverse Engineering the Hardway without knowing any fundamentals to be more expressive i was interested and successful in cracking Software Protection Systems and also edit Software that only existed as binary code! My Most Famous Example is the Diablo Trainer that was really successful in network coffees to save the current game state while the cheating abilities should not get used. I disabled them in the binary representation via a Hex editor I found the check fields in the code and was able to grey them out. I also was able to rename the Title. Because i knew the rules of HEX Code from my cracking history.
I was, for example, the teacher and also friend of https://en.wikipedia.org/wiki/Razor_1911#Dycus he was from the same city and was hanging out in the same network coffee bar that i was hanging around. I showed him how to learn code and cracking and then introduced him to the Scene.
Why do I point all that out? I only want to make clear that I blooded and made my hands dirty with really scary stuff! I swear I am so passionate that I cry when I can't solve a problem before I now start to tell you my opinion about NodeJS Deno and the future of ECMAScript this should be kept in mind because I think it's important who says something.
because it has again to much stuff in it that is regretable the rusty_v8 bindings are the real good part about that and the deno project is a good example., also the go binding v8worker2 is value able.
Software at Present is shit most times. Near every Project that I see now on the wild even when it is really neat and solves complex stuff right look in code most time like a city that got hit by a nuclear strike.
Its Simply overwhelming. a good Example is Parser5 a relatively good npm package using CJS Src. Simply watch the source of it if you feel comfortable you are doomed.
I agree with his concepts in total!!!
- Using Package.Json is not the best idea but at present, it offers a compatibility layer till all adopt.mjs
- node_modules should only get used for build and prototyping all dependencies are dev dependencies.
- restricting network, filesystem providers and so on is a good concept I did an extra project for that https://github.com/direktspeed/es-permissions
- Everything should be ECMAScript 6+ with JSDoc I don't agree with typescript .ts at all I find it hard to read for new coders and its boilerplate
- no index.js or let us call it no nodeResolve should get used using absolute path is well
- using parcell download cache and run is a bad concept while I understand his intentions.
- using modules from the network via https or file protocol is totally ok for me i coded esm-loader for it https://github.com/direktspeed/esm-loader
- concept of send, recv is implemented inside nodeJS workers already and allows to apply security concepts well and fast
- blocking the loading of modules is easy to do able via custom-loaders and hooks.
- gyp is right hell but it doesn't need to get used often and maybe a send recv API can get added additional n-API is a good effort.
- running inside container docker/firecracker solves even more isolation problems while keeping the caps untouched.
- your source should be in Valid ECMAScript with .mjs extension
- static type checking via typescript checkJs true and JSDOC annotations in your code.
- package.json
- Only devDependencies
- { "type": "module" } //is the future use commonjs for backward compat
- vscode don't support .mjs right because of typescript it needs .mjs support workaround is use package.json with type module and then .js at present till .mjs support lands in typescript
- don't do import without extension don't use package JSON or any lookups in your own code
- use rollup to build ECMAScript bundles that are consumed
- dev should not get packaged and stay in git
- bundles should work without package.json
- if you want to use node_modules as vendor maintained packages be aware of the fact that they are not clean coded go for es-modules
- modules can be fetched how you like it via wget or any method and then get bundled up.
- run inside a container engine to apply isolation and do awsome repeatable infrastructure that scales.
if you follow these rules your Project is Awsome! You Tackled yr with his product NodeJS Deno is a nice experiment it can get a good education point how to embed v8 but NodeJs is as of the time of writing 12.Feb 2020 the better V8 runner.
- Regret: Security. ...
- Regret: The Build System (GYP) ...
- Regret: package.json. ...
- Regret: node_modules. ...
- Regret: require("module") without the extension ".js" ...
- Regret: index.js.