izym

Latency is certainly not 1 ms for a video frame in desktop resolution. It also means lower visual quality due to the fact that video compression would be needed to make it even slightly possible. Also, how many people actually have a GbE connection to the internet?

If you can barely get 1 request through, it might take a long time before the JS will load and run, as it has to load completely before running at all.

You're using the wrong tool for the job. Front-end JS frameworks do not mention how to get data from a database, because it's completely out of scope. Take a look at server frameworks/libraries like Rails, Phoenix, Express etc.

Sure it could. But this is also about providing a better user experience. Being able to automatically split the bundle into parts, the most needed of which is loaded at first and the rest then loaded afterwards in the background using a service worker, means that navigation will be far more snappy and provide better feedback to the user. Rather than waiting for the HTML to be downloaded when a link is clicked, most of the UI can be displayed while a smaller payload is downloaded. Obviously if your content is 100% static and your target group is people who only have 2G available, this might not be the best choice.

> then things like the back button after scrolling through the blog would work.

What do you mean?

> Why try to outsmart the browser?

Not sure how this is outsmarting the browser.

I think that depends very much on the suite of apps you use. There's plenty of apps where the scaling is rather broken and seriously takes away from the experience.

This one isn't Electron based, but rather it uses QML (i.e. Qt Quick).

I'm not quite sure how those two threads indicate technical debt. Could you elaborate?

References don't allow null.

Might I ask what company? Or at least which country? It sounds very nice :)

I can highly recommend the Dell XPS 15. I too was in the market for a laptop with a mediocre GPU, which didn't look absolutely terrible, was affordable and not too bad on the whole portability thing. So far it has definitely lived up to my expectations.

I can recommend getting the 1080p version (but not the entry-level model, as that one has a smaller battery and no discrete GPU), unless 4K is very important to you and you know what you're getting into wrt. high-res scaling in Windows.

Do also look at the recently released http://vulkan-tutorial.com.

It seems I was a bit too fast. I meant to write C++ and not C.

C has just as much fine-grained memory support as Rust. Rust does however have better memory safety with its borrow checker, but I'm not sure if you could implement something like this without unsafe.

This is what was previously the vkcpp project from Nvidia, which seems to have been transferred to the Khronos group.

How doesn't it work and how does that transfer to Vulkan?

Yep :) Or more precisely "the fast route".

The point is to take APIs that don't and wrap them with said classes, not to provide an alternative.

Nope, it's "hurtig".

Your question could definitely have been more neutral. I think most people read it as you trying to invalidate the article.

Was it ever meant for general web usage?

You should have a look at the Conan package manager. It'll allow you to use Boost (and other libraries) rather easily in your project.

I think so, yes. Personally I'm really looking forward to seeing what people are going to implement with WebAssembly. Another possibility would be virtual DOM diffing.

The WebAssembly VM is already there. It's the same VM as is used for JavaScript.

How about not requiring a plug-in?

WebAssembly will eventually have access to the same APIs as JavaScript does now. Then it's just a matter of using an ES2016->wasm compiler rather than an ES2016->ES5 compiler.

Serving a binary file is in principle no different than serving a string file. What can be done with WebAssembly today can most likely also be done with asm.js.

From what I could see, you don't. Rather it seems like they're just putting the render on top of the video, which fully occludes the blackbird.

It'll be interesting to see how things develop with HIP (http://gpuopen.com/compute-product/hip-convert-cuda-to-porta...)

Somewhat, but with more (forced) automatic resource management.

Mantle is not proprietary. Metal being usable before Vulkan doesn't exactly make up for the complete lack of Vulkan support and anything past OpenGL 4.1.