"Of course just looking at what is archievable today, we will have a lack of performance, features and tooling, but thats not how technology adoption and performance increases work"
Well yes, but that's what I mean when I say I wouldn't want to take it to production. Maybe in the future, but it's not ready yet. I think it has some way to go before it's viable, and a long way to go before it competes with the likes of Source, Unreal and Unity.
" imagine developing a product once and being able to ship it to any device"
Always a worrying promise, as you need to write one product that works on multiple, slightly different setups. Browser Y supports the CSS selectors you're using, but there's a rendering issue on Browser Z 2.9.0.1 - 2.9.1.3. Browser X renders it correctly but doesn't yet support hardware acceleration so it doesn't run so well.
It's also not the only cross platform option there is, and I'm not sure trying to target vastly different devices with the exact same code is a great idea. Why would we expect to be able to write a game for a phone with a touchscreen that also works on a desktop with a keyboard and mouse? Why is it better to have one product with internal switches "if mobile..." rather than two with shared code? You've now got a lot of regression testing to make sure you're not affecting the desktop experience when you update something that 'should only change the mobile bits'.
"Additionally: think about the time and cost that go into developing cross-platform engines - is this approach able to compete on a long run?"
It depends on the quality of what each side can offer, and the difficulty in adding to it. A cross-platform game engine can add support for a new feature of graphics cards and be ready quickly rather than having to draft an addition to a spec which you hope the browser manufacturers implement similarly, then watching until the market penetration of the version of the browsers you want reaches the right level.
"The entry barrier into web-based products comparatively vanishes: no downloads"
No downloads? So why did it take so long for me to load the demo? I'd like to know how I can get your product over the internet without downloading it.
"Imagine having a release cycle that always instantly pushes out the newest version of your product to all users in realtime - no update processes on client-side"
Imagine having to load large parts of a game online every time you want to play it, rather than just opening a program. Also, realtime updates? Sounds awful. Fix one JS file and watch the fun as some people load an older cached version, others a new one, others loading in that file on level three after loading the older assets on level two. Something that was loaded 5 minutes ago is now trying to call a function on an object that's been renamed in the latest push. Not being able to load level 4 because the server is under strain...
Well yes, but that's what I mean when I say I wouldn't want to take it to production. Maybe in the future, but it's not ready yet. I think it has some way to go before it's viable, and a long way to go before it competes with the likes of Source, Unreal and Unity.
" imagine developing a product once and being able to ship it to any device"
Always a worrying promise, as you need to write one product that works on multiple, slightly different setups. Browser Y supports the CSS selectors you're using, but there's a rendering issue on Browser Z 2.9.0.1 - 2.9.1.3. Browser X renders it correctly but doesn't yet support hardware acceleration so it doesn't run so well.
It's also not the only cross platform option there is, and I'm not sure trying to target vastly different devices with the exact same code is a great idea. Why would we expect to be able to write a game for a phone with a touchscreen that also works on a desktop with a keyboard and mouse? Why is it better to have one product with internal switches "if mobile..." rather than two with shared code? You've now got a lot of regression testing to make sure you're not affecting the desktop experience when you update something that 'should only change the mobile bits'.
"Additionally: think about the time and cost that go into developing cross-platform engines - is this approach able to compete on a long run?"
It depends on the quality of what each side can offer, and the difficulty in adding to it. A cross-platform game engine can add support for a new feature of graphics cards and be ready quickly rather than having to draft an addition to a spec which you hope the browser manufacturers implement similarly, then watching until the market penetration of the version of the browsers you want reaches the right level.
"The entry barrier into web-based products comparatively vanishes: no downloads"
No downloads? So why did it take so long for me to load the demo? I'd like to know how I can get your product over the internet without downloading it.
"Imagine having a release cycle that always instantly pushes out the newest version of your product to all users in realtime - no update processes on client-side"
Imagine having to load large parts of a game online every time you want to play it, rather than just opening a program. Also, realtime updates? Sounds awful. Fix one JS file and watch the fun as some people load an older cached version, others a new one, others loading in that file on level three after loading the older assets on level two. Something that was loaded 5 minutes ago is now trying to call a function on an object that's been renamed in the latest push. Not being able to load level 4 because the server is under strain...
As I say, it's got positives and negatives.