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

191–200 of 203 posts

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

#191

Post by ZenoArrow »

blueprint wrote: post #152
ZenoArrow wrote: post #131

Earlier quoted context omitted.

Firstly, I didn't downvote you. Secondly, I don't know what point you're trying to prove. The people that create frameworks for Haxe have their own priorities, if those priorities don't align with your own that doesn't mean they lack merit for those that use them. Haxe has been used to create a number of successful apps and games. Instead of just looking for weaknesses, try also looking for strengths, try understandi…

I'm not sure why you responded if you didn't get my point then, but let's assume you're asking me in good faith. All I'm saying is that your premise of "write once, run anywhere" is still not true for everyone, everywhere. So I don't see why I have to accept it as if I'm being unfair to someone. I think it's not honest when people are not upfront about hidden limitations to their promises which are going to have mate…

> "I'm not sure why you responded if you didn't get my point then"

For the sake of clarity.

> "All I'm saying is that your premise of "write once, run anywhere" is still not true for everyone, everywhere. So I don't see why I have to accept it as if I'm being unfair to someone."

Use of native UI widgets is not a prerequisite for "write once, run anywhere". Code runs just fine using custom UI widgets. From a styling point of view, native UI widgets are a nice-to-have option, but they're not a required feature.

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

#192

Post by baldfat »

jay_kyburz wrote: post #155
baldfat wrote: post #17

Earlier quoted context omitted.

I don't think it is that small ecosystem. It may be used in gaming mostly but it has a very strong success record. I also have decided upon Haxe (Godot is still in the running) for educational activities I am building) Some very strong Indie games have been made in Haxe already. EA and Zynga us it for their mobile games and OpenFL has many children web games made with Haxe. https://haxe.org/use-cases/games/

I love Godots Python like language. Its kind of disappointing to see the C# stuff take centre stage.

It will eventually take over first position in Godot, but right now GDScript will stay the main focus. Personally I find Python (Though I really like the language) just isn't suited for gaming as well as other languages. The Indie Gaming Scene has really gravitated over to C# due to Unity. Unity also had a python like Language, Moon and it got dropped.

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

#193

Post by blueprint »

ZenoArrow wrote: post #191
blueprint wrote: post #152

Earlier quoted context omitted.

I'm not sure why you responded if you didn't get my point then, but let's assume you're asking me in good faith. All I'm saying is that your premise of "write once, run anywhere" is still not true for everyone, everywhere. So I don't see why I have to accept it as if I'm being unfair to someone. I think it's not honest when people are not upfront about hidden limitations to their promises which are going to have mate…

> "I'm not sure why you responded if you didn't get my point then" For the sake of clarity. > "All I'm saying is that your premise of "write once, run anywhere" is still not true for everyone, everywhere. So I don't see why I have to accept it as if I'm being unfair to someone." Use of native UI widgets is not a prerequisite for "write once, run anywhere". Code runs just fine using custom UI widgets. From a styling p…

Whether or not it's intentional on your part, you didn't understand what I pointed out at all. And you are literally making it up that "non native code runs just fine" and native code isnt a requirement. Do you think it makes it true just by insisting there's no way anyone might ever need native code? Lol. You're just displaying your ignorance and inexperience. However I at least am not tied by your choice not to have the real answer. Thanks for leading us down a completely useless rabbit hole after not understanding what I said at all. I'm sure you'll come up with all kinds of reasons why your point of view does not have to be discarded as invalid. But your "ideas" are exactly what led to have toolkits like Flash and HTML/CSS. Congrats. That's what happens when people are asleep.

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

#194

Post by singmajesty »

amaranth wrote: post #58
crescentfresh wrote: post #42

> rewriting the entire codebase in ActionScript first to take full advantage of GPU acceleration, before porting it into Haxe So let me get this straight. It was already written in ActionScript. They re-wrote the ActionScript. All of it, then ported it to the Haxe language. So the purpose of the first "re-write" was... refactoring it to use GPU acceleration in ActionScript? I guess they just hadn't gotten around to t…

I'd guess that, along with converting all of their artwork to bitmaps, this was needed because Haxe+OpenFL didn't support what they were doing before. If they were going to have to change it anyway better to make that change before the port so you don't mix up two sets of bugs.

OpenFL does support the earlier workflow, but you are exactly correct that refactoring and porting are better done separately than at once!

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

#195

Post by singmajesty »

k__ wrote: post #129
wvenable wrote: post #106

Earlier quoted context omitted.

I totally agree. There are tools for beginners but those are just for beginners -- you have to transition to something else to do real work. Development is so complex right now but I suspect most programmers in their 20's have no idea how easy it used to be. Now certainly some tasks themselves (like cross-platform development) were near impossible in those times but that's somewhat orthogonal to the point.

They had Flex, which looked really good. But somehow it didn't catch on.

Flex was really, really slow

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

#196

Post by ralfn »

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?

No. Also because it's nearly impossible, has only downsides including worse performance.

