What are the limitations of Opal? [closed]

妖精的绣舞 提交于 2019-12-03 02:16:54
Elia Schito

From a Ruby standpoint:

  • Strings are immutable b/c are bridged to JS Strings
  • All Numeric (Integer/Float/etc.) are bridged to the JS Number class
  • Symbols and Strings are the same, they're both bridged to JS Strings
  • no access to some stuff from the browser (File,Thread,System,Process,etc)
  • require is more tricky since there's no filesystem in the browser and as of 0.6.x they're gathered at the top of the file (AssetPipeline style). Things should improve from 0.7.x on (unreleased), (as a sidenote, similar issues are found in RubyMotion).
  • you still need to learn the DOM, and possibly the CSSOM

From a JS standpoint:

  • Math stuff is like in Ruby (i.e. method calls) that means it's slower (like in Ruby) compared to native JS operators; that means you won't probably use opal to write a HTML5 3D game engine
  • no access to properties from outside the class, as in Ruby if you want to access instance variables you need to use methods
  • some particularly convoluted (or if you want, idiomatic) JS libraries are harder to use with just Native or bridged classes (class MyClass < `MyJsClass`; end) and need full blown wrappers (opal-jquery is an example, and that happens all the time in Ruby too, where you seldom use FFI mapped apis directly and always wrap C libraries).

That said you usually can get a lot of stuff done with just using Native or opal-jquery. I personally have found myself moving classes from the backend to the frontend more than once. Testability and code readability surely improves (as long as you write good Ruby) and you can reuse your OOD skills.

I surely may be missing something, anyone is welcomed to chime in. And it will eventually turn into a blog post on http://opalrb.com/blog.

tl;dr

Don't forget you are in a browser. Don't underestimate the power of Ruby.

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!