davrous

This is a fantastic concept! It's going to be super useful to map users' intent to API / code in a super reliable way.

Indeed! Web developers can have a huge impact!

By the way, the Bing Covid PWA has been published to the Microsoft Store using Pwabuilder.com ;)

I strongly disagree. You have access to a lot of API and even more thanks to project Fugu. We have Web Assembly (WASM), WebGL 2 (soon WebGPU), etc. Check out this article: https://www.davrous.com/2019/10/18/myth-busting-pwas-the-new...

Hey! I see a lot of confusions on PWA on what they can or can't do in the comments. I've written an article trying to address that in a fun way: https://www.davrous.com/2019/10/18/myth-busting-pwas-the-new... by busting 9 common myths on Progressive Web Apps. For instance, they can use WASM which is production ready for years in all browsers!

Thanks for this feedback. We're thinking about hosting a blogging platform directly under pwabuilder.com. We've got a small team that was mainly focused on writing new features & code but we definitely need to better address our blogging approach.

They can thanks to the Native File System API coming with Project Fugu: https://web.dev/native-file-system/. Available via origin trial for now but it should be soon released more broadly.

Firefox seems to have a lot of Web Audio bugs. I've already pinged one of the developer of the web audio stacks on Twitter. But I probably need to open a firebug request also.

Our Web Audio engine runs fine in Chrome & Spartan.

Hello,

Yes, there's plenty of reasons. First of all, babylon.js for instance, has been made specifically for the web. It's been tested on all browsers & on as much mobile devices as possible. Our shaders architecture has been made for that: to run on as much platforms as possible, mobile included. We're also spending a lot of time optimizing the performance for the web browsers and we're taking into account some of its specifics: offline via IDB, support for multi-touches (Touch & Pointer Events), streaming of assets, GC friendly, etc.

We have plenty of tools to help you testing the behavior of our engine and your code in the targeted env, the web: the sandbox tool, the debug layer, emitting user marks for F12 tools. We even have something we’re very proud of, our playground: http://www.babylonjs-playground.com/. Test & debug your code directly in the browser. Learn by experimenting in the target platform.

Moreover, babylon.js is free & open-source. You can debug your game and our engine directly in the browser. You can tune our engine to your needs if wanted as you have access to the source code, fork it and do whatever you want with it. You’ll also write the logic of your code in pure JS (or any great compiler like TypeScript or CofeeScript).

Babylon.js offers then a pure web experience. You can customize everything you want, handle the UI yourself with the ton of existing libraries, add some cool CSS features on top of it, mix it with SVG. Well, it is the web. Last but not least, we have almost finished our Unity exporter to Babylon.js that will dump all the graphics & sounds assets from the Unity scene to our .babylon format. It even seems much more efficient that the Unity 5 export.

Well, you see that this is a completely different philosophy. On the other hand, Unity 5 benefits from a huge community & assets. But creating a simple scene with a couple of meshes could take several minutes to export to WebGL and create up to 100MB of JS! And it's a very specific JS based on asm.js that can't be read by human nor modified. Plus it will only run correctly on Firefox (soon on Spartan too). At last, you will have to write the logic of your game in C#. But it’s a real great option for games developers that don’t master the beauty of the web. Unity is doing everything for them.

Conclusion: Unity 5 targets people with games already built for mobiles and will offer a very specific WebGL option. It's closed source. Babylon.js targets web games developers that build games specifically for this platform. It's free & open-source.

Note: I'm probably not objective as I'm the co-author of babylon.js ;) But I'm sharing my vision.

You're right. Looks like our server has difficulties to handle the load. I'm going to work on hosting it elsewhere.

Once it's loaded, it should be faster to reload as we've implemented support for offline via IndexedDB.

Yes, I am. :)

We have great things coming on babylon.js in the next days. It's mainly a personal project we have as a small team with David Catuhe, Michel Rousseau and Pierre Lagarde. We have great feedbacks so far!

Hi! To avoid having too long loading time, we have the support for incremental loading. But we definitely need to work on optimizing the size of our scene format also.

Please note that we've also worked on a companion framework named GameFX: http://blogs.msdn.com/b/davrous/archive/2013/07/23/introduci...

As Babylon.JS, it's open source, mostly done on our free time and works well on every platforms supporting WebGL such as Chrome, Firefox, Opera, Android, Firefox OS and of course IE11 (win 8.1/RT).