Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Opal: Ruby in Your Browser – the Basics

sitepoint.com

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Opal: Ruby in Your Browser – the Basics

#31

Post by teacup50 »

ohhmaagawd wrote: post #30
toddan wrote: post #20

Why is it so hard for browsers to implement a common set of byte-code. Then we all get what we want and it would make it much simpler to port your favorite language to the browser. This compile to javascript trend seems so brittle and frail.

Why is compile to JavaScript any different than compile to byte code? Is the "frail" comment from experience or intuition?

You'd think this would be obvious. It's an inefficient and poorly designed "bytecode":

- The only number representation available is floating point.

- Concurrency is impossible except for the nearly useless web workers API; this prevents a language author from exposing any other type of concurrency mechanism.

- Anyone wishing to implement the "byte code" specification must implement or integrate a full Javascript parser and runtime.

Re: Opal: Ruby in Your Browser – the Basics

#32

Post by ylluminate »

kasperbn wrote: post #12

Very cool project. Like others say, it can be a pain to debug generated code in opal, clojure, elixir etc. But that's also true of the code generated by the C compiler. This is a chicken-and-egg thing. Either consumer hardware gets so fast that it's feasible to implement the language vm's in javascript or browsers will support other mechanisms for implementing them. But only when these projects are used by many peopl…

Opal debugging seems to be better than some of the other ones I've played with.

Re: Opal: Ruby in Your Browser – the Basics

#33

Post by 1qaz2wsx3edc »

davidw wrote: post #18
PuercoPop wrote: post #15

Earlier quoted context omitted.

How is assembly going for you? What is fundamental to the web is the APIs (dom/websockets/webgl/...) not the fact that they are exposed through javascript. Dart seems especially nice considering that they go out of their way to provide (most?) html5 apis in dart and also Angular. In fact the dom is defined in an IDL which can generate the dom API not only in javascript but a lot of other languages (Java/C++/etc)

Javascript isn't really comparable to Assembly though, is it?

Tell that to emscripten...

Re: Opal: Ruby in Your Browser – the Basics

#34

Post by ylluminate »

We're using this on a large'ish project at the moment and thrilled with the productivity gains. Right now we're using Rails 4.1RC2 + Opal and thrilled with the readability that we now have across the board. This is good sized project for several thousand concurrent users and was to test the waters before using for something larger on our plate.

Re: Opal: Ruby in Your Browser – the Basics

#35

Post by ylluminate »

adambeynon wrote: post #28
nnq wrote: post #6

If one needs to write code like: `#{context}.lineTo(#{x}, #{height})` ...you're doing it wrong. Please do figure out a way to "automagically" make things work without `...` or just don't bother. `...` should be a last resort option for when you just need to do something that can't be done any other way, not something that should be peppered over the entire code.

The example in this post is definitely a bad example of inline js in Opal. This is better handled by the `Native` bridge class, or writing a wrapper for it. On the other hand, being able to drop down to native javascript anytime you like is a huge win.

@adam maybe you can give us a tutorial on doing this properly? Opal is amazing and being able to wrap things like ImpactJS and other js libs is enormously powerful.

Re: Opal: Ruby in Your Browser – the Basics

#36

Post by ylluminate »

dham wrote: post #17
nnq wrote: post #6

If one needs to write code like: `#{context}.lineTo(#{x}, #{height})` ...you're doing it wrong. Please do figure out a way to "automagically" make things work without `...` or just don't bother. `...` should be a last resort option for when you just need to do something that can't be done any other way, not something that should be peppered over the entire code.

Yea. They have a canvas wrapper that this guy did not use so you don't have to do that. With that being said, this project https://github.com/rubys/ruby2js is more appealing to me. Sure it doesn't pass more RubySpec tests than Rubinius like Opal does, but it works. The Angular interoperability is especially appealing to me. It also generates readable javascript.

Use opal-browser (https://github.com/opal/opal-browser). Great stuff.

Re: Opal: Ruby in Your Browser – the Basics

#37

Post by RussianCow »

teacup50 wrote: post #31
ohhmaagawd wrote: post #30

Earlier quoted context omitted.

Why is compile to JavaScript any different than compile to byte code? Is the "frail" comment from experience or intuition?

You'd think this would be obvious. It's an inefficient and poorly designed "bytecode": - The only number representation available is floating point. - Concurrency is impossible except for the nearly useless web workers API; this prevents a language author from exposing any other type of concurrency mechanism. - Anyone wishing to implement the "byte code" specification must implement or integrate a full Javascript par…

On top of that, you have no control over memory management (which makes properly implementing lots of languages impossible).

Re: Opal: Ruby in Your Browser – the Basics

#38

Post by sciguy77 »

xxxmadraxxx wrote: post #4
davidw wrote: post #2

I'm not terribly convinced by these things that compile to javascript. I don't much care for javascript, but I'd rather take the bull by the horns than deal with a bunch of generated code, especially in any kind of commercial setting where it's going to be a lot easier to hire JS people rather than people who are both X-lang and JS experts. That said, it's very much a cool hack, and worth doing on that basis alone.

I'm inclined to agree. I'm not one of those Javascript bashers. It's a handy enough language and tweaking/hacking/breaking JS enabled webpages is the way a lot of us amateur coders dip a toe in the water. Unfortunately I think JS is having a lot of responsibility heaped on its slightly creaky shoulders these days, due to the growth in mobile intarwebsing and every man and his dog looking for a quick way to build the…

> Personally I'd rather a scenario where people could code in and embed this in HTML as easily and ubiquitously as JS can be embedded.

That would indeed be amazing. Anyone want to build it? :P

Re: Opal: Ruby in Your Browser – the Basics

#39

Post by jrmiii »

ylluminate wrote: post #34

We're using this on a large'ish project at the moment and thrilled with the productivity gains. Right now we're using Rails 4.1RC2 + Opal and thrilled with the readability that we now have across the board. This is good sized project for several thousand concurrent users and was to test the waters before using for something larger on our plate.

I'm curious what kind of features you have on the client side that you're using this for.

Re: Opal: Ruby in Your Browser – the Basics

#40

Post by jrmiii »

adambeynon wrote: post #27
TheAceOfHearts wrote: post #3

One big problem with this is that you still end up having to use raw JS anyway. Debugging is usually a big hassle too.

Opal creator here. Debugging in Opal is no problem at all with source maps. I only need to look at generated code when Im working on improving the compiler/fixing bugs. Developing end apps always results in using the chrome debugger stepping through source-mapped code. About the raw JS, to use my current app as an example, I have one line of inline JS (using `...` notation) which is just to initialize FastClick. Writ…

What kind of client side coding are you using it for?
Post reply on HN