TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

State of the Web: Deno

147 点作者 markhaslam超过 3 年前

14 条评论

Sirikon超过 3 年前
Think of it as Node.js + Typescript, but you don&#x27;t have to think about configuring the typescript compiler, linter and formatter as everything is bundled in the `deno` binary.<p>Don&#x27;t think about syncing that formatting&#x2F;linting&#x2F;import aliases configuration with VSCode, all you need is the Deno plugin and you&#x27;ll get all the benefits of working with TS on VSCode.<p>Packages are obtained (and heavily cached) from any URL instead of relying on a centralized repository. Obtain your dependencies as you want, whether it&#x27;s Deno&#x27;s proxy, directly from raw.githubusercontent.com, your own http server, or any other thing accessible thru an URL.<p>At the end, the permission system is the least interesting part of the project imho. It&#x27;s useful, because if you&#x27;re doing a CLI that just receives stdin, processes it, and prints to stdout, you can block any disk and network access, but apart from that it&#x27;s really limited because the nature of JS itself. (Maybe for the next trendy language we could think about the Object-capability model before it&#x27;s too late. <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Object-capability_model" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Object-capability_model</a>)<p>The thing I value the most is consistency and having a fully working development environment out of the box to be productive.
评论 #29875691 未加载
评论 #29875817 未加载
评论 #29875465 未加载
goldsteinq超过 3 年前
Deno’s permission system is broken, you shouldn’t rely on it. Deno developers consistently ignore security issues, high priority bugs take months to fix.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;11964" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;11964</a><p><a href="https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;9750" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;9750</a><p>API-based access control can’t possibly work because it’s nearly impossible to predict the effect of any single permission. For example, “permission to run specific command” makes no sense without checking the integrity of the binary, controlling the environment for LD_PRELOAD-like hacks and evaluating the code of this command for possible escape hatches. If you want to isolate a program, you need to do it on the OS level.
评论 #29872440 未加载
评论 #29871729 未加载
评论 #29872089 未加载
评论 #29875615 未加载
评论 #29871694 未加载
eyelidlessness超过 3 年前
&gt; V8 is a sandboxed language<p>False, V8 is a JS runtime with sandboxing built into its core design. It’s not a language and it doesn’t guarantee sandboxing the JS runtime.<p>&gt; that makes it impossible<p>False, breaking out of the sandbox is trivial in environments which allow native addons.
评论 #29872321 未加载
评论 #29871632 未加载
pjmlp超过 3 年前
Deno is an interesting experiment, but I don&#x27;t see it ever replacing nodejs, beyond the nodejs ecosystem eventually adopting it.<p>It is the usual case of worse is better, and nodejs for better or worse, does it job.
评论 #29872128 未加载
评论 #29871548 未加载
评论 #29871928 未加载
评论 #29875679 未加载
wruza超过 3 年前
I&#x27;d like to use some modern common ground for js&#x2F;ts development, but the entire toolchain is not ready for this, somehow turning it into chicken&#x2F;egg problem. Typescript, webpack, babel contribute to that. For last 10 days I tried to pull my generic project as much to the top as I could^, but modules are still commonjs, because to use imports I have to &quot;type&quot;:&quot;module&quot; in package.json, which makes webpack.server.config.ts fail because typescript is not ready for type:module until 4.6. I can&#x27;t even recall now what&#x27;s with Babel, I guess the same issue, since I&#x27;m using it to strip types in development builds. And then there are modules from ESM movement which are incompatible with this state of things. I understand their idea that nothing will move if not kicked further, but I hate it in real production where I can&#x27;t upgrade because the author said so. Once ESM transition will be done, Deno will get much more modules, I believe. But right now the friction is unbelievable. Idk why they can&#x27;t just allow all of the things like imports, requires, sync&#x2F;async, side effects thing at least for a while, to cooperate. It&#x27;s a matter of a form, not of a content. And there is no reason seemingly why nodejs couldn&#x27;t make main.js async by default — sync modules would return a resolved promise. There is so much circus in all of that, which makes you pull hairs for weeks of a setup process.<p>^ I&#x27;m bundling server-side for hmr&#x2F;watch functionality in a monorepo with many cross-side shared code&#x2F;modules.
评论 #29881372 未加载
评论 #29872426 未加载
u-rate超过 3 年前
Love Deno. So much much more intuitive and simple than Node. I highly recommend you giving it a try, if you used Node before, Deno will be a super easy to learn tool.
评论 #29872666 未加载
bartkappenburg超过 3 年前
Offtopic but this webpage disables my bottom navigation bar on mobile safari, their own navigation on top re-enables this. Has anyone else experienced this?
评论 #29871959 未加载
andrewmcwatters超过 3 年前
Now instead of npm packages abusing SemVer unless you use non-default --save-exact behavior as an attack vector, we can import modules from URLs without subresource integrity unless you use non-default lock file behavior! Great! We learned nothing!
评论 #29877331 未加载
Waterluvian超过 3 年前
Deno’s import system is near at first until you are repeating yourself everywhere, so you do what they suggest and make a file of import URLs and now you have your own package.json format.
a99c43f2d565504超过 3 年前
Node.js fully supports ECMAScript modules as they are currently specified and provides interoperability between them and its original module format, CommonJS. Authors can tell Node.js to treat JavaScript code as ECMAScript modules via the .mjs file extension, the package.json &quot;type&quot; field, or the --input-type flag.
dmitriid超过 3 年前
Mentions security and then completely glosses over security in the section on &quot;yeah, we load random modules from URLs but it&#x27;s okay because most Deno registries are immutable and we cache files&quot;
评论 #29873414 未加载
评论 #29872434 未加载
评论 #29871603 未加载
Kiro超过 3 年前
I prefer CommonJS. It&#x27;s so simple. You assign the dependency to a variable and that&#x27;s it. I still need to look up the syntax every time I use ESM.
评论 #29871602 未加载
评论 #29871589 未加载
galaxyLogic超过 3 年前
Why is it that ES6 modules load only asyncly but Node.js CommonJS modules only syncly?<p>I find sync is often simpler to code for.
评论 #29871486 未加载
评论 #29872132 未加载
minroot超过 3 年前
Wanted to install deno via cargo. It failed due to having low amount of memory while building V8.
评论 #29872418 未加载