These are chat archives for opal/opal

20th
Nov 2015
Michał Kalbarczyk
@fazibear
Nov 20 2015 09:57
@fkchang Is webpack hot module replacement works in this configuration ?
Martin Becker
@Thermatix
Nov 20 2015 11:37
could I use opal-webpack to load (for example) crypto-js?
and how?
Michał Kalbarczyk
@fazibear
Nov 20 2015 12:22
Opal related projects/gems in one place :) https://github.com/fazibear/awesome-opal
Martin Becker
@Thermatix
Nov 20 2015 14:55
should I use yardoc for documentation?
meh.
@meh
Nov 20 2015 14:55
for what?
Martin Becker
@Thermatix
Nov 20 2015 14:58
documenting front end code
meh.
@meh
Nov 20 2015 15:00
I like yard
Brady Wied
@wied03
Nov 20 2015 17:22
@fkchang - You can go that direction and also the other direction (NPM into "gems"). I personally like the GEM packaging system better so I'd love rails-assets.org for NPM packages (not just Bower). I do think it's good to support the other direction (opal into NPM) as well though.
Brady Wied
@wied03
Nov 20 2015 17:28
@fkchang - I also don't see why Sprockets needs to go away in favor of webpack. commonjs/requirejs are not exactly relevant in my view because it's not an apples to apples comparison. Opal Ruby modules are already providing the "require" dependency functionality from a runtime perspective. Sprockets covers the actual file dependency piece. I think fixing source maps in concatenated files is on Sprockets' radar (see rails/sprockets-rails#254). I can't make the argument that Sprockets is absolutely better than webpack. I just don't necessarily agree with the reasons in the blog post.
Forrest Chang
@fkchang
Nov 20 2015 19:13
@fazibear do mean does hot module replacement work for opalrb-loader? If so, https://github.com/zetachang/opalrb-loader/tree/master/examples/simple says yes
George Plymale II
@ylluminarious
Nov 20 2015 19:36
@fazibear re: awesome-opal, great job on that! i've been waiting for an awesome-opal for a while and, if iirc, others here like @elia have expressed interest in it too.
Forrest Chang
@fkchang
Nov 20 2015 21:16
@wied03 I think there are advantages to being "1st class citizen" of JS, but something that would let me have things like
  • hot module reloading
  • painless integration of npm js modules (is this actually possible?), -- for react.rb I want to use existing react.js modules, they are all npm distributed and usually ES6, so I always have to process some and the save that as sometihng I require. Extend this to every npm module.
  • the ability to package only the needed assets for an entry point vs "the whole world" approach that sprockets does. I think react-router is really trying to do this and only load the appropriate js needed for particular routes, which ought to improve start up times, etc.
    All of which webpack does, but if we can it else wise, that would be cool. I'm not bound to webpack, but it seems like it's what all the JS ppl are doing, certain the react folks which is where I'm spending a lot of time researching
Brady Wied
@wied03
Nov 20 2015 21:44
@fkchang - the 1st 2 bullets are good reasons IMO. Doesn't the 3rd one come back to AMD vs. not? One could make the case that sending all of the JS so it can be cached is better than having to go back to the server for bits and pieces.
Elia Schito
@elia
Nov 20 2015 22:00
@fazibear awesome! can you send a couple PRs to add the link to the README and to opalrb.org?
never realized there's so much stuff!
meh.
@meh
Nov 20 2015 22:23
@fazibear where's lissio? :((
Elia Schito
@elia
Nov 20 2015 22:51
@meh re yardoc, I'll revert the API docs to yard and rewrite those I written in tomdoc
meh.
@meh
Nov 20 2015 22:51
lol
Elia Schito
@elia
Nov 20 2015 22:52
i still like the sdoc search more, but yes, I repent! :D
also I still delude myself in thinking I'll have time to port the sdoc search to yard :P