How could WebAssembly offer a single API to different languages with different internal datastructures and calling conventions and different memory allocators and garbage collectors?

They would have to pick a weakest/most-low-level common denominator, like the C calling convention.

If say the language you are compiling to WebAssembly is Haskell, Ruby or Go .. you will still need to bindings that are going to feel as 'calling into another language with non native (to this language) datastructures'.

And they will have to be implemented for each language that targets WebAssembly. And kept up to date.

If this calling out happens with typical C datastructures and calling conventions, you would need a complete reimplemention of the DOM, including meetings about every detail of the new API surface since in this world something as simple as a getting the boundingbox would not be easily expressible.

Also: since it's unclear who manages (owns) these datastructures and how, it means that most implementations will just always copy the data over.

So you have worse performance, double the attack surface, even worse performance because now the DOM needs to run in the same sandbox for it to be safe. And I'm not even sure all security policies can be implemented at all, even then. What about the rule that only code triggered by a click may open a new window? Is that even something we can implement on the WebAssembly level? No.

And after we finally all agree on what the API surface should be, you'll need at least 2 to 3 years to get a first implementation. Since the only way for browser vendors to do this is to implement their DOM completely for scratch.

And while we are doing that we also have to keep the feature set in sync, and maintain the current DOM because JavaScript isn't going anywhere.. and what if you want to use both?

The notion that WebAssembly could or should itself support bindings other than 'call JavaScript and interact with the DOM from there' is quite delusional and hints at a fundamental misunderstanding of how programming languages are actually implemented and what WebAssembly actually is.

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

#197

Post by merdreubu »

Decade wrote: post #70
ChrisSD wrote: post #43

Earlier quoted context omitted.

Sure but my recollection is that Java was the first major plugin that really took off. Then realmedia and other players came along. It was only in the 00's that I remember Flash taking off. My memory may be faulty so I'll bow to anyone who has decent sources.

In my recollection, Java was pushed into browsers as part of Sun’s Write Once Run Anywhere strategy. Browser makers went along because it was the era when everybody wanted to be a platform for plugins. Then Microsoft tried to control the development of Java on Windows, and that was a mess. The Java plugin was a pain. The runtime took somewhere on the order of 10 seconds to load, and the browser was completely unrespo…

It was Macromedia that made Flash, not Adobe. Adobe just ignored it and is now killing it.

Edit: Adobe also killed 2 other brilliant Macromedia products, right after acquisition, Fireworks and Freehand.

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

#198

Post by tritium »

imtringued wrote: post #190
tritium wrote: post #176

Earlier quoted context omitted.

The problem with “contributing” to a project that belongs to someone else, is that your contributions might be handily ignored, no matter how incredible and wonderful they may be. And so, often, the only recourse to such an outcome is to roll your own from scratch.

Why from scratch? You can take advantage of existing projects and make your own fork.

True. However, depending on the manner of licensing applicable to a given project, one might be forced comply with aspects of the protection a given license affords.

So then the choice leaves one working with intellectual property controlled by people who might ignore offers to improve their project, but in the same breath, demand attribution for the burden they inflict.

Why bother playing the sycophant to an emperor with no clothes?

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

#199

Post by cannedslime »

ivansavz wrote: post #4

Does anyone know of tools I can use to convert simple .swf animations to html + .js? I did a thorough research and found Swiffy (discontinued by google) and Shumway (discontinued by mozilla). All the other tools seem to require original source code to be available, which we don't have... (Context: educational animations for early childhood, e.g., cool numeracy animations with sounds and colors for kids to learn to do…

Are you sure that Shumway wont work? I can run some of my old swfs on it, it was a little cumbersome setting it up (primarily because I didnt have all dependencies installed but it was only a few) then run grunt

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

#200

Post by ZenoArrow »

blueprint wrote: post #193
ZenoArrow wrote: post #191

Earlier quoted context omitted.

> "I'm not sure why you responded if you didn't get my point then" For the sake of clarity. > "All I'm saying is that your premise of "write once, run anywhere" is still not true for everyone, everywhere. So I don't see why I have to accept it as if I'm being unfair to someone." Use of native UI widgets is not a prerequisite for "write once, run anywhere". Code runs just fine using custom UI widgets. From a styling p…

Whether or not it's intentional on your part, you didn't understand what I pointed out at all. And you are literally making it up that "non native code runs just fine" and native code isnt a requirement. Do you think it makes it true just by insisting there's no way anyone might ever need native code? Lol. You're just displaying your ignorance and inexperience. However I at least am not tied by your choice not to hav…

> "non native code runs just fine"

Ah, I can see where you're getting confused now. Haxe compiles to multiple formats, including binary formats on platforms like iOS. Native support is not reliant on using the bundled UI framework, native support means compiling code to the native format expected by the OS.

To use an analogy, imagine I build a C++ app for MacOS but I use Qt instead of Cocoa for the UI. The end result is still a native app. Native is about the runtime, not the UI library.

Post reply on HN