Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Death of Flash and Rewriting 1.4M Lines of Code

gamasutra.com

Post reply on HN
Print view View original

111–120 of 203 posts

Re: The Death of Flash and Rewriting 1.4M Lines of Code

#111

Post by jrs95 »

watty wrote: post #75
dilap wrote: post #36

Earlier quoted context omitted.

Jobs' position was they couldn't make flash run acceptably on mobile devices, so they never allowed it. Looking at how Flash turned out on Android, I think history shows he was right. Rereading Jobs' letter from years ago, basically all of it stands solid. https://www.apple.com/hotnews/thoughts-on-flash/ Remember when basically everyone was using flash to play video? Would we really be in a better place if that had c…

Was Flash on Android bad? I guess I never really noticed. I imagine it performed worse but don't those things fix themselves over time? It's like OS X or Windows banning Electron Apps because they're horrible compared to native.

> It's like OS X or Windows banning Electron Apps because they're horrible compared to native.

Can they do this??! Please?!

As for Flash on Android, it was pretty terrible iirc. But at least it worked, and with most of the video content still being Flash based at the time, it was kind of nice to have until everyone switched off of it within a year or two.

Re: The Death of Flash and Rewriting 1.4M Lines of Code

#112

Post by shmerl »

seangrogg wrote: post #77
scottmf wrote: post #51

Earlier quoted context omitted.

I just glanced at that repo and what you say is not quite true. Looks like they have to reimplement the entire DOM API with JS interop: pub fn document() -> Document { unsafe { js!( return document; ).into_reference_unchecked() }.unwrap() }

Valid point - currently, wasm cannot target the DOM. I think the GP would've been more accurate in saying the logic is all performed in Rust - JS is only used for DOM access.

Is it because of security reasons?

Re: The Death of Flash and Rewriting 1.4M Lines of Code

#113

Post by btown »

joemanaco wrote: post #59

1.4M Lines of Code in a very high level language? What the hell are they doing?

Thousands of self-contained flashy effects, each custom designed with its own animation code to optimize that specific dopamine response, all to keep someone playing slots and spending their money. It’s a domain well suited to fractured/“parallelized” development processes. I’m honestly surprised it’s not even more lines.

Re: The Death of Flash and Rewriting 1.4M Lines of Code

#114

Post by ZenoArrow »

shmerl wrote: post #112
seangrogg wrote: post #77

Earlier quoted context omitted.

Valid point - currently, wasm cannot target the DOM. I think the GP would've been more accurate in saying the logic is all performed in Rust - JS is only used for DOM access.

Is it because of security reasons?

Not as far as I'm aware. WASM is still sandboxed like JS is. I believe DOM access is coming, and in the meantime I believe you can still use directly.

Re: The Death of Flash and Rewriting 1.4M Lines of Code

#115

Post by manigandham »

gech wrote: post #45
tomovo wrote: post #41

Earlier quoted context omitted.

WASM replaces Javascript as the target of other language compilers. If you already use Javascript, WASM won't be much help. But WASM lets you compile C/C++ and with a bit more effort other languages into a bytecode instead of weird looking Javascript, or its more streamlined and still weird form, asm.js.

This will ensure every web page application can be closed source then right?

Not necessarily, WebAssembly will support view source features: http://webassembly.org/docs/faq/#will-webassembly-support-vi...

Re: The Death of Flash and Rewriting 1.4M Lines of Code

#116

Post by manigandham »

Crespyl wrote: post #88
seangrogg wrote: post #73

Earlier quoted context omitted.

Shouldn't it be possible to decompile from wasm to the language that was used to compile to it (or any target language that could've produced said wasm)?

Only to roughly the same degree that it's possible to decompile x86/64 binaries to C or C++. It depends heavily on the specific optimizations and obfuscations used, whether or not debugging information was left in, etc. There's a reason the GPL has a "preferred form for editing" clause.

It's better than that: http://webassembly.org/docs/faq/#will-webassembly-support-vi...

Re: The Death of Flash and Rewriting 1.4M Lines of Code

#117

Post by ZenoArrow »

blueprint wrote: post #107
panopticon wrote: post #60

Earlier quoted context omitted.

I have seen very few games leverage native controls (with the exception of dialog boxes which are supported by almost every write-once framework), so I'd be curious to know your specific case for needing native controls in a game.

Then you miss the point of systems like Haxe.

The point of systems like Haxe is "write once, run anywhere". You don't need to mimic the standard OS interface style to do so, especially not with games (as it's more important that the style of the interface suits the game).

Re: The Death of Flash and Rewriting 1.4M Lines of Code

#118

Post by jack9 »

jack9 wrote: post #66
jmull wrote: post #29

Earlier quoted context omitted.

Yes, that bothered me too. They called that option “HTML5”, but they meant something more like native JavaScript & HTML.

Accessing HTML5 features is usually by javascript api. Even if you used another dependency, how would that help?

Seriously? Do you not understand the question? Guess not.

https://www.html5rocks.com/en/tutorials/getusermedia/intro/

Basic intros to HTML5 all use Javascript to access functionality. How else are you going to access video, audio, timing, etc? HTML5 isn't a language.

Re: The Death of Flash and Rewriting 1.4M Lines of Code

#119

Post by Marazan »

ralmidani wrote: post #78

I have zero sympathy for anyone who feels pressured to convert a Flash app these days. The writing has been on the wall for so long, and there are still at least 2 whole years before Adobe cuts off support. Flash is the established cause of so many computer crashes, so many security exploits, and so much battery drainage. It is downright irresponsible for anyone to force users to use Flash in 2017, even if Adobe prom…

The Flash runtime was not an intrinsic battery hog. The shit swfs people wrote was the problem. The same people are now writing shit HTML5 that drains just as much, if not more, battery

Re: The Death of Flash and Rewriting 1.4M Lines of Code

#120

Post by ZenoArrow »

teilo wrote: post #63
joemanaco wrote: post #59

1.4M Lines of Code in a very high level language? What the hell are they doing?

They wrote this codebase in Flash, meaning ActionScript, the only real option at the time they were developing these games. The effort to rewrite the entire codebase in something completely different, all while still running a profitable company, in time to beat the EOL for Flash, all while still maintaining a legacy code base, was a non-starter. Now they have a multi-platform code base, and a non-deprecated path for…

GP wasn't talking about the rewrite, they were talking about the original codebase. In other words, how did the codebase for a couple of Flash games balloon to 1.4 million lines of code?
Post reply on HN