adambeynon changed the topic of #opal to: - Ruby runtime and library on top of Javascript | 1.0.0 is near | This channel is logged at
ylluminate has joined #opal
e_dub has quit [Ping timeout: 264 seconds]
e_dub has joined #opal
barry__ has joined #opal
barry_ has quit [Read error: Connection reset by peer]
barry___ has joined #opal
<e_dub> adambeynon_, improved docs will be great
barry__ has quit [Ping timeout: 265 seconds]
barry___ has quit [Remote host closed the connection]
barry_ has joined #opal
barry_ has quit [Ping timeout: 246 seconds]
fkchang has quit [Ping timeout: 252 seconds]
meh` has quit [Ping timeout: 260 seconds]
dragonkh has quit [Read error: Connection reset by peer]
dragonkh has joined #opal
ryanstout has joined #opal
fkchang has joined #opal
<ryanstout> so I missed some conversation yesterday about require's. I'm just curious, would it be possible to have a mode where there were some AST transforms and normal requires were made into async requires. (By placing the rest of the file into a callback off of each require) One thing I would love to see is having it where files are first loaded asynchronously when needed via opal, then a backend framework could start to see that "page x uses files y,z", so th
<ryanstout> it would just send them on the initial request. But it could basically learn what files are needed. It might not be possible, but I thought I would throw that out there.
e_dub has quit [Ping timeout: 264 seconds]
e_dub has joined #opal
ryanstout has quit [Quit: ryanstout]
fkchang has quit [Ping timeout: 260 seconds]
ylluminate has quit [Quit: Bye!]
ryanstout has joined #opal
ryanstout has quit [Client Quit]
_whitelogger_ has joined #opal
marcandre has quit [Remote host closed the connection]
e_dub has quit [Ping timeout: 264 seconds]
e_dub has joined #opal
barry_ has joined #opal
barry_ has quit [Ping timeout: 246 seconds]
DouweM has quit [Read error: Connection reset by peer]
dfranciosi has joined #opal
barry_ has joined #opal
elia has joined #opal
barry_ has quit [Ping timeout: 246 seconds]
elia has quit [Quit: (IRC Client:]
elia has joined #opal
<dragonkh> morning
<elia> dragonkh, morning!
<dragonkh> elia: hi - thanks for answering my question on pure.js :)
<dragonkh> elia - I have decided not to use it as I can do everything I need in ruby more easily - one interesting point though is if it is possible to construct the directive used at the bottom of the page here: where they pass in a function
<yazgoo> Hi, if I was to write a pouchdb integration, how should I proceed ?
<dragonkh> oh pouchdb looks pretty cool - never seen it before
kludge` has quit [Ping timeout: 260 seconds]
<dragonkh> yazgoo - I don't know much about opal but I guess you would put the pouchdb js files next to your opal file and do require 'name-of-js-file-without-.js' for each file and then use it as described
<elia> yazgoo, you can have a look at how opal-jquery brings jquery into opal
<elia> yazgoo, or you can use native as opal-browser does
kludge` has joined #opal
<dragonkh> brb
dragonkh has quit [Quit: Bye!]
<yazgoo> Ok, cool.
<yazgoo> Opal replaces #@native with window.history ?
<elia> yazgoo, yeah, Native puts the native object inside @native
<elia> and acts as a nice wrapper
<elia> s/nice/basic
<elia> the nice wrapper is Native::Object
<yazgoo> Would you have an example of nice wrapper usage ?
dragonkh has joined #opal
elia has quit [Read error: Operation timed out]
<dragonkh> back
elia has joined #opal
elia has quit [Client Quit]
elia has joined #opal
barry_ has joined #opal
barry_ has quit [Client Quit]
<adambeynon_> yazgoo: here is an example of wrapping using `@native` for events in opal-jquery:
<yazgoo> adambeynon_: thanks :)
<adambeynon_> yazgoo: the second approach is to just use a lot of methods with simple x-strings
<adambeynon_> e.g. I use something like this for local storage:
<adambeynon_> you could use the native stuff directly: `$$.localStorage.setItem('user_id', 42)`
<adambeynon_> but, I generally prefer wrappers for nicer ruby-like apis..
<dragonkh> arg - my remote connection to work keeps dropping! guess everyone works from home on a friday
<dragonkh> I'm still getting my head around the possibilities with opal - but I think it reduces the need for many of the javascript libraries since you can now write your own in ruby
<dragonkh> I guess writing wrappers for the larger js libraries - in the same way opal-jquery would be a good thing as well
DouweM has joined #opal
<dragonkh> elia or adambeynon_ - what is the general strategy used when opal-jquery was implemented - e.g. it just has a few classes e.g. Element, document etc - but they mostly just have methods which have `$(#{selector})` but return the Element instance
<dragonkh> so is opal-jquery actually written in opal? and gets compiled into js by the opal compiler?
<dragonkh> and how does the %x{ javascript stuff in here} get evaluated? in the top of element.rb theres some just sitting outside the class at the top of the file - which makes me think something loops around all the files and does an opal compile on them at somepoint?
<dragonkh> sorry about all the questions
<dragonkh> ping me if anyone gets some time to give me a explanation of opal-jquery implementation
<adambeynon_> dragonkh: so, the %x{...} stuff in element.rb is to allow Element to work with either jquery or zepto
<adambeynon_> also, Element isnt a wrapper, it is bridged
<adambeynon_> like Array instances are just javascript arrays
<adambeynon_> we dont wrap jquery, but add our Element methods directly to jquery instances
<adambeynon_> I think jquery does this with $.fn.pluginName = function() { .... }
<adambeynon_> that is only because jquery is awkward, and does some silly checks about the constructor and stuff when calling methods
<adambeynon_> any code inside x-strings or backtiks just gets passed directly through to the output
<adambeynon_> all the corelib is written using x-strings as its pure js, so much faster
<adambeynon_> Document is an instance of Element
<adambeynon_> basically, Document = `$(document)`
<adambeynon_> also, we have Window = `$(window)`
<adambeynon_> they also have $document and $window aliases, but I really dont like global variables in ruby, so I dont personally use those aliases
<adambeynon_> the reason Event wraps events, instead of bridging like Element, is because zepto and jquery use different objects internally
<adambeynon_> so it was too difficult to bridge them
<adambeynon_> zepto uses the real native dom event
<adambeynon_> where as jquery is a wrapper of the native element
<adambeynon_> event*
* adambeynon_ should probably write this down as documentation really
<dragonkh> ah I see
<adambeynon_> dragonkh: with Element, I guess performance might come into it as well
<adambeynon_> jquery is already a wrapper
<adambeynon_> and if we create another wrapper around that wrapper - that just seems to much wrapping
<adambeynon_> same reason why we bridge strings and numbers to native js strings/numerics
<adambeynon_> things like localstorage though can afford to have a nicer ruby wrapper
<adambeynon_> you only access them now and again
<dragonkh> so in my application.rb running as a sprockets app - can I use `` or %x{} to execute js ?
<adambeynon_> dragonkh: yeap!
<adambeynon_> I see that as a really crucial feature of opal
<adambeynon_> at any point, you can drop down to native js
<adambeynon_> dragonkh: I try to encourage using `foo` for one-liners
<adambeynon_> and %x{ bar } for multiline javascript
<adambeynon_> they both also support interpolation
<dragonkh> hmm
<dragonkh> def go(selector) `return document.getElementById(selector);` end ; p go('cool')
<dragonkh> I expected that to give me something other than nil
<dragonkh> in my html : <div id="cool">this is cool</div>
<adambeynon_> dragonkh: what did it print to the console?
<dragonkh> nil
DouweM has quit [Quit: Leaving...]
<dragonkh> this works tho - p `$('#cool')`
<dragonkh> gave me empty Element
<adambeynon_> dragonkh:'body'%5D%20%3C%3C%20Element.parse(%22%3Cdiv%20id%3D'foo'%3Ehello%3C%2Fdiv%3E%22)%0A%0Ap%20Native(go('foo'))
<dragonkh> - gives nil on the console
<dragonkh> arg cant get that url - my client has muddled it
<dragonkh> adambeynon_ ah got the link - it only seems to work in chrome and not firefox!
<dragonkh> the link that is
<adambeynon_> dragonkh: ok, I will check that out to see why firefox isnt liking it
<dragonkh> im still getting nil in my console
<dragonkh> adambeynon_ - not sure what is happening but I still get nil in my sprocket app - I can see on the try me it works
<dragonkh> adambeynon_ - aha I wrapped it in a Document.ready? and it works now
<adambeynon_> dragonkh: ahh, of course. forgot about that :)
<dragonkh> adambeynon_ so what is the Native doing? if I dont wrap the call to go in the Native - I get an uncaught TypeError saying object HTMLDivElement has no method $inspect
<adambeynon_> dragonkh: so, the result of your `go()` method will be native dom element. `Kernel#p` basically calls `#inspect()` on whatever it gets passed
<adambeynon_> that native dom element doesnt define the method
<adambeynon_> `Native(object)` creates a ruby wrapper around native javascript objects
<adambeynon_> and uses method_missing to send methods to it
<adambeynon_> Native#inspect handles returning a nicer string representation of the object
<adambeynon_> I think it uses .toString()
<dragonkh> ah that makes sense
<dragonkh> so if I use `$('#cool')` instead it returns the opal-jquery Element - so only when I make a call to native js I need to wrap the return in a Native
e_dub has quit [Ping timeout: 264 seconds]
<dragonkh> so it would make more sense in my go method to put the Native call there e.g. def go Native(`document.getElementById('cool')`)) ; end to better encapsulate it
e_dub has joined #opal
<dragonkh> adambeynon_ well thanks for your help - that has give me sufficient understanding to get going with some stuff :) :)
<adambeynon_> dragonkh: yes. When I write wrappers like that, I try to have the methods return real ruby objects. I dont like converting back and forth between them
<adambeynon_> dragonkh: if you dont like jquery, there is opal-browser as well which is a pure dom lib
<adambeynon_> and probably a nicer ruby syntax
GitHub148 has joined #opal
<GitHub148> 584e759 Adam Beynon: Add initial jquery/zepto docs
GitHub148 has left #opal [#opal]
<GitHub148> [] adambeynon pushed 1 new commit to master:
DouweM has joined #opal
e_dub has quit [Ping timeout: 264 seconds]
e_dub has joined #opal
elia has quit [Quit: (IRC Client:]
elia has joined #opal
elia has quit [Client Quit]
elia has joined #opal
e_dub has quit [Ping timeout: 264 seconds]
e_dub has joined #opal
marcandre has joined #opal
lectrick has joined #opal
fkchang has joined #opal
elia has quit [Quit: (IRC Client:]
meh` has joined #opal
elia has joined #opal
elia has quit [Client Quit]
elia has joined #opal
GitHub130 has joined #opal
<GitHub130> [opal-jquery] svoboda-jan opened pull request #34: fix, return the status_code in http.rb (master...fix_status_code_on_http)
GitHub130 has left #opal [#opal]
<meh`> adambeynon_, ping
<adambeynon_> meh`: hiya
<meh`> adambeynon_, I was thinking about the issue of not knowing what the main file is
<meh`> the only solution I see is having an Opal.main JS helper
<adambeynon_> meh`: yeh, that's the part I don't like about it. It's what I had back in the early days
<meh`> adambeynon_, I don't see any other way, unless you can track what the first require was
<meh`> adambeynon_, sincerely, this downside is worth the semantic consistency with Ruby
<meh`> seriously, as of now you CANNOT run most gems unmodified
<meh`> wanted to run parslet, can't because of require order
<meh`> wanted to run color, can't because of require order
<meh`> even my own gems would have those problems
<meh`> we could also have autoload working correctly now
<meh`> it's worth it
ryanstout has joined #opal
<adambeynon_> meh`: if there is a way to do it without opal.main() then yes, bit I think that's going to be difficult with sprockets
<meh`> adambeynon_, even if Opal.main was needed, this must be done
<meh`> if we can't run gems as is, it's pointless
ryanstout has quit [Quit: ryanstout]
<adambeynon_> adambeynon_: I'm not adding it if we need an explicit opal.main call. That's going to be a huge pain.
<meh`> adambeynon_, how so?
<meh`> the user always knows his main file
<meh`> in what situation doesn't he?
<meh`> how do I run these gems without these changes?
<elia> adambeynon_, could be a compilation option
<elia> adambeynon_, and that will push also for better caching controls on the sprockets side
<meh`> I don't see where the pain of an Opal.main call is sincerely
<elia> meh`, to me: 1) kinda global 2) dislike the word "main"
<meh`> I'd rather have an Opal.main than being unable to use Ruby gems as is
<elia> agree on that
<meh`> I don't like the Opal.main either
<meh`> but it's worth running Ruby gems as is
<meh`> people bitch about being unable to use JavaScript libraries with Opal as easily as with CoffeeScript
<meh`> well, the counterargument is, you can use any Ruby gem
<meh`> but this is not the case currently
<elia> my proposal is Opal.compile('color', load: false) or something similar to compile as requireable
dfranciosi has quit [Remote host closed the connection]
<elia> leaving, i'll check the transcript :)
DrShoggoth has joined #opal
elia has quit [Ping timeout: 272 seconds]
dfranciosi has joined #opal
ryanstout has joined #opal
dfranciosi has quit [Remote host closed the connection]
<fkchang> ryanstout: have u see jubiliee?
marcandre has quit [Remote host closed the connection]
<e_dub> it's pretty interesting. i've been following vertx a long time
<ryanstout> fkchang: yea, thinking about using it for my framework
<ryanstout> I'm just not sure if being jruby only will turn people away
<fkchang> ryanstout: meets my needs of "giving the perks of node.js on the server, but in ruby" and more, but w/all ur production stuff in jruby, I figure u'd be keen on it
<fkchang> the eventbus feature seems great
<fkchang> perfect for a spike I need to do
<ryanstout> fkchang: yea. The other thing is jruby is going to get some major performance improvements in the next year. Between the new IR and truffle, should blow MRI out of the water:
<ryanstout> yea
<ryanstout> the clustering stuff in vertx is really nice
<e_dub> the eventbus / websockets stuff is super slick
<e_dub> with opal on the front end, i think you could probably pass ruby objects around like dbr
<fkchang> e_dub: that'd be cool
<e_dub> do you know if jubilee still gives you the ability to do stuff like use vert.x polyglot stuff, and vert.x modules, etc and spin up verticles and whatnot?
<ryanstout> e_dub: I think its early, so I think some of that stuff is still in process
<e_dub> cool
<e_dub> initially the polyglot stuff was what interested me, although these days that's much less the case. I was just stepping out of the node.js world and still thought I might sometimes want to write coffeescript lol
fkchang has quit [Ping timeout: 246 seconds]
DrShoggoth has quit [Remote host closed the connection]
DrShoggoth has joined #opal
e_dub has quit [Ping timeout: 264 seconds]
e_dub has joined #opal
elia has joined #opal
elia has quit [Remote host closed the connection]
elia has joined #opal