This is a 20 year old game.

is it ? quake 3 is a 1999 game. It's closer in time to MS-DOS 6.22 (1993) than to Windows 10 (2015)... and it's not even reaching 60fps on my 1080...

I hits 60 fps steadily on safari & chrome on my macbook.

It was already possible in 2011, but alas politics.

https://www.youtube.com/watch?v=UQiUP2Hd60Y

https://adobe-flash.github.io/crossbridge/

... the issues with Adobe Flash are quite a bit more varied than “politics.” At best, it was always a drag on mobile platforms, reducing battery life and hogging resources, and at worst it’s pretty much best known now for its security issues that ultimately helped further its demise. If you want to go a step further, in 2011 you could also have probably delivered your game as an NPAPI extension and got pure native code instead. You could deliver these via extensions, even in Chrome.[1]

Native Client also came to fruition in 2011, and Firefox chose not to support it. I doubt many would chalk that up to just politics, either, but I think it’s fair to compare.

[1]: https://developer.chrome.com/apps/npapi

The first part of this isn't quite correct if I am remembering correctly. Flash (or at least the engine behind it) is still on both Android and iPhone platforms through its app equivelant called Air. There's a lot of things that use Air... to give you an idea, Angry Birds was first written and deployed to Air. So though Apple complained about performance issues, they were not the biggest deal. If I was to take a guess, it was mainly to prevent the web from competing with the app store. So I think his comment is at least somewhat right. Apple didn't want an app store competitor (think Kongregate or Newgrounds competing with the games part of the app store)

Flash on Android existed, and I actually used it, and I can pretty much guarantee you it was never going to be competitive with the way it ran on contemporary smart phones. I don’t get how Flash applets on a website were ever at risk of competing with the app store. HTML and PWA is a more compelling option today than I think Flash ever was, and Apple contributed greatly to that fact with Webkit...

I tried it too and it wasn't the best. But I have a general feeling it was because those particular games weren't really well optimized for the phone. Then again, they were a it more complex than the other games on the phone at the time... but alas.

I'm not sure if it would have grown into a competitor either way. But some people definitely tried to - Kongregate at one point built an app specifically for mobile flash games. Naturally google took it down (you aren't allowed to host 'app stores' on the 'app store'). But it had quite a few downloads. That's just for something on the app store, not directly on a website, but I think the point is that maybe if things had gone a bit differently it might have been more competitive.

For PWAs, yeah, today, they definitely are, but it's taken a long time for them to come that way.

Hope your having a good day.

Of course, though, you can distribute your own app stores on Android via sideloading a la F-Droid and Epic Games. Perhaps in 2011, it just didn’t seem as doable, or maybe sideloading was disabled by more vendors... not sure.

Apple speech I guess.

It was perfectly fine on any Symbian and Android device I got to play with, and much better than J2ME ever was.

