These are chat archives for opal/opal

7th
Sep 2018
Simon George
@sfcgeorge
Sep 07 2018 08:45
An easier way to move all Opal stuff to Webpack would be my vote, as Sprockets is slow and Webpack does so much more. Sourcemaps take ages each page load too, but I think that would be fixed with Webpack.
Elia Schito
@elia
Sep 07 2018 08:46
Probably an officially supported opal-webpack repo would make sense then
Simon George
@sfcgeorge
Sep 07 2018 08:46
Yeah :) Just saw your other comment about merging sourcemaps, that sounds good too.
Elia Schito
@elia
Sep 07 2018 08:48
I'm about to release the update right now :smile:
Simon George
@sfcgeorge
Sep 07 2018 08:48
🤯
Elia Schito
@elia
Sep 07 2018 08:52
@sfcgeorge backstory: this summer I did a rework of sourcemaps on master fixing a bunch of pending problems, along the way they were transitioned to fully inline. The conversation spun by @ylluminate made me wonder if the whole source-map harness could be simplified even for currently released versions, and it proved incredibly simple to do :tada:
Simon George
@sfcgeorge
Sep 07 2018 09:05
@elia Ah nice :)
I was just wondering if ES6 string tagged template literals would enable us to differentiate between strings and symbols, but no it would still introduce overhead.
Simon George
@sfcgeorge
Sep 07 2018 09:11

I thought maybe this would work:

var str = symbol`hello`
str.tag == "symbol" // doesn't exist

But there's no API to get what tag was used, so you'd have to do something like this:

function symbol(strParts, subs) {
  var str = strParts.join()
  str.tag = "symbol"
  return str
}

var str = symbol`hello`
str.tag == "symbol"

But then you've added that method call overhead anyway.

Elia Schito
@elia
Sep 07 2018 09:13
From my experience so far having them mixed is nothing but an improvement, I also recall something about matz wanting to merge them into frozen strings, but I'm not sure about that

/@all I just released opal-jquery 0.4.3 with opal-0.11 compatibility, the specs are still not working but has been in production for over a year and it's time to move on, sorry for the long wait! https://rubygems.org/gems/opal-jquery/versions/0.4.3


(0.4.3)[https://github.com/opal/opal-jquery/compare/v0.4.2...v0.4.3] 2018-07-24

  • Add Element#== as an alias of .is()

  • Add Element#method_missing to allow not yet wrapped methods and plugins to be accessed with zero setup

  • Avoid || in JS-land because it would consider some values as falsy (e.g. "" and 0). breaking

  • Call Element#prop via Native.call to get the right semantics around nil vs. undefined breaking

  • Expose Element#click

  • Fix semantics of Element#attr to better reflect jQuery's breaking

  • Skip sending a callback to Element#animate if no block is given

  • Let Element#data return a usable Ruby object (Array/Hash) instead of a native one breaking

  • Don't wrap events with Event.new if no args are provided or the event is not a native object to increase performance in Element#on and Element#one

  • Rename the internal property holding the callback wrapper in Element#on and Element#one from ._jq_wrap to .$$jqwrap to avoid polluting instance variables and following the custom of Opal's core classes

  • Fix Element#value, Element#height and Element#width to perform the || at ruby level to avoid overwriting values that are falsy in JavaScript with nil breaking

  • Add Element#== as an alias to jQuery's .is()

  • Add Element#method_missing and Element#respond_to_missing? to forward calls to native plugins

  • Add HTTP#inspect with a basic summary

  • Updated specs to also use jQuery 3

  • Allow Opal v0.11.0

Simon George
@sfcgeorge
Sep 07 2018 09:17
@elia There is talk of merging them and I can see the arguments. Personally I like them separate, I like that conceptually you have "identifiers" and "data", though that line has blurred as Symbol has gained methods from String. Practically, lots of APIs in Rails rely on being able to distinguish between the two, so it's not possible to port certain Rails APIs to Opal without changing them. Nonetheless I don't think it's worth the performance hit, and for most people it is fine merged.
Elia Schito
@elia
Sep 07 2018 09:19
yeah, the conceptual division is good, but maybe it can stay as just an aesthetical difference, like in opal where I use symbols all the time :)
we'll see :smile:
Elia Schito
@elia
Sep 07 2018 10:35

/@all opal-sprockets 0.4.2 is out (Rails users should wait until I release opal-rails 0.9.5 that has explicit support for it)

https://rubygems.org/gems/opal-sprockets/versions/0.4.2.0.11.0.3.1


v0.4.2

7 September 2018

  • Inline source-maps with their source-contents for better performance and simpler architecture
Simon George
@sfcgeorge
Sep 07 2018 10:43
IMG_1648.GIF
Elia Schito
@elia
Sep 07 2018 12:54
/@all here we go: opal-rails v0.9.5 https://rubygems.org/gems/opal-rails/versions/0.9.5

0.9.5 - 2018-09-07

Added

  • Added support for inline source-maps provided by opal-sprockets 0.4.2+
  • Added Rails 5.2 to the test matrix

Removed

  • Removed support for Opal v0.10
ylluminate
@ylluminate
Sep 07 2018 13:17
wow, you're a machine @elia
so where does everyone think our conversation needs to go in order to make a proposal or some kind of suggestion for tighter integration and what form should that be to bring us to parity with options like coffeescript?
ylluminate
@ylluminate
Sep 07 2018 13:26
(btw, i thought about bringing this discussion up on reddit, but that community is such a mixed bag that i figured we should probably keep it tight and neat here until things are sorted out on the fully "pro" community)
Elia Schito
@elia
Sep 07 2018 13:30
so, has anyone enough experience with webpack/rails/opal or just wants to start maintaining that project inside github.com/opal ? is there an already established opal-webpack that can be migrated to the org? (with the author's permission of course)
Jan Biedermann
@janbiedermann
Sep 07 2018 13:52
https://github.com/janbiedermann/opal-webpack-loader
i would not consider it established, its fresh, but it makes opal code build and run with webpack, depending on the es6_import_export PR. Not sure how that would work with the webpacker gem though.
That webpack loader is of course more complicated than using Opal::Builder, but it allows for dynamic imports and therefor lazy loading of opal code, which is great to reduce the size of the initial asset loaded.
Barrie Hadfield
@barriehadfield
Sep 07 2018 16:15
@elia thank you so much! The hundreds of source maps was the biggest issue with Opal Sprockets, so that is a huge improvement. Weppacker is an interesting beast, but one that should be mastered to keep Opal close to the Rails world - who knows - they might wake up!
Elia Schito
@elia
Sep 07 2018 16:37
@barriehadfield good to hear that was the right problem to attack, let me know how it goes with the new inlined setup
@janbiedermann I was looking at that PR just the other day, trying to make opal "use strict" compatible without sacrificing force_encoding, but then I had to stop, be assured I'll pick it up again