Deno v1.8 – support for WebGPU, private modules, Intl, and much more
deno.land
deno.land
I understand why. The extremely proprietary and platform specific nature of graphics APIs and hardware makes it hard. WebGPU is a good choice for portability.
It will be nice to finally have a portable 3D API that's sanely designed (unlike OpenGL) and that non-experts can be expected to handle (unlike Vulkan)
I'd love the multi platform support of OpenGL with the features all the new APIs bring.
to me both look similarly horrifying:
http://austin-eng.com/webgpu-samples/samples/rotatingCube?wg...
I cannot pin it down but there must be a better way, this looks like the server world before the invention of ruby on rails.
Also magical values in string format:
primitiveTopology: 'triangle-list', const swapChainFormat = 'bgra8unorm'; ...
132 lines isn't really that much for a triangle in any 3D API, except 90's style OpenGL 1.x (which was a nice and convenient API, but also very inefficient).
I'm sure there will be plenty of high-level Javascript libraries built on top of WebGPU which will cater to different philosophies and use cases, and those will also allow a Hello Triangle with fewer lines of code (but also will involve compromises at flexibility or performance).
WebGPU is not much easier than Vulkan, simpler yes, but still too much boilerplate to set everything up and running.
As traditionally in all Khronos APIs, the step from "I managed a rotating cube with gourad shading", to loading a game scene with PBR material, is a gigantic step full hunting for libraries and trying to put them together, somehow.
It is no surprise that even with WebGL, most people end up picking ThreeJS or BabylonJS, after getting their first triangle.
Yet. Middleware renders the "portability"[0] of Khronos APIs a moot point, by having the best 3D API for each platform hardware, while at the same time exposing a more developer friendly infrastructure.
[0] - Anyone that was used Khronos APIs in anger across multiple OS and GPGPUs, knows the painful way of multiple code paths due to extensions, driver and hardware workarounds.
The attempt to create an OpenGL SDK repository was a joke, and the best Vulkan SDK can offer is a tool to avoid loading all the layers by hand, as it reached the same extension spaghetti as any Khronos API.
https://www.khronos.org/ktx/documentation/libktx/index.html
But for cross-platform code it makes more sense anyway to use an independent cross-platform image loader library, instead of depending on the platform-specific utility APIs provided by D3DX or MetalKit.
I did my thesis porting a particle engine from NeXTSTEP into Windows 98, and was big into OpenGL for a couple of years, went through the Longs Peak drama, eventually my focus switched to other 3D APIs by the GL 3.x timeframe.
[0]: https://bugs.chromium.org/p/project-zero/issues/detail?id=20...
Edit: I believe the bug you linked below (https://bugs.chromium.org/p/project-zero/issues/detail?id=20...) can't be exploited through WebGL or WebGPU in the browser because all GPU access is remoted to a separate process with a special GPU sandbox. I don't know if Deno does this but it should.
And hardware bugs, crappy drivers, etc
This is breaking all the code which relies on deno.land/std and deno.land/x registries too.
In the meantime, you can rely on other module registries or cdns:
You can also use raw github links but don't do that in production.
https://www.cloudflare-terms-of-service-abuse.com/streaming....
This is on the Business tier too, not the Free one.
(i have no personal experience with popular sites personal/free-tier sites sadly)
Doesn't load for me either.
Of course these are all relatively easy things to smooth out over time so I'm curious what the experience is like now.
Deno provides LSP now which is what Vscode extension use. Other text editors also work with deno since they can use LSP.
I haven't had any problems with fs APIs. They provide almost everything and any nice utilities can be imported from std.
Testing has gotten a lot better. Bundling and compiling works too.
Support for third party platforms such as vercel, heroku, and other platforms is decent.
Many rails-like frameworks are also popping up.
Overall, I am satisfied.
Glad to hear things seem better now
It provides auto completion for registries and code lens for external code which was missing before, I think when you used it.
On the whole I have been quite happy with it - the VSCode support is now pretty good (and even without proper integration it was still fully usable even if I didn't get intellisense and had some red squiggles around the imports etc), and sounds like this release will improve it even more.
I do agree though that the documentation is a bit sparse - the auto-generated docs are nice enough, but it could benefit a bit more from some more coverage of human-generated docs for some of the more common use-cases... that will come with time I guess.
My main criticism is that the built-in test framework is a GREAT thing to have, but it does not have support for mocking or spies so it is limited in real-world usefulness.
E.g. in my Gopher protocol client, there is not an easy way to mock out the `Deno.connect` built-in function to create a TCP socket so it is hard for me to test failures at the TCP level. I am sure with some gymnastics I can abstract everything away under layers of interfaces and classes and manually inject everything to make testing easier, but it would be nice to just be able to mock/spy out functions/classes rather than have the entire architecture of the project be dictated by the testing framework. There are third-party alternatives that can be used, but I'd prefer to stay as close to "standard" as possible.
This is the major thing holding me back from using Deno more at the moment.
Not being able to mock out a class/function or spy on a particular call etc means that there are large parts of my code/particular situations that are not able to be tested easily without refactoring my entire codebase to use manual IoC and excessive-OO to hide things away under layers of interfaces etc. E.g. I cannot currently mock out `Deno.connect` (....? or can I?) so it is hard to test all sitautions there. Unfortunately this sort of thing (connecting to a remote system) is often quite critical and would benefit hugely from extensive testing.
It would be great to be able to create tests where calls to Deno.connect throw errors, or where it returns 0 bytes, or a special sequence of bytes and so on and so on to verify that my code works - this is the classic sort of `Spy` functionality seen and used extensively in Jasmine et al.
I know there are third-party solutions to this, but it would be nice to see this in the standard distribution.
Just like deno bundles typescript - there is a reasonable expectation to track latest stable typescript features.
Any examples from deno.land/x of what you'd expect from spies and mocks in std/testing?
The use case is to be able to leverage ES6/Typescript but have security built into the assets management. I'm not unhappy with the sprockets pipeline, but I would like to move forward with a modern assets pipeline without having to think too hard about the security implications of using yarn and node.
As for migrating to Deno: you probably will not be able to do this because most NPM packages will not run in Deno out of the box. Your build pipeline almost certainly relies on libraries like gulp/sass/globby, and those projects will need to be ported first (or made compatible by their authors).
Deno provides built in bundler. It is low level but there are third party packages built on top of it.
All the three packages mentioned have equivalent in the deno ecosystem.
Try searching on https://deno.land/std and https://deno.land/x
Manual for built-in stuff in deno: https://deno.land/manual
Now that Node supports ESM, I hope this year will start seeing more migrations, but it will be at a glacial place because the ESM<->CJS compatibility remains extremely brittle (among all bundlers, and for Node+Browser usage). If you are writing a greenfield small library you can make it work. But it will be a long time - if ever - before we see things like @babel work.
I've rolled my own assets pipeline with a Sinatra app, but did not tap into Node.
I think with Rails, there's probably some way to hook into the framework, just not sure how one would approach this.
It's a really good/barebones Roda project that uses webpack for assets/js pipeline and Tailwind CSS for UI. My methodology was:
1) clone the project
2) then swap out webpack for Snowpack
I was able to do that within 1 day and honestly, it was well worth the effort due to the amount of knowledge that come with it. Snowpack is much much faster and efficient in terms of resources vs webpack. The newest version, Snowpack3, uses esbuild internally which basically puts it on steroids. Good luck!
Reference: https://www.snowpack.dev/posts/2021-01-13-snowpack-3-0
FYI, in my dev stack, I'm running Puma server, Sidekiq worker, Snowpack dev server and Guard for live reload capabilities. I'm using Foreman to startup all 4 things using a Procfile and my startup time clocks in at 2.85s from issuing "foreman start". I hope this helps!
That vendors yours dependencies, so the whole project can then be started without yarn itself, but avoids the gigabytes and millions of files problem of node_modules.
Just an alternative.
It would be nice to read a rationale about this.
Python has arbitrary sized integers in the language, which even improves the usefulness.
Of course libraries and extensions could eventually help.
That's not what they stated. They corrected me and pointed me to BigNum.
BigNum is documented in MDN as a "Global Object" https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... I don't find a reference to it in the ECMAScriot standsrd, https://262.ecma-international.org/10.0/
Thus I claim the Python approachbiss till better in that specific area.
I don't know Deno's source for their claim. Certainly relevant is what area of Maths you're looking at. For instance looking at reread rations for vectors and matrices might be relevant for different maths problems. The functional approach in some of these things also might be interesting for some Maths problems ... broad topic :)
I have had a quick play around with it - seems functional. Usual caveats about cross-platform webview apply, but I don't see those as major blockers these days unless you are doing something particularly fancy/niche
I love that you can just run the examples by copy-pasting a command and everything is auto-downloaded via Demo's modules. No installation or huge separate binary downloads. Awesome stuff.
Denying XML support may as well be like denying JSON support at this point.
This is such a great idea.
I’m seeing some very odd behavior. I’ve gone from getting an SSL error, to stuck in loading ‘forever’, to sometimes it loads.
Anyone else experiencing this?
GLSL is compiled by the OpenGL driver. The question becomes is WGSL sitting on top of OpenGL driver and thus requires the OpenGL drivers to support it or with a transpiling to GLSL, or does it has its own WebGPU driver that can compile the WGSL and interface with the GPU directly?
On platforms supporting Vulkan, WebGPU implementations are probably compiling WGSL to SPIRV before handing it to the driver, and a DX12 implementation would probably compile it to DXIL. I'm not aware of any intermediate representation on Apple platforms, so it's probably transpiled to MSL there.