I feel like the author and/or the team is confused about what HTML5 actually is. They're probably right to conclude that JavaScript/HTML5 won't perform as well on lower end devices, but a few things struck me as odd.
They mention Facebook switching away from HTML5, but I think Facebook is using the actual DOM, whereas their game would be using the canvas part of the HTML5 spec.
Later they mention WebAssembly replacing HTML5, but what it's really replacing is JavaScript, and the actual canvas that you're rendering to will stay the same afaik. The impact on performance would probably be as they predict, but overall, their issues seem to be with JavaScript, not HTML5.
Facebook famously moved away from HTML5 for mobile applications, the author is talking about a time some years ago when his company began to look for other technology.
I think the important thing here is that "HTML5" as a solution would mean wrapping it in a Phonegap/Cordova application for mobile. Haxe means HTML5 and/or Flash on the web, but also native for mobile.
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.
> WASM replaces Javascript as the target of other language compilers.
Ugggh, still no evidence. WASM is a compile target in a sandbox. It is the new Flash or Java applet. Everything else is a wish list from people incredibly insecure about touching JavaScript.
So far any advocation that WASM will magically replace JavaScript severely misunderstands both WASM and JavaScript. I will continue to await something more than mere fantasy.
Nobody was claiming that WASM would replace JavaScript in general, magically or otherwise. I think there's reason to believe it will replace asm.js since it's already being integrated into Emscripten and the major browsers have already landed support in their stable releases.
I find comparing it to Flash or Java applets weird, given the fact that you clearly understand that it doesn't interact with the outside world using any WASM-specific APIs. Both Flash and Java applets could in theory interact with the outside world only via a JavaScript wrapper but that was never the use case they were aimed towards either in theory or practice. Flash and Java applets also used languages that map much better to JavaScript's execution and memory models than C/C++ do, so the APIs were a big part of what you were getting by going that route (especially in Flash's case, where you had to learn a totally different programming language just for Flash).
Unless you consider people who using things like Node.js or Electron to be "insecure about touching C/C++" I don't see where you get off saying that about people who want to use WASM. Sometimes you have existing code or expertise in a certain language, or it simply fits your problem better.
> Nobody was claiming that WASM would replace JavaScript in general, magically or otherwise.
That is literally what I have heard directly on here and Reddit numerous times.
> Unless you consider people who using things like Node.js or Electron to be "insecure about touching C/C++" I don't see where you get off saying that about people who want to use WASM.
I am not saying that about WASM. I am saying that about the people who obsessively NEED for WASM to replace JavaScript and believe this to be a magically solution.
WASM replaces Javascript as the target of other language compilers.
JavaScript is also a compile target in a sandbox. Emscripten started with outputting plain JS, then that was optimized to asm.js, now optimized to WASM.
I completely agree that WASM should NOT replace JS for normal DOM apps. It's currently possible through awkward calls into JS, and might be possible in the future more directly, but there's no need to replace JS.
> WASM replaces Javascript as the target of other language compilers.
No, it does not. Compiling to WASM is not a replacement or synonym for compiling to JavaScript. JavaScript is not locked in a sandbox, in the same way, as it has a multitude of APIs. WASM does not have such APIs as it is just the sandbox.
Here is the deal. All modern browsers now claim to support WASM. If WASM were capable of replacing JavaScript it would do so right now, but it isn't because it cannot. The demand is certainly there and yet despite that demand the results are completely absent.
People claim this is because WASM lacks DOM bindings. True, but that is only a tiny bit of it. WASM also does not have a security model around code/data distribution. WASM also does not have access to the chrome of the browser (the parts outside the DOM). I also haven't heard much about asynchronous threads in WASM, which is a huge requirement when working with distributed code execution. This list could go on and on.
This is common knowledge for people who do this work professionally. There is an incredible amount of work to do before an arbitrary compile target can replace a major platform consideration, and much of that work isn't API bindings.
The people who claim WASM as a replacement for JavaScript, as evidenced on r/programming, tend to be the people most ignorant and fearful of JavaScript. They want a replacement so badly they assume this is it without any consideration for what the technical requirements are, because they have no idea what they are.
I'm starting to get fed up by the open-ended trust models used by most forum software on the internet.
slashdot started in 1997. phpBB was started in 2000. 4chan accidentally in 2003. reddit was put together in 2005. HN was created in 2007.
I think 2007-2010 was a tipping point where people started to collectively get smarter and more sophisticated on the Web. I'm not saying everyone was dumb before that, but that... you needed to be more cynical and you couldn't just depend on something's ridiculousness to know whether it was fake or not.
4chan maintained a troll mentality that made it obvious some things were real and some were not, and many people there there knows not to believe everything they see - maybe not a 51% majority, but just enough that the integrity of an awareness culture is maintained.
HN got started around the tipping point I just described, which might explain why it's lasted a while.
But all the others... they're based on old ideas, old notions of trust. The culture is based on openness and contemporaneously broken interpretations of the idea of freedom of speech - so anybody gets on there and declaratively makes their point, and everyone believes them like it's tort law and utterly official.
Maybe that's why reddit gets blamed for being a hivemind.
Not quite sure if I'm talking hot air through ten hats here, but I'm just mad there isn't an IQ test to be casually involved in tech because EVERYONE has such crippling levels of "oh no I don't understand this so I'll just believe this thing here and won't fact-check it for myself". At least on reddit this seems to be the case.
Yes, that's really harsh, but I see it as the facts of the situation. If I'm wrong please do let me know.
Its a good point, and a lot broader than tech or online forums.
The end point of "everyone gets an equal say" is noisy, bad consensus, because not everyone deserves an equal say - that invalidates the whole idea of differences in skill/knowledge among domains across people. Its why the modern world uses representative democracies, rather than direct democracies because no one person is qualified (or has enough time) to make decisions about the minutiae of FISA amendments, cooperation treaties between US-Israel space programs and federal food stamp programs at the same time.
I think early HN (and the web) were small enough that only people who really cared used them, so stuff tended to be high-quality even though they were open to all. As audience grows, content gets worse. Quora is another great example of a forum being destroyed by scale.
Plus now that people actually use forums, there are millions of "growth marketers" trying to push their agenda that further muddy the waters and increase noise. The ads, "native" ads, clickfarms, massive networks of sockpuppets and ads masquerading as "content".
I wish I had a solution.. but the only resilient one I see is a real old-school human community. A network of people you trust. Friends basically :p
Also, if anyone has books or pointers to read more about this kind of stuff, please tell me!!!!
> [N]ot everyone deserves an equal say - that invalidates the whole idea of differences in skill/knowledge among domains across people.
What makes me mad is that this isn't even that controversial; people just go straight to "completely offended" about so many things nowadays without accepting that they've leveled-up as much as they have, that discussing things competently must be earned, and that the right to do so should come with the ability.
"Representative democracies" sounds like scalability-speak :P - where I define "scalability" to mean "dropping tons of rounding errors on the floor". (Cuz that's what invariably happens.)
Network "smallness" wasn't really a concrete enough explanation for "works better" to me; I knew there was something extra to be said besides "human networking doesn't scale". This is of course true, but too generalized IMO.
Niche interest provides a slightly more concrete explanation: you're right, only people super-interested in relevant fields (or recommended by word of mouth, perhaps) used to find HN.
And yes, now we have spammers of all kinds. HN is full of the weird ASCII soup ones, I've noticed tons of them of late sadly. But the noise here is greater, and sadly lots of interesting content gets firmly buried the moment it's posted while fluff rises to the top. I wonder how much of the fluff is engineered.
As for a solution to this, I think whole-system analysis could be useful - scraping e.v.e.r.y.t.h.i.n.g on a site, all the content and even images, and then being able to cross-reference everything, shove it through arbitrary models, etc. Having everything in once place is I think the key part - this is after all how our brains work, and since this is about human networking I wonder if this isn't at least a good approach to start with.
Nobody seems to be doing this at scale for eg reddit or HN, even though the data is available (reddit has dumps up on bigquery and there are also torrents; and HN's firebase API is officially explicitly non-ratelimited, confirmed via email). Beyond that, looking at for example all of tumblr is something I've wanted to do for a very long time.
Ultimately it's about being able to lose the right information in the summarization process. Summarization is always lossy; but if you lose low-value info then the essence can be reconstructed. (If I summarize this message by dropping everything except for "if" "and" "a" "as" "for" and "I" (etc), the result would be non-reconstructable, for example.)
"Big data" is currently at the pattern-matching stage. The stage I've just described - summarizing consistently - will be the one where people will be falling over each other with new uses etc etc. I think everyone's anthropomorphizing the stage we're at, thinking we're already doing summarization, because it's how we intuitively interpret the idea of pattern-matching (when we aren't actively thinking about the mechanics of it). But we aren't yet.
So for now, we need to do this ourselves, I think. I've been thinking about tagging for many years; del.icio.us absolutely had the right idea with that, it's so sad it's now a broken personal-use-only archive (it got bought by pinboard and is now effectively non-scrapeable D:).
I'm hoping to put a forum of my own together at some point. Considering the speed I do just about anything and the number of ideas I know I want to fold in I know the earliest I'm likely to have anything interesting is probably this time next year (ha). It uses tagging as one of its foundations along with a few other tidbits. (Of course they is sekret, I want the forum to be a surprise :D)
I also have some ideas about web scraping I want to play with at some point. Well, not really web scraping, but more a "bigger picture" type thing that makes scraping interesting/useful. _That's_ a 10-year project, one I've been thinking about since 2003. (I still haven't started it, as I'm still figuring it out. It's not rocket science, it's just getting the intersection of a thousand tiny details right.)
Problem #1 is articulating everything - I have no idea how to describe all my ideas because the only way I know how to write is to describe things with a beginning middle and end. But there's no middle or end because this hasn't happened yet (lol). So I go to write about this and I get completely stuck on the "beginning" part, describing what I'm about to describe in an infinite loop. Hilarious and depressing all at once.
I've recently realized mind-mapping could help there, now all I need to do is get (or build) a mind-mapping system that'll work on my ancient laptop... ("what's a GPU?")
Javascript also does not have access to the chrome of the browser. Unless it's running in a WebExtension context, in which case you can also run WASM there.
WASM can CALL INTO JAVASCRIPT CODE. Which means it can do anything JS can do — in a "clunky hack" kind of way, sure, but people are building sugar on top of this already: https://github.com/koute/stdweb
So it's not the kind of sandbox you're thinking about. It's literally the same sandbox as JavaScript itself.
Also, I just realized — you're probably thinking of "compiling to JS" as in TypeScript/BuckleScript/Elm/ghcjs/ScalaJS/… — and yeah, that isn't easy to replace, because you'd have to implement a whole garbage collected runtime for WASM currently and that's kinda ridiculous.
Others (including me) are thinking of "compiling" as in Emscripten, and WASM was literally created to optimize this at first.
No, but there are tons of prettifiers that can get minified/obfuscated JS back into a state that it can be read and reasoned about fairly easily. It's not like minifiying/obfuscating JS compiles it into byte code. It's still plain text.
Free software has never been about the technical possibility of something, but a moral and cultural value. I.E. Just because you can, doesn't mean you should. So favor sites which don't obfuscate or make their (WASM) source code available as free software.
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)?
Yeah, but is that actually required? I don't know much about this, but I'd guess 90% of websites will strip this just like debug info in most proprietary software, 9% don't know about this or forget to remove it, if it's included by default and 1% consciously decides to ship it for transparency.
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.
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.
Nope. It's because one of the things that WebAssembly did to succeed was stay small. Instead of a huge kitchen sink spec, it's lean and mean, and will add things over time. DOM access is one of the first features to be layered on.
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 <canvas> directly.
I found the article confusing at first, because they said they discarded HTML5 as an option but in fact ended up using Haxe to generate HTML5.
The explanation is that they wanted a desktop-first, multi-platform solution that is able to generate both HTML5 and iOS/Android native code. Quite interesting, as I didn't know you can use Haxe to achieve this.
I still wonder if React + React Native could offer a similar platform, although it would probably not be very optimized for games.
Haxe is pretty interesting. I really wish strongly that it was more polished and had a larger ecosystem, because it feels like a nice development environment and is quite nice to code in.
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.
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.
As a native mobile dev, I found myself unable to adopt it because I need and/or want direct access to the native platform capabilities, most especially when it comes to building GUIs. Write-once tends not to work so well when users are able to tell behavior, framerate, appearance, … differences in a split second and when optimal UX was my purpose in writing mobile apps in the first place. In the same way, learn-once is more of a marketing term than a reality, since platforms implicitly differ.
Well, it's kind of an issue, because it's a similar argument for platforms like Xamarin. A third party still has to keep up with mainline. That means another layer of support, maintenance, dependency… which is not always an issue… but practically speaking is one of the things you eliminate at scale and / or in the rigors of production.
Fair enough; it still seems pretty promising, especially because my experience developing native Android apps did not make me feel confident in doing very advanced UIs with native Android - it just feels complicated, and the compatibility layer stuff seems like no fun. (I had trouble linking the jars in for reasons I was not able to fully understand. I've worked with Java stuff before, but the Android toolchain still has me confused.)
I hope that Flutter, with its massive backing, manages to stay up to date with mainline without putting too much burden on app developers. We'll see I suppose.
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.
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).
That's great as long as you don't care about reusing your code. It's not just biz logic, services, utils, etc either, I'm talking about the fact that people put UIViews over SpriteKit games all the time and you can't rightly say that doesn't exist just because you get to downvote me.
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 understanding why developers are choosing to use it.
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 material effects on the future. We ought not to sweep this problem under the rug when we have the chance to solve it. I don't buy that people have entirely their own priorities. We all need a solution to this problem, but who wants to dedicate their life to making "learn once write anywhere" an actual reality? Especially when the developers of top platforms "have their own priorities". Go ahead and call me esoteric but I guess I just prefer it if projects didn't overhype their capabilities when I'm supposed to be evaluating them for security- and business-sensitive contexts. :P
> "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.
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.
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.
Does anyone else have the feeling that there has been a move away from the kinds of tools that make it very easy for beginners to get started? I'm thinking of things like Hypercard, Flash or VisualBasic classic (VisualBasic in the 1990s). Simple tools that made it fun for non-programmers to learn the basics of computer programming?
Even simple HTML/CSS has lost importance, and writing simple Web sites is how I got started back in 1995.
Look at what happened on the Web between 2005 and 2015, where we transitioned from using HTML/CSS to instead building systems with React/Relay or Angular or Vue.
Especially since 2005, it’s unclear that we gained much — the old system gave us Google Maps and Gmail and a lot of great online software, none of which seems obviously worse than the kind of software being created today. And, contrariwise, the biggest missing piece in 2005, a good Open Source tool for animation to replace Flash, is still missing now. What do we do nowadays when we want to mix images, sound and video in an interactive interface? We can build these sites with complex Javascript, though we are still missing a good authoring tool to match what Flash used to have — in particular a tool that allows people with little skill to do a great deal. Using React/Relay/GraphQL requires a tremendous amount of skill.
(There also used to be the argument, put forward by folks like Phillip Greenspun, that Flash did not belong on the Web, because the Web was fundamentally about text and images and HTML. I read Greenspun’s book in 1998, and I strongly agreed with him then and for many years following, but we have to admit that debate is now long dead, along with ideas such as semantic pages. The way people use Javascript now is in the spirit that Flash was once used.)
I disagree. If you're in a developer bubble you may believe that everyone is using react or angular or vue but if you're beginner you're more likely to stumble upon on something like codecademy or freecodecamp. On freecodecamp they start by teaching you some basic css/html then javascript and (!) jquery and after that you start building simple projects/sites using codepen. I think codepen is really great begginer tool. You don't have to worry about bundling stuff, what text editor you use, etc. etc.
Even codeacademy and freecodecamp are fairly advanced.
For actual beginners, there are even simpler tools. At school, my kids were started in Scratch. They showed it to me a few weeks ago and it's very good.
The Adobe Flash authoring environment has been rebranded as Adobe Animate now that it can output html/js/canvas content. It’s closed source of course.
Long before that, however, the fairly simple to understand Actionscript 2 was replaced by the more powerful but much more complicated Actionscript 3 and it became a lot less friendly to a new programmer.
ActionScript 3 was definitely not less friendly, it just wasn't ActionScript 2. One of the most unfriendly things about ActionScript 2 was that it was just so different from other programming languages, and not in a good way.
I actually was taking programming classes at the time, and they were all in Java. Almost every concept translated directly from Java to AS3. In fact, AS3 is actually a sister language to modern JavaScript, as it was simply an implementation of ECMAScript with actual classes and optional type system.
AS2 was instead a very strange and inconsistent language, where having a question answered in another language was unlikely to conceptually port over.
AS1 was a very close relation of JavaScript, prototype inheritance and all. AS2 was based on Netscape's initial proposal for ECMAScript 4. AS3 was a more fully developed proposal for ECMAScript 4, which in turn was abandoned.
I really think where Haxe is going for Web development will actually fill this place. The game engines like Godot and unity have made game development easy for beginners. I think With WebAssembly we will have higher level languages that will make web development easier for people starting.
The problem is when tools that are targeted for rapid development start getting used for large, mission-critical applications. The people using these tools professionally often are not the greatest engineers and you end up with a giant mess of an application using technology that is no longer supported. The company I currently work for is in this situation right now with Oracle Forms.
Going with your specific example of beginner web dev, the basic HTML site of today is Wordpress
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.
Flash existed in places outside of the browser even after a significant portion of the web development scene moved on from it. Building game UIs with Scaleform was very common. AutoDesk only discontinued Scaleform earlier this year.
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 math. There is some great content, but would have to be abandoned since Flash is no longer supported.)
4. file>publish, this sure can take a while, it’s been stuck at 80% on the file I pulled out to test this on for some time.
Caveats:
* Some SWFs are "protected" and won’t be loaded by the editor, you can find tools online to crack that protection pretty easily IIRC. Or at least you could back in the day.
* This won’t get the sound.
Installing Animate also gets you the Flash Player, which will play any .swf; you could conceivably record the screen as a .mov or whatever. Though a cursory google search reveals multiple websites that claim to be able to spew out a video file from your uploaded .swf.
You could also acquire a swf decompiler and use that: decompile .swf, load the resulting .fla into Animate, export as canvas. I don’t know which decompilers are currently the best, it’s been years since I last did Flash.
Not to mention the Newgrounds/Albinoblacksheep/etc world. It kills me to see all of the art produced by that community become inaccessible. I'm hoping that it becomes possible to run (sandboxed) flash apps in the same way that you can run DOS apps with DosBOX. If there's a project I can contribute to somewhere, I'm game.
> I'm hoping that it becomes possible to run (sandboxed) flash apps in the same way that you can run DOS apps with DosBOX.
Firefox + adobe flash plugin still works (well, it works for me anyway... I'm on FF 56 still). Slap it into a container (firejail works) and you are done. No need to reinvent the wheel.
If you don't want the closed source solution and the Firefox dependency, there's also gnash. Slap gnash on a container and you're set. The only niggle is that gnash is... kinda bad. It's slow and a bunch of swf files I have don't work (some don't work at all, others have weird graphical problems).
If you want to contribute, gnash would be a good candidate, I guess:
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.
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?
I have done a few flash to HTML5 conversions without source code, and the method I've gone with is just to use the flash as a guide and write the HTML5 app from scratch. You end up with cleaner, more maintainable code that way than if you were to throw it into a converter and try to sort out what comes out, and it can end up taking the same amount of time as trying to fix whatever the converter came up with in the end. Do you have any links to the flash products? Might be worth putting what you have in a GitHub repo and see who can contribute. Maybe try https://www.codetriage.com/ as well. If you end up doing either, let me know and I'll try to help :)
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
If you have the original source file (FLA), Adobe Animate (formerly Flash Pro) can export to Canvas. It uses the Create JS library for export / runtime:
Swiffy was offered as an API and is no longer available, so can't try.
I tried reading the Shumway docs + follow the build instructions but got nowhere. I think it was meant to be used as a plugin for firefox (to emulate Flash runtime). I have it a whole day and got nowhere, so I'll count that in the tried-but-failed category.
> 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 that optimization in the first place and used this as an opportunity to do so. But was it strictly speaking, necessary?
CPU - this is an old API that can render vector based graphics. Every game before 2011 uses this API.
GPU - Adobe introduced a thin OpenGL wrapper around 2011. This is a completely new API and looks very similar to OpenGL.
I guess Haxe code looks much more similar to a game written in OpenGL, this they rewrote the rendering pipeline (and converted all assets from vector animations to sprite sheets.)
I know a guy who worked for that company. Sounds like they had no goal beyond refactoring their ActionScript as better ActionScript as recently as a couple years ago, denying the ample writing on the wall that this was a fool's errand. I assume they pivoted and turned that into a stepping-stone for their Haxe port when it finally sunk in that Flash was getting euthanized. So they might be monkeying with the timeline and cause-and-effect in the article, but the end state is ultimately what matters.
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.
This makes a lot of sense. Doing a major refactoring while migrating to a new language/platform is much harder than refactoring a codebase so that it more closely mimics a line by line translation to a new language, and then doing the line by line translation. It may look like more work, especially since you are almost guaranteed to touch the same code twice, but the the cognitive load is so much lower each time, that the extra effort will make it all so much easier.
I remember thinking, wait, Javascript will catch up eventually then why would anyone use flash? At the same time, we probably owe a lot to flash existing (especially WebRTC). Flash helped us get browsers to this point faster both through it's tech and increasing consumer awareness/demand for media.
> I remember thinking, wait, Javascript will catch up eventually then why would anyone use flash? At the same time, we probably owe a lot to flash existing (especially WebRTC). Flash helped us get browsers to this point faster both through it's tech and increasing consumer awareness/demand for media.
i don't think most people remember how bad Javascript was, how limited web API were, and how different browsers implemented totally different flavors of JS and DOM and standards were weak.
Flash pushed the web forward and demonstrated that it could be used to deliver real desktop like applications,videos and games, not just text and images.
Obviously it also came with a catch: the player was proprietary and full of bugs and security holes.
Ultimately, Web API progress also staled when Flash died. You still can't mesure canvas text properly in most browsers and API such as file system and WebSQL were dropped, which is a horrible mistake IMHO.
> Flash pushed the web forward and demonstrated that it could be used to deliver real desktop like applications,videos and games, not just text and images.
Java (and RealMedia) did that first. The thing that Flash brought was good tooling for creators and not just programmers.
We have very different recollections of the history. If your website had the Shockwave badge, I was excited. If your website has the RealPlayer badge, I likely went somewhere else. You also can’t underestimate the influence of the ‘new media’ web aesthetic, that was dominated by Shockwave (e.g. Praystation), on current web design principles and tools.
For those that don't remember/weren't online then, Shockwave was the brand that Flash originally shipped under. It's where the "sw" in "swf" comes from.
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 unresponsive during this time. This was also the era before CSS, so if you wanted animated buttons on your web site, you had to use Java. Imagine loading a page, and then seeing a column of gray rectangles that freeze your browser and eventually resolve into dithered (“web-safe” color) buttons. Not a great experience.
Real Media only played video and audio. QuickTime played video and audio and VR snapshots. There were also plugins for specific types of content like VRML.
I feel that Flash took off because Adobe spent lots of money pushing it everywhere, but also because it ran better than Java. The runtime was smaller to download than Java, it started up much faster than Java, and its vector animations played very smoothly compared to the alternatives of the time.
Right. I remembered that Adobe bought Macromedia, but I thought the acqui-kill was earlier. I was getting the story of Macromedia mixed up with Aldus. And actually, Flash came from FutureWave Software, before Macromedia acquired that company.
But Adobe did not ignore Flash. They may have mismanaged it, but they did invest in it, and tried to push Flash into places it does not belong (AIR, and especially PDF). They also tried to turn ActionScript 3.0 into ECMAscript 4.
Now that the Flash runtime is becoming banned, Adobe renamed the Flash Professional content creation program to Adobe Animate, and made it able to export to some flavor of HTML5. The content creation is where they make the money, after all.
It is true that Java was the first widely available plugin, but how many people did really useful things in Java? It was always a pain, slow, difficult to use properly. Most people dreaded using Java and it only had a niche in enterprise applications. It was flash that made plugins look cool and brought innovative things like Youtube to the masses.
So instead of click-to-play Flash, now you have unstoppable, auto playing audio and video ads that spy on you...?
Yes Flash with it's weekly or sometimes daily security vulnerabilities was bad, but HTML5 is not "better".
It is design by giant corporations (DRM inside your CPU, inside your browser, etc.) FOR other corporations. It is not designed for people, for freedom. It is regulatory capture by Silicon Valley "techbros" of... Internet's standardizing bodies instead of government regulating agencies.
Hence when I recently used the browser (designed by an advertising company BTW), websites just freely play annoying sounds.
This is not "better". It's worse IMHO, since at least with Flash you had click-to-play.
Agreed. But on the other hand, with web a browser can select which features it allows and which ones it ignores. With flash there was no such option. I am really hoping Mozilla gets their act together and protects us users here.
I think the final legacy of Flash will be the knowledge that this was the first major piece of software locked out of a platform and we lost a lot of the history of the internet with its demise. As much as Flash was a pain, I'm not sure I like the idea that it is acceptable for Apple or anyone else to keep that software off their platform. I wonder if someone comes up with the next step after the web will it even be allowed to run?
This has always been the fundamental problem with building anything on a closed platform. This outcome was predictable, with or without Apple's machinations.
But loss of internet history has happened again and again and will continue to do so for time immemorial. We lost Webshots. We lost Geocities. Timecube is gone. All of my old Yahoo accounts, groups, friends and associated content have either been lost to data breaches or outright reassigned. Photobucket is a shell of what it once was, what with their blocking hotlinks and purging old data. Anything you created in Second Life will only last as long as the parent company decides it's worth supporting their subpar VRML engine for the benefit of its dwindling community of sexual deviants. As the internet becomes more and more centralized on a handful of platforms that happily ingest our data but refuse to efficiently excrete it for archival, bringing it with them to the grave, and that will themselves one day be replaced with something more hip, all your precious memories, photos and top-tier memes will be lost to time like tears in rain.
It's nobody's fault. It's the natural order of things. Old technologies and platforms die, and new ones take their place. Some data loss happens in the transition. The internet circa 2000 might have sentimental value to you and I, but it's counterproductive to insist that all web browsers need to be able to support playback of Peanut Butter Jelly Time SWFs, RealPlayer-encoded Nine Inch Nails videos, Metallica's homepage from 1997, or binaries of P.F. Chang's menus in their original form in perpetuity. Sometimes it's best to let go of sentiment for the sake of progress.
Seriously? For what reason Apple should have been forced to support in his platform something sluggish, buggy and full of extremely serious security problem?
I really can't understand your rationale.
The article is describing an event that has been covered a couple ways. It was also the basis for a presentation at the 2017 Seattle Casual Connect - https://www.youtube.com/watch?v=nGl3pDhYC9o
I was one of those who asked some questions at the end.
Even though the OpenFL api matches the AS3 version pretty closely, a porting job of this scale would've been a huge ordeal to go through. To have this kind of a positive trip report after the whole process is over is a great credit to Josh's work on OpenFL.
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.
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 forward. What they did is utterly rational from an ROI standpoint.
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?
This article is confusing, and sounds confused, but I feel like a lot of problems like this could be solved by Adobe open sourcing the Flash Player. If they did this, we would have a complete, correct view of how each and every feature in the Player was implemented, and a working implementation to compare to.
In the sense that there is so much art locked away in SWF blobs which don't quite work with gnash or shumway. The last patent needed for MP3 decoders will, IIRC, expire at the end of this month, so we can include one of those everywhere too (essential for most SWFs).
Also, it'd be nice to have access to the Shockwave player, boy oh boy, I think just about nobody has tried to reimplement that (probably due in part to XTRAs and other fun). There's still plenty of Shockwave content out there, don't know if anyone here remembers playing the Gorillaz Final Drive gamette, IIRC released to promote 19-2000, or any number of other cool things people were doing with Director.
I am looking at converting 40k lines of action script right now. TypeScript is my top choice, while I like HAXE, I dont feel that is has a large enough ecosystem. Also ActionScript to TypeScript is really easy.
I've always disliked this excuse. Software licenses are negotiated with third parties, not handed down from god. If Adobe really thought it would be advantageous and profitable to open source Flash, wouldn't they have gone back and renegotiated these licenses? "We'd love to do Xyz, bbbbbut licenses!" doesn't really make sense.
Or release a crippled version with with the commercial dependencies stubbed out and let the community bring it back up to speed? This could even slightly advantage Adobe as they could replace their licensed solutions with open source code and avoid the support contracts.
That's a really novel idea. But I suppose it would all depend on how modular the codebase is. If there's any doubt about where Adobe's code ends and company X's code begins you'd be back to square one-- especially given that company X could easily exploit any ambiguity to scare hobbyist developers from an effort to fill in the stubs.
If I recall correctly, some of the reference implementations of .NET were somewhat like this; I remember a story about how the GC was pretty naive, because the real one was patent-encumbered, or something along those lines.
Few remember, but Adobe tried to submit a variant of ActionScript 3 as an ECMAScript candidate but the open web folks were dubious and it went nowhere.
That's not the same thing as open-sourcing the Flash authoring tool, but they still sell the modern variant Animate.
They could open source the player, but why bother -- the browser vendors have basically shut the gates. The swf file spec is pretty well documented but the player architecture doesn't map well to 2d canvas performance wise and is nearly a complete impedance mismatch for webgl.
It wasn't the open web people, it was the other companies like Microsoft who killed ECMA 4 as they saw the massive lead Adobe had in corporate Rich Internet Applications and needed to block them.
Was it really less trouble to rewrite the codebase than to enhance something like shumway and run the existing code on a modern platform? I think there's a temptation to view platforms as given, inviolate, and immutable entities, when in reality, we can and should make our own when necessary.
If you go to one of the referenced sites: http://www.vegasworld.com. It asks you to enable flash first then will fall back to the html5 site. I wonder why that fallback is configured.
Doesn't sound that mysterious to me. By the sounds of it, Flash is still their main platform (for performance reasons perhaps), and HTML5 is provided for those who don't have Flash installed. Haxe can target both Flash and HTML5, so this doesn't contradict the article.
It was bad of Steve Jobs and Adobe to kill Flash (and Flex)
Flex allowed building cross platform apps with classic rich GUI. Now we need to do expensive rewritings in HTML / JS where UI programming is still not fully re-invented.
On the one hand, I agree that Apple nixing flash support on iOS seemed manipulative, unnecessary, and disingenuous at the time. It's part of a pattern of behavior from Apple I greatly dislike (unnecessarily failing to support standards under claims that doing so is superior--I say this as someone who happily owns Apple devices, as well as other companies'). It seemed premature.
On the other hand, the demise of Flash seemed obvious in the long run, with all the other standards and alternatives that were developing, and problems with the platform that never seemed to be addressed well. It seems like there's been a number of pieces out there lately eulogizing Flash, and although I understand its appeal, I don't really have a lot of sympathy for the idea that its demise was unanticipated. Even if Apple hadn't disabled Flash, the same outcome probably would have occurred. It just would have happened more gradually, with a more natural transition (which is important and why I have mixed feelings about all of this).
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.
Remember when basically everyone was using flash to play video? Would we really be in a better place if that had continued?
(The one thing that doesn't hold up imo was the desire to not allow native apps using 3rd party intermediate APIs. Tons of apps are made that way now, and it's fine. Jobs' worry about hurting the platform because of the 3rd-parties not picking up the latest native APIs mostly hasn't come to pass, because iOS is so dominant that there's a strong competitive advantage/drive to quickly adopt new stuff. But it was probably a reasonable worry at the time.)
>Jobs' position was they couldn't make flash run acceptably on mobile devices, so they never allowed it.
I have a bridge to sell you too!
He took that position so that everything would be forced to go thru the app store. Flash apps can run on iOS right now, but they have to go thru the app store.
People wrote a TON for flash games, most of it was shit, but some was amazing and creative. Much like what you see in the app store now.
I find the arguments convincing because they make sense to me. There's 0% of me as an iPhone user that's like, "man, I wish Apple had done more to extend the lifetime of flash."
And think about it: If Apple's only goal were to push people to the App Store, why bother to build a mobile browser with good html5 support? Why add a special mode where you could add websites to the home screen as icons, and they'd show up just like normal apps, launching into full-screen mode w/o chrome?
Maybe I'm buying bridges, but I take Jobs' at his word in the flash letter.
(Though, no doubt! Apple does love having ultimate control via the App Store.
(Which, as a completely separate topic, is terrible. They censor the whole thing to a PG-13 level and reject apps for arbitrary political reasons (e.g., a drone-strike notification app, Gab).
(It's truly a shame that the most important medium of our time is run like a totalitarian state.)
They weren't supporting Flash long before the App Store was a thing.
I'm more inclined to believe that Adobe couldn't make a decently performant version of Flash for ARM that didn't eat battery power like a fat kid locked in a candy store.
> 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.
I disagree. The early iPhones had to be memory constrained to get reasonable battery life (CPUs can be switched off, but RAM eats power even when your phone is asleep).
Supporting Flash would have resulted in a system running, effectively, multiple independent graphic subsystems, each with their own font and web cache. Users would have blamed the platform for the resulting performance problems.
Also, Steve had seen what happened to OS/2. Once it supported Windows APIs, as good as nobody wrote OS/2 applications anymore, killing the platform. With zillions of Flash games out there, the same would have happened to iOS.
I generally do not like Steve Jobs (at least as a business person), but killing Flash was the right thing to do, regardless of whether he did it for the right reason.
I really, really liked Flex. I built several iPad and iPhone apps with it back in the day as it was just so much more accessible than XCode and Objective-C. To this day I still say it was my favorite environment and language to build in (AS3).
We had a quite large Flex AS3 Business analytics Flash App (100K LoC). We had to rewrite it to get away from Flash plugin and because of Haxe+HaxeUI+OpenFL we saved literally 1 year of development+testing. Haxe also allows us to maintain and improve a web + native app with a single code base with a very small team.
Compilation errors and strict typing IMHO is a must for your own peace of mind, when you are dealing with a big code base.
I could say Haxe and its ecosystem has saved our company from dying along with flash plugin.
I was a Flash dev for a decade and I'm not sure I agree with you.
On one hand AS3 was a much better language 10 years ago than JS is today.
But OTOH when I was doing UIs in Flash I always missed HTML and CSS.
The good thing about Flash is that you could make stuff that was impossible otherwise, but once HTML5 was here why chose Flash? It was slow and a battery hog.
Steve Jobs didn't kill Flash, it died under its own weight or probably Adobe let it die. Maybe Adobe thought investing in AS4 didn't make sense considering everyone was moving to HTML5.
>>Backed by a codebase of more than one million lines of ActionScript and a game suite that makes nearly $1 million in revenue per month, we knew finding the right solution was not going to be easy.
Only in the short term. In the long run its more than worth it because:
- It will be impossible to hire good AS3 experts. You will need to pay mountains of money to train juniors or hire the remaining experts. Programmers will always want to try the new shiny thing, which they cant adding more HR problems.
- Now they will need to maintain the AS3 -> new tech compiler too. New tech evolves constantly breaking your compiler.
- Current tooling will show its age quickly. The official IDE for Flash is an outdated Eclipse plugin that wont work without patches. JetBrains has an excellent plugin, but its in maintenance mode who knows when they drop it. Also profilers, debuggers,...
If you don't fight the tech dept you will end up like banks where it takes a day to make a simple money transfer because everything core is running on mainframes in COBOL.
I know a few freelancers who made a living doing Flash stuff and they stopped right after Apple said it wouldn't be a thing on iOS, because their project requests dropped dramatically.
This article bugs me because they don't clearly identify the author. There is a Doug Pearson I used to work with at Activision. He was a stand up guy. But I really can't tell if that is who wrote this. What worries me is that companies push people in the game industry to write post-mortems promoting their technology.
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 promised to maintain support for another 10 years.
Edit: removed specifics about my school and computer model to avoid distractions.
The only time I bother with Flash is when I have to for an educational purpose--that is the only situation I can imagine using Flash for a net gain. No form or amount of entertainment is worth it.
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
They mention Facebook switching away from HTML5, but I think Facebook is using the actual DOM, whereas their game would be using the canvas part of the HTML5 spec.
Later they mention WebAssembly replacing HTML5, but what it's really replacing is JavaScript, and the actual canvas that you're rendering to will stay the same afaik. The impact on performance would probably be as they predict, but overall, their issues seem to be with JavaScript, not HTML5.