One time I accidentally left SpinControl.app on for a week and went about my business (SpinControl, RIP, was an app that logged stack traces any time an app didn't flush its event queue for more than a few seconds -- i.e. caused a beachball). A week later I came back and checked it to find something truly astounding: with hundreds of logged spins, 100% of them were due to flash. Usually in Safari, but sometimes in other embedded webkit contexts. You would expect a few spins to creep into that list from other causes, and indeed I triggered one with a mail index rebuild just to be make sure it was watching more than the browser process, but no, SpinControl was working fine. 100% of the beachballs in the last week were due to flash's suckiness, to say nothing of power usage or security.

Flash's performance issues, at least on the mac, were very real. Good riddance.

> much better than J2ME ever was.

If you lower the bar to the ground anyone can jump over it.

iPhone never had Flash I don’t believe. I was an Android user at the time and the only way Flash on my device could be described is in terms of locomotive incidents. Flash games and applications almost worked, although virtually none of them were responsively designed, and they mostly worked pretty poorly with touch controls, and unlike HTML there was no way to reasonably work around or improve this at the browser level, because it was just a big proprietary black box.

Worse than this was sites that used Flash in non-essential ways like ads. If you had Flash enabled on a blog or other site that just happened to pop up a flash ad, it would make the whole page janky, greatly hurting pan and zoom functionality and killing your battery life for no benefit.

Worst of all, Flash frequently crashed my browser and sometimes even caused the entire phone to reboot.

Phones now have better CPUs and GPUs and I am relieved beyond words that Flash is totally dead now. It was never ideal for what it was most popular for (videos, streams) which only became apparent after the alternatives stabilized. But even for games and other software, I just don’t think the NPAPI browser plugin model was worth keeping. Would the problems with touch usability and accessibility be resolved at some point? Maybe I don’t know - I presume Adobe Air was able to do it for native apps, although my experience with Adobe Air apps was also not very good.

J2ME may have been not the most thrilling platform, but I’d not be surprised if it had a better security track record at the end of the day. I disabled Flash before most people, and was using a userscript to use the then-new and buggy <video> tag for YouTube. I still, before that point, had been personally hit by a Flash 0day, and a couple of my friends got hit later by a malicious Mediafire Flash payload. There was a period of time where it felt like there was a new use-after-free in Flash every month. And when you look at all of the functionality stacked into this unsandboxed blackbox to keep it competitive and alive, I don’t feel it’s terribly surprising.

I don’t enjoy everything about the bloated platform that is the modern web, but the design of it is a lot more sound. It’s designed more as a platform than a product. You get a lot of totally brand new functionality, like WebRTC, that just wasn’t really going to happen with Flash.

Flash had to die. It wasn’t a part of the web platform, it was part of an Adobe product that was shoehorned into web browsers. If it has a good legacy, I reckon it will mostly be from nostalgia fueled denial.

Then you had a much much better experience than I did, across Symbian (UIQ3), Windows Mobile and Android.

It's intellectually dishonest to imply de-adoption of flash was just "politics". Flash had all sorts of problems, we should be happy we managed to get rid of it. Back in the day I was too cynical to think one day we can do so.

Not at all, it remains to be proven that WebAssembly is any better.

I eagerly wait for the first batch of CVEs.

Html5 and modern javascript already replaces flash as a target. I don't know if the tools are the same. Webasm isn't necessary for that, its use is accelerating cpu intensive parts of a web page.

Except it is not.

https://www.leaningtech.com/pages/cheerpx.html

https://www.leaningtech.com/pages/cheerpj.html

https://www.qt.io/blog/2018/05/22/qt-for-webassembly

https://platform.uno/

https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

I don't know what point you are making here. These projects could have been done by compiling to asm.js - webasm isn't what makes them technically possible, it just makes them faster, smaller and parsed faster. You have been told all of this before.

Just like you have been told before that WebAssembly is nothing new beyond politics, all the way back to 1961.

Above you linked projects that you said happened specifically because of webasm. Here you are saying it is nothing new 'since 1961' (what does that mean exactly)?

How have you made CPU workloads run at native speeds across all major browsers before we webasm?

Many people have corrected you on your extreme and bizarre vendetta against webasm. You are the only one saying it is both nothing new and somehow enables new projects that you don't like.

As shown at the start of the thread, with Flash Alchemy, already in 2011.

Those people are the ones with an agenda to spread WebAssembly as above anything else in regards to safety, and the very first attempt to have a bytecode format for C and C++ code, when IBM and Unisys mainframes, CLR, Brew, Tendra, PNaCL, Alchemy have been there first.

My agenda, is only to prove a point that, it isn't that much safer than PNaCL, and the only thing we got from its adoption is a 10 year delay having a general purpose VM in the browser.

Ironically, Chrome is anyway who calls the shots in WebAssembly, as per browser market share.

You think all the people in this thread talking about quake 3 and doom 3 running smoothly are part of an agenda against ancient bytecode formats for IBM mainframes?

Only those pushing for WebAssembly as if it was the best thing since the Web came to be.

Flash had more issues than "politics."

Yeah lets see how many security issues we get to see in WebAssembly sandboxes once researchers set their sights on them, given that they already found a couple on JS engines.

Wasm has been here for years already. There's no flood of issues waiting for some cue to be released. It's no worse than any other part of the browser; probably better than some. Besides, modern browsers don't rely solely on one sandbox anymore. There are many levels of protection now.

CPUs were deemed unexploitable, until researchers had a better look into them.

The only thing that makes WebAssembly safer than its predecessors, is that most security researchers haven't yet bothered with it.

Which is already true for any type of software.

Bugs exist everywhere. Of course you finde some if you put in the effort. That is not something that marks the quality of the code.

Not all ideas were created equal. Parent's contention (one I agree with) seems to be that the contemporary browser-as-app-deployment-platform paradigm is a bad idea.

I didn't say Wasm is unexploitable. You're attacking a straw man.

Wasm vulnerabilities are worth real money. Bug bounties are tens of thousands of dollars to hundreds of thousands as part of exploit chains. If people aren't finding many, your explanation will have to be a little bit better than "they haven't yet bothered".

Currently there are better rivers for panning, but rest assured they will come.

https://i.blackhat.com/us-18/Thu-August-9/us-18-Lukasiewicz-...

You bring this nonsense up in every webasm thread and every time it is explained to you that webasm does no IO and is contained in the same environment as javascript. Every time you either bring up details that have nothing to actually do with webasm or you say something vague about possible security problems in the future.

If you have real criticism based on real information, let's see it.

You mean the same JS engines that already have several entries on the CVE database? Yeah, really safe.

It has a looooong way to go before it's as bad as flash.

Not really, I already posted a couple of initial steps in a sibling comment.

It would have to run a marathon to catch up. Initial steps are hardly an indication that it will.

Can you link one that has to do with webasm? Are you saying that you think javascript is less secure than flash?

Indeed,

https://www.contextis.com/en/blog/webgl-a-new-dimension-for-...

https://react-etc.net/entry/exploiting-speculative-execution...

https://www.virusbulletin.com/virusbulletin/2018/10/dark-sid...

https://www.cvedetails.com/vulnerability-list/vendor_id-2041...

https://i.blackhat.com/us-18/Thu-August-9/us-18-Lukasiewicz-...

All of these are speculation about the future. Most have nothing to do with webasm at all.

The first is about webgl (that has nothing to do with webasm)

The second is about using javascript with intel speculative execution exploits.

The third is grasping at straws, saying that call center scams would be more obsfuscated, even though javascript or asm.js can be just as obsfuscated, if not more.

The fourth is about crashes in the webasm JIT

The last is about -theoretically- executing arbitrary javascript. Heavens no.

What is the real reason you have some crazy crusade against webasm? You go to great lengths to grasp at any straws you can. It isn't that big of a deal. It is a more direct way to JIT cpu intensive parts of a web page. Get over it. Incredibly, the alternative is to run actual native instructions by downloading a binary.

Survivor of the anti-PNaCL, Java and Flash crusade I guess.

To be clear, because you have seen other VMs, you are desperate to spread complete misinformation and lies about webasm?

Funneling your own frustrations into lying and spreading false information on the internet is not something a reasonable, emotionally healthy person does. Think about all the other people that do that in other areas of discussion. Those are your peers when you do this.

I am not desperate at all, it is no different than WebAssembly advocates spreading false information about its "safety" or novelty.

In fact I rejoice that WebAssembly, despite all the attempts to be presented as safe and novel, is becoming the mechanism to bring back to life all the plugins that where killed in name of WebAssembly.

I will give 5 years time for WebGL/WebGPU + WebAssembly to rule the majority of multimedia driven websites, with a new generation of Flash like tooling.

Then you call tell the world how much safer and novel WebAssembly is.

What about 2010 without flash?

We ported the Java version of Quake2 using GWT in 2010

https://youtu.be/aW--Wlf9EFs

Even better.