What Are the Limitations of Opal

What are the limitations of Opal?

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.

Are these valid disadvantages of a REST-ful API?

I do not believe the points you state above are really drawbacks of a RESTful API. More analytically:

REST-ful API unnecessarily exposes models

No models are exposed. Everything is handled by a single controller. The only thing that is exposed to the user is the route of the appropriate controller.

REST-ful API forces one to think in terms of manipulating models instead of the natural behavior of stating intent

Same as above. A single controller can handle the different customer happiness states. The distinction can be made by passing different post paramenters (ex. { state: "happy"}).

REST-ful API Update action oversimplifies too much

Nothing stops you from manipulating the data that needs to be sent to your model before updating it. You can do whatever you want, however complex it may be, before updating your model.

Finally, I believe that a RESTful API is only as good as its implementation. Furthermore, I believe that if you wanted to find a flaw to the REST technique is the fact that you cannot initiate transactions or push notifications server-side

Spock's @Narrative and @Title annotations

Title is expected to be a single line (short description)

Narrative should be full paragraphs (using a Groovy multi-line string)

They are mostly used in big projects where Narrative text could be read by business analysts, project managers e.t.c.

As Opal said these will be more useful once some reporting tools actually use them.

Update:
The Spock reports project now supports these annotations.

coregraphics on gnustep ubuntu

As far as I know, CoreGraphics is not implemented in GNUstep; I believe though that Cocotron has an implementation.

The error error: request for member ‘layer’ in something not a structure or union refers to the expression view.layer, which you intended to return the layer property from the view object. That syntax is from Objective-C 2.0, which wasn't supported out of the box with GNUstep, last I knew; check ObjC2FAQ for information about enabling it (and what its limitations on GNUstep are).

In the meantime, you can instead use the original Objective-C syntax: [view layer].

What Are the Limitations of Opal