<adambeynon>
do you have specs for Vienna::Views ?
<elia>
adambeynon, hi there, all fine during holydays?
<elia>
adambeynon, no specs, I attempted once, but the html/css setup was too hard
meh` has joined #opal
elia has quit [Quit: Computer has gone to sleep.]
elia has joined #opal
e_dub has joined #opal
e_dub has quit [Ping timeout: 240 seconds]
grios has joined #opal
grios has quit [Quit: grios]
e_dub has joined #opal
<adambeynon>
elia: yeh, same for me. I have been writing some today though, and have a very capybara inspired dsl for opal-rspec which is helping a lot
<adambeynon>
going to add it into vienna repo later
<adambeynon>
you might find it useful
<meh`>
adambeynon, found another bug with super
<adambeynon>
meh`: just saw it :) didnt realise that was the intended behaviour
<meh`>
neither did I until I hit it sincerely
<AndrzejKrzywda>
I just wanted to say that what you're doing here is fantastic and can be HUGE for the Rails community one day :)
<meh`>
AndrzejKrzywda, yeah, it would be nice, both adambeynon and elia are going in that direction I think
<meh`>
I'm going my own direction ◕ ◡ ◔
fkchang has joined #opal
<adambeynon>
meh`: as in, non-ruby based server? or?
<meh`>
adambeynon, yes
<meh`>
no integration with rails whatsoever
<meh`>
I don't use nor care about rails
<meh`>
I want to get rid of Ruby on the backend
<meh`>
or complex backends
<meh`>
I want a simple backend and a complex frontend
<meh`>
and I want the frontend in Ruby
<adambeynon>
meh`: what do you want to use on the backend instead?
<adambeynon>
erlang?
<adambeynon>
javascript? :)
<fkchang>
meh`: and my 3rd direction is to do both sides in opal, in a meteor-ish fashion, though at the moment I lean towards the front end being lissio, because I like DSL/components
<adambeynon>
fkchang: both sides is what Im liking at the moment
<adambeynon>
render templates front + backend
<adambeynon>
(render initial template server side, and go from there)
<meh`>
adambeynon, Elixir or Erlang, yes
<meh`>
mostly Elixir
<adambeynon>
why not Elixir on the front end as well? Genuine question - I havent used it yet, so I dont know what its like
<fkchang>
adambeynon: my biggest deal w/opal both sides, is I don't want to rewrite Rails
<meh`>
adambeynon, I find it pointless
<meh`>
the good of Erlang comes from OTP and the way it all scales and is resilient to errors
<meh`>
the good of Elixir is a decent homoiconic language on top of Erlang
<fkchang>
I figure it's easier to implement rack and sinatra on opal-node and then we might be able to use a lot of stuff from there
<adambeynon>
fkchang: Nor me. I have very thin model classes client side. Basically attributes, with a glorified ajax system for save/delete/etc
<fkchang>
adambeynon: rack on opal-node might be a worthwhile experiement to reuse stuff from the rack ecosystem
<adambeynon>
fkchang: I did start writing an adapter for rack w/ node
<adambeynon>
could be a fun weekend hack
<elia>
adambeynon, yay! I think I have some opal-node updates locally, could be handy for "require" handling
<fkchang>
elia: I was going to ask u about changes for opal-node, cuz I remember you mentioning something about it in irc. Updates forthcoming, I'm guessing
<elia>
fkchang, yes, CBDD (crying baby driven development) isn't the fastest among agile methodologies, so I'm a bit late :)
<fkchang>
elia: CBDD, I'm familiar w/that, several times over
<AndrzejKrzywda>
practicing CBDD often as well :)
<fkchang>
AndrzejKrzywda: I saw u had a question on new years, did u figure it out
<meh`>
AndrzejKrzywda, we know for sure angular is basically impossible with opal
<meh`>
AndrzejKrzywda, they heavily rely on syntax bullshit
<meh`>
like parameters having to start with $
<meh`>
and it just smells all around
<ryanstout>
meh`: I think we can do way better than angular with a framework built for opal :-)
<meh`>
ryanstout, I know, that's why I'm working on lissio :D
<fkchang>
adambeynon: next week is good
<fkchang>
hey ryanstout what did u think of meh` s idea on reactive in lissio?
<ryanstout>
I think reactive is the way to go, I might have not been around for the lissio reactive discussions
<ryanstout>
fkchang: did you get a chance to check out that video I posted?
<ryanstout>
I need to do a shorter video, I have a bunch more stuff working now.
<fkchang>
ryanstout: sorry, never finished it, should've done it over the holidays but it got pushed out of my memory queue. I did have my coworker who is an ember enthusiast look at it and he thinks u'r going in the right direction. In general, he feels that up to a certain complexity level angular is fine, but past that u need an approach like ember
<ryanstout>
I have all of the reactive stuff working at the moment, except for handling blocks reactively, which I think I know how I'm going to do it.
<ryanstout>
mine's kind of a way to do "reactive objects", where it lets you define how events propagate through your objects so its only updating what needs to be updated
<fkchang>
AndrzejKrzywda: interesting, I may have to start making tech videos where I'm walking around outside. I think w/some small tweaks opal could be a really good default for Rails. Vienna on Rails is probably something that fits well as it feels pretty Rails-y/Backboney to me which fits the mindset for a lot of Rails devs now
<AndrzejKrzywda>
meh`: interesting with angular and opal. that will be an ongoing problem or is just an implementation detail for now?
<fkchang>
I think the direction I perceive lissio meh` is taking it in, OO components w/simple rest backend could also fit well, but I'm interesting in getting something meteor-like where the much of the same code is run on both sides, a lissio/opal-node sort of thing, but I"m loathe to reimplement all the stuff that's already in backend ruby
<ryanstout>
fkchang: thats the goal with my framework
<meh`>
AndrzejKrzywda, it will be ongoing, unless angular changes
<meh`>
we can't do anything about it
<ryanstout>
in the next week I should have it where I can get validations running on both sides
<ryanstout>
and I have the data syncing working already
<ryanstout>
have you guys seen derby.js?
<fkchang>
ryanstout: yeah, I believe we voiced the same desires for a framework. I'm thinking, implementing rack on opal-node and using say sinatra on node as the backend might be a good thing
<fkchang>
allowing reuse of rack stuff while trying to do the meteor/lissio thing
<ryanstout>
fkchang: what do you think of doing mri/jruby/etc.. on the backend and opal on the front, but still sharing some code?
ryanstout has quit [Quit: ryanstout]
ryanstout has joined #opal
benyami has quit [Quit: benyami]
<fkchang>
ryanstout: that's doable and probably a reasonable route. I think I wanted the node backed opal for 2 reasons 1) same code will run on both sides 2) the reasons ppl use node over ruby
<ryanstout>
fkchang: what's the reasons ppl use node over ruby?
<fkchang>
but w/MRI/JRuby there will be a subset that should work on both sides. It's a perk to not have to worry about what doesn't run on both sides though
<ryanstout>
yea
<ryanstout>
I personally liked the idea of having access to all of the ruby ecosystem on the backend (and with jruby the JVM ecosystem also)
<fkchang>
ryanstout: I think it's mostly async io, the whole "my app is in ROR, but I made a node.js service to handle chat/websocket/blah"
<ryanstout>
so like if I need html or xml parsing I can bust out nokogori
<ryanstout>
etc..
<ryanstout>
yea
<ryanstout>
you can do all of that with ruby too though
<ryanstout>
have you see vert.x?
<fkchang>
vert.x has been on my radar for while
<ryanstout>
I use jruby in production for everything, so its very appealing to me
<ryanstout>
being able to have a cluster-ready actor framework is awesome too
<fkchang>
I definitely had aspirations of a jruby centric SOA, jruby, clojure, scala all running in torquebox
<ryanstout>
yea
GitHub182 has joined #opal
<GitHub182>
opal/master 5538446 meh: Compliancy fixes for Regexp#match