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

21–30 of 47 posts

Re: Opal: Ruby in Your Browser – the Basics

#21

Post by teacup50 »

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?

No, it's really not.

This is an argument that tries to emotionally justify the limitations of web browsers that force us to compile down alternative languages into web "assembly".

Re: Opal: Ruby in Your Browser – the Basics

#22

Post by akoumjian »

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.

I have been wondering this myself for a while. While I believe there are probably reasons you couldn't exactly map behavior of all of today's popular scripting languages into a common byte-code, you could probably approach something close to it.

Part of the problem is that Webkit has a very narrow mission of wanting to only be standards compliant. This is really holding back innovation given how widely used it is in Safari and until recently Chrome.

It seems to me that in order to make it happen, it would need wide support from one of the major browser vendors.

Re: Opal: Ruby in Your Browser – the Basics

#23

Post by teacup50 »

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.

We may finally see this, if only as a side effect of Eich's departure from Mozilla.

Google and Mozilla are the only mainstream browser vendors that have an incentive to offer a bytecode alternative to the JavaScript status quo, whereas Apple and Microsoft would simply be undermining their respective platform positions.

This means that Mozilla could have worked with Google to form a bloc; Chrome and Firefox would have been the only browsers to support better web technology, and that might have been enough to force Microsoft and Apple's hand.

Instead, Eich stuck to his "JavaScript First" guns for years, wasting market opportunities and in the process, serving as the swing vote that held the entire web back.

I hope that the next CEO of Mozilla realizes that for platforms like Firefox OS to have a snowball's chance in hell, they need to work with Google to move past HTML/CSS/JS.

Re: Opal: Ruby in Your Browser – the Basics

#24

Post by camus2 »

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?

He still have point,what matters is the APIs you have access to,not coding in language X or Y,especially when your goal is not to develop "web pages" but web apps that arent "brochures".

Re: Opal: Ruby in Your Browser – the Basics

#25

Post by Skoofoo »

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.

You have to drop down to JavaScript at some point, though in practice you would not write this much JavaScript mixed with Ruby in an app. The joy of using Opal is having the JavaScript wrapped away in a module, letting you use pure Ruby for your app.

The author used a lot of JavaScript here, likely for teaching purposes, but he could instead have used pure Ruby to interface with canvas using opal-browser. https://github.com/opal/opal-browser/blob/master/opal/browse...

Re: Opal: Ruby in Your Browser – the Basics

#26

Post by ht_th »

akoumjian wrote: post #22
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.

I have been wondering this myself for a while. While I believe there are probably reasons you couldn't exactly map behavior of all of today's popular scripting languages into a common byte-code, you could probably approach something close to it. Part of the problem is that Webkit has a very narrow mission of wanting to only be standards compliant. This is really holding back innovation given how widely used it is in…

Looking at the languages that run on the JVM ( http://en.wikipedia.org/wiki/List_of_JVM_languages ), I'd say it shouldn't be too much of a problem to create that common byte code.

Re: Opal: Ruby in Your Browser – the Basics

#27

Post by adambeynon »

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. Writing a ruby wrapper wasn't worth it for one method call. Anytime I see more then 1 line of inline JS inside a file, a ruby wrapper ends up being a much better idea, or indeed using the `Native` class which handles all the corner issues of calling native JS libs.

I think the problem with Opal is the documentation, which needs huge improvements, to show the proper/realistic development experience with it.

Re: Opal: Ruby in Your Browser – the Basics

#28

Post by adambeynon »

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.

Re: Opal: Ruby in Your Browser – the Basics

#29

Post by xrd »

teacup50 wrote: post #23
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.

We may finally see this, if only as a side effect of Eich's departure from Mozilla. Google and Mozilla are the only mainstream browser vendors that have an incentive to offer a bytecode alternative to the JavaScript status quo, whereas Apple and Microsoft would simply be undermining their respective platform positions. This means that Mozilla could have worked with Google to form a bloc; Chrome and Firefox would have…

Chrome (or rather Chromium) will soon have Dart support built into it. There you go.

Re: Opal: Ruby in Your Browser – the Basics

#30

Post by ohhmaagawd »

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?
Post reply on HN