TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

From native code to browser: Flash, Haxe, Dart or asm.js?

95 点作者 bufo超过 10 年前

9 条评论

protoduction超过 10 年前
There are other paths for Haxe, although they are probably not pretty. That is Haxe -&gt; C++ -&gt; Emscripten -&gt; asm.js. Then there is another, Haxe -&gt; Java -&gt; GWT -&gt; JS.<p>I think Haxe is underappreciated for areas other than game development. You can write serverside logic with it (compile to js for node.js, php, neko, java, c#, python), and target flash and js in the browser.
评论 #8622430 未加载
评论 #8621402 未加载
christoph超过 10 年前
Haxe + Flambe really is a nice combination for developing 2D games for us at the moment. We cover old browsers with Flash (IE6 etc.) and modern browsers - either canvas or WebGL, with almost no concern about which ends up running in the end on the client. It almost feels like magic at times. The compiler also generally seems very fast as well.<p>Sublime text makes a nice(ish) IDE with free plugins.<p>Additionally, we can relatively easily compile out iOS and Android binaries should we want&#x2F;need to. It&#x27;s a very nice system to work with and has caused us very little problems with just getting things done.
评论 #8622684 未加载
wtetzner超过 10 年前
&gt; A lesson to future compiler makers: if you want your compiler to be really fast use OCaml, not Java!<p>Another option the author could have explored is js_of_ocaml. It compiles OCaml bytecode to JavaScript. It works quite well in my (somewhat limited) experience.
johnyzee超过 10 年前
GWT is still a very viable option for writing JavaScript applications, if not actually the best one. It is one of (or the?) first transpiling tools and very mature and feature rich (transparent RPC&#x2F;serialization, obfuscation&#x2F;deobfuscation, IDE integrated debugging, i18n, resource bundling, code splitting, JavaScript interoperability, etc.).<p>The author seems to have a bit of a bias (Dart&#x27;s designers &quot;ate too much Java for breakfast&quot;), but Java is rock solid, and being able to write the entire application, from the client and the domain model on down to the backend, is a major boost. GWT also has a vibrant community (see f.ex. the GWT.create() event across US and Europe: <a href="http://gwtcreate.com/" rel="nofollow">http:&#x2F;&#x2F;gwtcreate.com&#x2F;</a>) and lots of invention and development going on, with a huge new release (2.7) coming up.<p>See my game project for an example of GWT in action: <a href="http://www.webworks.dk/html5engine" rel="nofollow">http:&#x2F;&#x2F;www.webworks.dk&#x2F;html5engine</a>
评论 #8621448 未加载
评论 #8622553 未加载
espadrine超过 10 年前
&gt; <i>I don&#x27;t know how exactly Emscripten handles the uints question but everything worked well and pretty fast without me having to worry about it and having to turn uints into ints.</i><p>Isn&#x27;t that a bit cheaty? IE is potentially a lot faster with that change, which Haxe&#x27;s port benefits from. Haxe&#x27;s port got more work put into, so proclaiming it a winner because Emscripten was already pretty fast without any work put into the port makes me doubtful of the results.<p>(Also, Haxe&#x27;s UInt 0xFFFFFFFF not being converted to -1 sounds like a bug waiting to happen.)
TazeTSchnitzel超过 10 年前
Haxe&#x27;s compiler speed probably isn&#x27;t from OCaml, and rather from a much simpler compilation process than is necessary for Dart or emscripten.
评论 #8621797 未加载
Pharohbot超过 10 年前
For Dart, it wasn&#x27;t fully valid. The problem was that they used the 32-bit VM on a 64-bit machine. Of course, the Dart team is working on fixing the number boxing on the 32-bit version that resulted in the poor performance, but the 64-bit performance would&#x27;ve been better, as outlined in the article.
amelius超过 10 年前
It would have been nice to see NaCl in a side-by-side comparison with asm.js.
评论 #8621443 未加载
评论 #8623106 未加载
bigredhdl超过 10 年前
Thanks for sharing. I leaned a lot from your comparison.