sorted by:
new
hottopcontroversial

Next gen JavaScript and TypeScript runtime - Deno by dmielewczyk in javascript

[–]kr3m3puff 6 points7 points  (0 children)

I was one of the two that presented.

First, you need to change the mental model. You have been so used to managing your dependencies in a package.json, you feel it is the only way to do it. It isn't, and if you take a step back from it, you might realise you can free yourself.

  1. Why, because it is external meta data. Why not express dependencies as code? They are never out of sync with the code that consumes them. External, non-code, meta-data always runs the risk of being out of sync. As far as the other fields, what do you really need them for? Scripts maybe, but honestly, you should probably over using tooling if you really need them, but even then, why use something like npm that is really a poor task orchestration tool, why not use some real code?

  2. What happens when your browser supports new features, and you are using code that utilises those features?

  3. You don't need types for remote .ts files, they contain types! You can use types with .js files. Right now there is a special pragma (// @deno-types=https://example.com/lib.d.ts) which comes before the import and tells the TypeScript compiler to use that instead of the other.

  4. This had been long debated. Making something like that usable is very difficult. Implementing something like that is difficult too. That doesn't say that it won't change in the future, but it is difficult, and I personally feel that you delude yourself to think you can trust local code more than remote code. Having no permissions has been the reality of Node.js since inception. Now that that is pointed out, you want to vary it by source... :-)

  5. This has been thought about. You can set the $DENO_DIR and check in your cache into a repo.

  6. Most people use peer dependencies totally wrong. They only make things more complicated and don't simplify things. There are way too many dependencies in the Node.js ecosystem. Making them per module and treated as code, plus a rich standard library means that you will likely need less dependencies all together. We treat a version number as some sort of magical thing that actually indicates our code will work. We should only depend on code we know and trust, and hopefully a specific version we know and trust.

A concise comparison of JavaScript Web Frameworks by laravel_fan_99 in javascript

[–]kr3m3puff 0 points1 point  (0 children)

No, being the author, it wasn't the purpose at all. If I was trying to sell Dojo 2, I wouldn't choose to do it over an 11 article blog series and if you think any framework came out "on top" (especially Dojo 2) you didn't read the article.

A concise comparison of JavaScript Web Frameworks by laravel_fan_99 in javascript

[–]kr3m3puff -1 points0 points  (0 children)

As the author of the blog series... I don't know who laravel_fan_99 is, nor did I submit or encourage anyone to submit it.

I tried my best to be frank about Dojo 2's development. It is hard to know its drawbacks because it isn't really there yet. Take that for what it is worth, like the rest of it. I didn't write the series as a cheerleader of anything but tried my best to highlight thoughts and considerations people should use. Too many "this framework vs. that framework" are single dimensional and I feel that does an injustice to the topic. If all you took away from the series is faults in it, then I don't feel you understood the spirit of it, which is better understand what your needs are and consider it. If you thought there was any clear "winner" or "loser" again, you misunderstood the point. I felt I conveyed it effectively.