Thanks to the work [1] of Yuta Saito [2], the TryRuby application now also supports a WASM-compiled CRuby 3.2.0dev backend!
You can try it yourself: TryRuby playground
[1] Add CRuby engine option in playground by kateinoigakukun · Pull Request #120 · ruby/TryRuby · GitHub
What are the trade-offs between Opal and WASM CRuby?
Is it true that WASM CRuby can only execute pure Ruby code that does not
have access to the DOM while Opal has complete access to the DOM just like
JavaScript given that it is a JavaScript transpiler!?
If that were the case, then WASM CRuby is not really practical for actual
web frontend development.
On Thu, Feb 17, 2022 at 5:38 AM hmdne <hmdne@airmail.cc> wrote:
Thanks to the work [1] of Yuta Saito [2], the TryRuby application now
also supports a WASM-compiled CRuby 3.2.0dev backend!You can try it yourself: TryRuby playground
[1] Add CRuby engine option in playground by kateinoigakukun · Pull Request #120 · ruby/TryRuby · GitHub
[2] kateinoigakukun (Yuta Saito) · GitHub
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
--
Andy Maleh
LinkedIn: Andy Maleh | LinkedIn
<https://www.linkedin.com/in/andymaleh>
Blog: http://andymaleh.blogspot.com
GitHub: AndyObtiva (Andy Maleh) · GitHub
Opal will never be as compatible with CRuby as WASM CRuby. Opal has a common type for Symbols and Strings, a common type for Float and Integer, doesn't support mutable String methods, has greatly incompatible Regexps, doesn't have big integers, doesn't have Fibers. Some of those issues will be tackled in following releases. But if you take those issues into mind, you don't notice it's a different implementation too often.
It is certainly possible to create a JavaScript shim, to be interfaced with the WASM CRuby and access DOM, execute JavaScript. The simplest way would be to wrap stdio and create some interface for that. This approach may introduce some latency though.
On the other hand, Opal actually compiles Ruby to JavaScript that can be further optimized via opal-optimizer and JS minifiers. You don't need to include the compiler for production applications if you reasonably limit your use of `instance_eval` and friends. The resulting code, optimized and compressed, can be as low as 100kiB.
As of now, WASM CRuby is 2.88MB compressed. It includes a compiler and takes some time to load. I imagine it would be possible to skip the compiler and ship the Ruby code just as bytecode. If page load time is a concern, this may be a problem.
For performance, I was surprised to note that Opal-compiled code has in general a similar, if not better performance than WASM CRuby. Also both run faster for me in Firefox than in Chromium:
On 2/17/22 14:32, Andy Maleh wrote:
What are the trade-offs between Opal and WASM CRuby?
Is it true that WASM CRuby can only execute pure Ruby code that does not have access to the DOM while Opal has complete access to the DOM just like JavaScript given that it is a JavaScript transpiler!?
If that were the case, then WASM CRuby is not really practical for actual web frontend development.
On Thu, Feb 17, 2022 at 5:38 AM hmdne <hmdne@airmail.cc> wrote:
Thanks to the work [1] of Yuta Saito [2], the TryRuby application now
also supports a WASM-compiled CRuby 3.2.0dev backend!You can try it yourself: TryRuby playground
WASM CRuby is 2.88MB
I think web browsers should just include the implementations of the
most popular languages out of the box, like Ruby, Python, Perl, Swift,
Crystal, etc...
That way, using languages other than JS with WASM becomes more
practical without waiting for users.
I mean, hard drives are terrabytes nowadays, so it shouldn't hurt if
browsers grow bigger a little to support languages other than JS out
of the box. Heck, maybe they can include ALL available WASM languages
out of the box, not just the common ones.
On Thu, Feb 17, 2022 at 9:19 AM hmdne <hmdne@airmail.cc> wrote:
Opal will never be as compatible with CRuby as WASM CRuby. Opal has a
common type for Symbols and Strings, a common type for Float and
Integer, doesn't support mutable String methods, has greatly
incompatible Regexps, doesn't have big integers, doesn't have Fibers.
Some of those issues will be tackled in following releases. But if you
take those issues into mind, you don't notice it's a different
implementation too often.It is certainly possible to create a JavaScript shim, to be interfaced
with the WASM CRuby and access DOM, execute JavaScript. The simplest way
would be to wrap stdio and create some interface for that. This approach
may introduce some latency though.On the other hand, Opal actually compiles Ruby to JavaScript that can be
further optimized via opal-optimizer and JS minifiers. You don't need to
include the compiler for production applications if you reasonably limit
your use of `instance_eval` and friends. The resulting code, optimized
and compressed, can be as low as 100kiB.As of now, WASM CRuby is 2.88MB compressed. It includes a compiler and
takes some time to load. I imagine it would be possible to skip the
compiler and ship the Ruby code just as bytecode. If page load time is a
concern, this may be a problem.For performance, I was surprised to note that Opal-compiled code has in
general a similar, if not better performance than WASM CRuby. Also both
run faster for me in Firefox than in Chromium:TryRuby playground
TryRuby playground
TryRuby playground
TryRuby playground
TryRuby playgroundOn 2/17/22 14:32, Andy Maleh wrote:
> What are the trade-offs between Opal and WASM CRuby?
>
> Is it true that WASM CRuby can only execute pure Ruby code that does
> not have access to the DOM while Opal has complete access to the DOM
> just like JavaScript given that it is a JavaScript transpiler!?
>
> If that were the case, then WASM CRuby is not really practical for
> actual web frontend development.
>
> On Thu, Feb 17, 2022 at 5:38 AM hmdne <hmdne@airmail.cc> wrote:
>
> Thanks to the work [1] of Yuta Saito [2], the TryRuby application now
> also supports a WASM-compiled CRuby 3.2.0dev backend!
>
> You can try it yourself: TryRuby playground
>
>Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
--
Andy Maleh
LinkedIn: Andy Maleh | LinkedIn
Blog: http://andymaleh.blogspot.com
GitHub: AndyObtiva (Andy Maleh) · GitHub
This was an approach a long time ago, when Internet Explorer supported VBScript alongside JScript. Right now we still live in times when JS engines differ, some are stuck in the past and we have to somehow account for that (IE11, but also Safari on iOS if you have an outdated phone).
In the past I thought that it would be logical for web browsers to bundle jQuery as a de facto stdlib. Times have changed, jQuery brought new - incompatible - releases, now it's rarely used for new projects, becoming slowly superseded by "vanilla JS". No longer do we need Sizzle (at that time it was an internal part of jQuery), as it's now integrated into core APIs like document.querySelectorAll. Also, new methods were introduced, like Array.prototype.map, Array.prototype.forEach, Array.from, which mostly even negated the need for jQuery if you want to write some concise code.
And unlike many other languages, JS has aged extraordinarily well regarding backward compatibility. Old websites, mostly still work today. Even though I don't really enjoy writing JS, I respect many early choices in the language. It was designed as a Scheme virtual machine, only at the last time it changed a syntax to C-like, but unlike languages like PHP, there is a clear design here and it stayed consistent, mostly. And, after all, JS is surprisingly very similar to Ruby at it's core, but unlike Ruby, there are no breaking changes possible at all.
There is one big problem with JS in my opinion and it's the size and quality of it's standard library. It mostly stems from the process of creating it. And today, even if some standard library would be created, for a good couple of years we will be relying on polyfills. There is one clear benefit of a standard library - there's one, standardized way of doing things - and not hundreds of competing environments that don't necessarily mix and match well enough with one another - at the well established core. I understand the idea of the free market of open source and it's good, we are allowed to showcase hundreds of competing ideas and if one will win, it will probably be because of its superiority (or because of inclusion of a bunch of marketable words in its description), but the main question is - why should this apply to obvious things like leftPad or isOdd? This is where Ruby excels and it excels due to a good design of stdlib/corelib from its inception, but also because of its freedom to break backwards compatibility.
You probably remember Ruby 1.8 -> 1.9 migration. It wasn't perfect, but thanks to it we have good encoding support. How about JavaScript - well, it's stuck on UCS-2 strings that are interpreted by some of the functions as UTF-16 (akin to how ASCII was extended to UTF-8). And JS will be stuck with it _forever_. Sure, the engines are optimized for its internal representation, but I don't think UTF-16 is in any considered modern - and you will have to deal with its weirdness when you expect it the least. There are other classes of issues that are considered now features rather than bugs.
And about the point of "hard drives are terrabytes nowadays" I must disagree. Chromium already needs a whole day to compile and not all machines are created equal. Some contemporary mobile devices have like 32GB of flash drive and 512MB of RAM and it'd be hardly ideal to put every minor version of every programming environment. Why not include every version of a JS library while we are at it. And we would still need to polyfill those for older environments. Looking at it this way, an idea of CDNs that are well cached is a lot better, but there's an issue with centralization.
But there is another issue than storage for which there is no clear solution. In a way, it isn't warranted everywhere. If you expect your users to have powerful hardware or to wait longer than usually - and depending on a profile of your application, you can - it's not an issue. But if you expect your webpage to load and work instantly... WASM environments won't give you it - regardless of if it's already loaded to disk or not. On every page load it takes 1s to load the Ruby WASM on powerful hardware, even 5s on a less powerful hardware. And it will take 64MB of RAM from the get go. Once better hardware is thrown at the problem It will improve with time, also one site won't ever be a problem. But let's consider you have 20 tabs open, each using a barebones WASM environment and we are already talking of gigabytes.
On 2/21/22 16:35, Andy Maleh wrote:
WASM CRuby is 2.88MB
I think web browsers should just include the implementations of the
most popular languages out of the box, like Ruby, Python, Perl, Swift,
Crystal, etc...That way, using languages other than JS with WASM becomes more
practical without waiting for users.I mean, hard drives are terrabytes nowadays, so it shouldn't hurt if
browsers grow bigger a little to support languages other than JS out
of the box. Heck, maybe they can include ALL available WASM languages
out of the box, not just the common ones.
It doesn't have to happen all at once.
First, browsers can agree to add one new language other than
JavaScript, like Ruby.
A few years later, they agree to add another language like Python.
In 20 years, it becomes standard to use Ruby, Python, Perl, Java,
Crystal, Swift, C, and C++ in the browser.
Also, I'm sure cell phones would have caught up with the terrabytes
thing by then.
Keep in mind that more than 20 years ago, web developers were already
having browsers download plugins for Flash and Java Applets back when
modems were 56k and hard drives were barely gigabytes.
It can't be worse today. It's much better. Intelligent solutions have
to be used (yes to polyfills when needed) instead of just repeating
the same things over and over. I wouldn't put anything past the
smartest developers on earth to solve this problem (even if I
personally don't have all the answers right this moment).
It's important to put the demand out there first regardless of the
solution in order for anyone to attempt to solve any outstanding
issues and meet the goals of the demand. Never say never! So many
people said that in the past and then suddenly some competitor solved
the problem and took over the market (like Steve Jobs solving the
problem of phones being computers with the iPhone after so many other
manufacturers failed with unpopular heavily computerized phones that
were not user friendly and nobody was particularly fond of).
On Mon, Feb 21, 2022 at 1:09 PM hmdne <hmdne@airmail.cc> wrote:
This was an approach a long time ago, when Internet Explorer supported
VBScript alongside JScript. Right now we still live in times when JS
engines differ, some are stuck in the past and we have to somehow
account for that (IE11, but also Safari on iOS if you have an outdated
phone).In the past I thought that it would be logical for web browsers to
bundle jQuery as a de facto stdlib. Times have changed, jQuery brought
new - incompatible - releases, now it's rarely used for new projects,
becoming slowly superseded by "vanilla JS". No longer do we need Sizzle
(at that time it was an internal part of jQuery), as it's now integrated
into core APIs like document.querySelectorAll. Also, new methods were
introduced, like Array.prototype.map, Array.prototype.forEach,
Array.from, which mostly even negated the need for jQuery if you want to
write some concise code.And unlike many other languages, JS has aged extraordinarily well
regarding backward compatibility. Old websites, mostly still work today.
Even though I don't really enjoy writing JS, I respect many early
choices in the language. It was designed as a Scheme virtual machine,
only at the last time it changed a syntax to C-like, but unlike
languages like PHP, there is a clear design here and it stayed
consistent, mostly. And, after all, JS is surprisingly very similar to
Ruby at it's core, but unlike Ruby, there are no breaking changes
possible at all.There is one big problem with JS in my opinion and it's the size and
quality of it's standard library. It mostly stems from the process of
creating it. And today, even if some standard library would be created,
for a good couple of years we will be relying on polyfills. There is one
clear benefit of a standard library - there's one, standardized way of
doing things - and not hundreds of competing environments that don't
necessarily mix and match well enough with one another - at the well
established core. I understand the idea of the free market of open
source and it's good, we are allowed to showcase hundreds of competing
ideas and if one will win, it will probably be because of its
superiority (or because of inclusion of a bunch of marketable words in
its description), but the main question is - why should this apply to
obvious things like leftPad or isOdd? This is where Ruby excels and it
excels due to a good design of stdlib/corelib from its inception, but
also because of its freedom to break backwards compatibility.You probably remember Ruby 1.8 -> 1.9 migration. It wasn't perfect, but
thanks to it we have good encoding support. How about JavaScript - well,
it's stuck on UCS-2 strings that are interpreted by some of the
functions as UTF-16 (akin to how ASCII was extended to UTF-8). And JS
will be stuck with it _forever_. Sure, the engines are optimized for its
internal representation, but I don't think UTF-16 is in any considered
modern - and you will have to deal with its weirdness when you expect it
the least. There are other classes of issues that are considered now
features rather than bugs.And about the point of "hard drives are terrabytes nowadays" I must
disagree. Chromium already needs a whole day to compile and not all
machines are created equal. Some contemporary mobile devices have like
32GB of flash drive and 512MB of RAM and it'd be hardly ideal to put
every minor version of every programming environment. Why not include
every version of a JS library while we are at it. And we would still
need to polyfill those for older environments. Looking at it this way,
an idea of CDNs that are well cached is a lot better, but there's an
issue with centralization.But there is another issue than storage for which there is no clear
solution. In a way, it isn't warranted everywhere. If you expect your
users to have powerful hardware or to wait longer than usually - and
depending on a profile of your application, you can - it's not an issue.
But if you expect your webpage to load and work instantly... WASM
environments won't give you it - regardless of if it's already loaded to
disk or not. On every page load it takes 1s to load the Ruby WASM on
powerful hardware, even 5s on a less powerful hardware. And it will take
64MB of RAM from the get go. Once better hardware is thrown at the
problem It will improve with time, also one site won't ever be a
problem. But let's consider you have 20 tabs open, each using a
barebones WASM environment and we are already talking of gigabytes.On 2/21/22 16:35, Andy Maleh wrote:
>> WASM CRuby is 2.88MB
> I think web browsers should just include the implementations of the
> most popular languages out of the box, like Ruby, Python, Perl, Swift,
> Crystal, etc...
>
> That way, using languages other than JS with WASM becomes more
> practical without waiting for users.
>
> I mean, hard drives are terrabytes nowadays, so it shouldn't hurt if
> browsers grow bigger a little to support languages other than JS out
> of the box. Heck, maybe they can include ALL available WASM languages
> out of the box, not just the common ones.
>Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
--
Andy Maleh
LinkedIn: Andy Maleh | LinkedIn
Blog: http://andymaleh.blogspot.com
GitHub: AndyObtiva (Andy Maleh) · GitHub
In any case, the problem might already be solved with WASM today.
After all, downloading 2.3 MB on common Internet connections today
(often 10Mbps+) is nothing. It goes in the blink of an eye. I am not
even sure this is a problem at all. I'd have to give WASM Ruby a try
eventually, but I am waiting for WASM to add threading support, which
is on the road map:
On Mon, Feb 21, 2022 at 2:50 PM Andy Maleh <andy.am@gmail.com> wrote:
It doesn't have to happen all at once.
First, browsers can agree to add one new language other than
JavaScript, like Ruby.A few years later, they agree to add another language like Python.
In 20 years, it becomes standard to use Ruby, Python, Perl, Java,
Crystal, Swift, C, and C++ in the browser.Also, I'm sure cell phones would have caught up with the terrabytes
thing by then.Keep in mind that more than 20 years ago, web developers were already
having browsers download plugins for Flash and Java Applets back when
modems were 56k and hard drives were barely gigabytes.It can't be worse today. It's much better. Intelligent solutions have
to be used (yes to polyfills when needed) instead of just repeating
the same things over and over. I wouldn't put anything past the
smartest developers on earth to solve this problem (even if I
personally don't have all the answers right this moment).It's important to put the demand out there first regardless of the
solution in order for anyone to attempt to solve any outstanding
issues and meet the goals of the demand. Never say never! So many
people said that in the past and then suddenly some competitor solved
the problem and took over the market (like Steve Jobs solving the
problem of phones being computers with the iPhone after so many other
manufacturers failed with unpopular heavily computerized phones that
were not user friendly and nobody was particularly fond of).On Mon, Feb 21, 2022 at 1:09 PM hmdne <hmdne@airmail.cc> wrote:
>
> This was an approach a long time ago, when Internet Explorer supported
> VBScript alongside JScript. Right now we still live in times when JS
> engines differ, some are stuck in the past and we have to somehow
> account for that (IE11, but also Safari on iOS if you have an outdated
> phone).
>
> In the past I thought that it would be logical for web browsers to
> bundle jQuery as a de facto stdlib. Times have changed, jQuery brought
> new - incompatible - releases, now it's rarely used for new projects,
> becoming slowly superseded by "vanilla JS". No longer do we need Sizzle
> (at that time it was an internal part of jQuery), as it's now integrated
> into core APIs like document.querySelectorAll. Also, new methods were
> introduced, like Array.prototype.map, Array.prototype.forEach,
> Array.from, which mostly even negated the need for jQuery if you want to
> write some concise code.
>
> And unlike many other languages, JS has aged extraordinarily well
> regarding backward compatibility. Old websites, mostly still work today.
> Even though I don't really enjoy writing JS, I respect many early
> choices in the language. It was designed as a Scheme virtual machine,
> only at the last time it changed a syntax to C-like, but unlike
> languages like PHP, there is a clear design here and it stayed
> consistent, mostly. And, after all, JS is surprisingly very similar to
> Ruby at it's core, but unlike Ruby, there are no breaking changes
> possible at all.
>
> There is one big problem with JS in my opinion and it's the size and
> quality of it's standard library. It mostly stems from the process of
> creating it. And today, even if some standard library would be created,
> for a good couple of years we will be relying on polyfills. There is one
> clear benefit of a standard library - there's one, standardized way of
> doing things - and not hundreds of competing environments that don't
> necessarily mix and match well enough with one another - at the well
> established core. I understand the idea of the free market of open
> source and it's good, we are allowed to showcase hundreds of competing
> ideas and if one will win, it will probably be because of its
> superiority (or because of inclusion of a bunch of marketable words in
> its description), but the main question is - why should this apply to
> obvious things like leftPad or isOdd? This is where Ruby excels and it
> excels due to a good design of stdlib/corelib from its inception, but
> also because of its freedom to break backwards compatibility.
>
> You probably remember Ruby 1.8 -> 1.9 migration. It wasn't perfect, but
> thanks to it we have good encoding support. How about JavaScript - well,
> it's stuck on UCS-2 strings that are interpreted by some of the
> functions as UTF-16 (akin to how ASCII was extended to UTF-8). And JS
> will be stuck with it _forever_. Sure, the engines are optimized for its
> internal representation, but I don't think UTF-16 is in any considered
> modern - and you will have to deal with its weirdness when you expect it
> the least. There are other classes of issues that are considered now
> features rather than bugs.
>
> And about the point of "hard drives are terrabytes nowadays" I must
> disagree. Chromium already needs a whole day to compile and not all
> machines are created equal. Some contemporary mobile devices have like
> 32GB of flash drive and 512MB of RAM and it'd be hardly ideal to put
> every minor version of every programming environment. Why not include
> every version of a JS library while we are at it. And we would still
> need to polyfill those for older environments. Looking at it this way,
> an idea of CDNs that are well cached is a lot better, but there's an
> issue with centralization.
>
> But there is another issue than storage for which there is no clear
> solution. In a way, it isn't warranted everywhere. If you expect your
> users to have powerful hardware or to wait longer than usually - and
> depending on a profile of your application, you can - it's not an issue.
> But if you expect your webpage to load and work instantly... WASM
> environments won't give you it - regardless of if it's already loaded to
> disk or not. On every page load it takes 1s to load the Ruby WASM on
> powerful hardware, even 5s on a less powerful hardware. And it will take
> 64MB of RAM from the get go. Once better hardware is thrown at the
> problem It will improve with time, also one site won't ever be a
> problem. But let's consider you have 20 tabs open, each using a
> barebones WASM environment and we are already talking of gigabytes.
>
> On 2/21/22 16:35, Andy Maleh wrote:
> >> WASM CRuby is 2.88MB
> > I think web browsers should just include the implementations of the
> > most popular languages out of the box, like Ruby, Python, Perl, Swift,
> > Crystal, etc...
> >
> > That way, using languages other than JS with WASM becomes more
> > practical without waiting for users.
> >
> > I mean, hard drives are terrabytes nowadays, so it shouldn't hurt if
> > browsers grow bigger a little to support languages other than JS out
> > of the box. Heck, maybe they can include ALL available WASM languages
> > out of the box, not just the common ones.
> >
>
> Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>--
Andy MalehLinkedIn: Andy Maleh | LinkedIn
Blog: http://andymaleh.blogspot.com
GitHub: AndyObtiva (Andy Maleh) · GitHub
--
Andy Maleh
LinkedIn: Andy Maleh | LinkedIn
Blog: http://andymaleh.blogspot.com
GitHub: AndyObtiva (Andy Maleh) · GitHub
In any case, the problem might already be solved with WASM today.
After all, downloading 2.3 MB on common Internet connections today
(often 10Mbps+) is nothing. It goes in the blink of an eye. I am not
even sure this is a problem at all. I'd have to give WASM Ruby a try
eventually, but I am waiting for WASM to add threading support, which
is on the road map:
https://github.com/WebAssembly/threads/blob/main/proposals/threads/Overview.md
If you are planning to create a game or a complex web application, then go for it. But if you plan to create a website, 5s load time (even discarding the network problem) on mobile devices may be too much.
It doesn't have to happen all at once.
First, browsers can agree to add one new language other than
JavaScript, like Ruby.
Question is - which version of Ruby and how much will it impact Ruby's viability to break compatibility?
Will it be MRI, MRuby or clean slate implementations (not fully compatible with each other) following the ISO standard?
As of today, having to deal with browser differences takes a lot of developer time. Supplying your own stable environment is in this case a lot better solution. Or people may choose to deal with transpilers.
A few years later, they agree to add another language like Python.
In 20 years, it becomes standard to use Ruby, Python, Perl, Java,
Crystal, Swift, C, and C++ in the browser.
For the compiled environments it makes little sense and WASM is absolutely a solution for those. Not having to ship the entire compiler is a big win. Same with not having to compile sources every time user runs a page.
Btw. browsers today support additional language for a GPU, GLSL ES. Future implementations, like WebGPU, will go with WGSL. Desktop applications slowly move to binary compiled formats like SPIR-V. I assume we will see a similar trend here, possibly something WASM related.
Also, I'm sure cell phones would have caught up with the terrabytes
thing by then.Keep in mind that more than 20 years ago, web developers were already
having browsers download plugins for Flash and Java Applets back when
modems were 56k and hard drives were barely gigabytes.
Those were times of Internet Explorer monopoly and web technology stagnation. JavaScript was almost unusable back then. I never wrote it's worse. Though, I sent some stranger on the internet recently a demo of OnlyOffice (a great WASM-compiled .NET application). He had to wait half a minute for it to load and didn't realize it's loading even. A situation strongly reminiscent of the Java times. As I wrote, it's in my opinion totally fine for a complex web application and I understand that Moore's law is not dead, but I can't imagine something similar to be needed for a regular website (oh well, with the number of the advertisement/tracking crap and cookie popups it's a reality. I guess the existence of those makes my entire argument moot... but I hope the readers will share the sentiment with me, that it's rather a pathology and not an example to follow)
It can't be worse today. It's much better. Intelligent solutions have
to be used (yes to polyfills when needed) instead of just repeating
the same things over and over. I wouldn't put anything past the
smartest developers on earth to solve this problem (even if I
personally don't have all the answers right this moment).
It's important to put the demand out there first regardless of the
solution in order for anyone to attempt to solve any outstanding
issues and meet the goals of the demand. Never say never! So many
people said that in the past and then suddenly some competitor solved
the problem and took over the market (like Steve Jobs solving the
problem of phones being computers with the iPhone after so many other
manufacturers failed with unpopular heavily computerized phones that
were not user friendly and nobody was particularly fond of).
While I deeply respect Jobs' decision to kill Flash, iPhones are hardly computers. Yes, they ship a full Unix operating system, but I don't think you even notice it much, unless you root your phone. For sure it was light years away from what used to be with Symbian, but that's because of the tools Apple provided for developers. What's more, I rather see a reverse trend - computers becoming mobile phones (eg. in terms of being more locked down, having poorer interfaces), maybe even lesser due to desktop application unavailability. But one of the most user unfriendly decisions iPhone creators made is inability to install alternative web browsers - it probably is a good business decision, but one that cements the fact, that iPhone is most certainly not a computer. But if this situation doesn't change, we may live to see people decide to embed WASM-compiled JS interpreters... or even the whole browsers (remember Google Chrome Frame?)
On 2/21/22 20:54, Andy Maleh wrote:
On Mon, Feb 21, 2022 at 2:50 PM Andy Maleh <andy.am@gmail.com> wrote:
Thanks for sharing your opinion, but it sounds like you're very
negative and jaded.
Think positive if you want anything good to happen. After all, when
things happen, that is a positive effect (addition). When things are
destroyed, that is a negative effect (subtraction). Thinking negative
is good I suppose every once in a while to remove the dirty weeds, but
it won't take us forward unless we eventually switch back to thinking
positively again.
I don't care about the details mentioned in this discussion at all.
From a bird eye's view, I only care about the positive trends of the
future regardless of how we get to them. And, being in a Ruby mailing
list, obviously my opinion is it would be cool if we have a better web
frontend development experience than JavaScript (or any of its es6+
incarnations, which are all just lipstick on a pig) in the future.
Again, I don't care how we get there. I could be wrong about
everything I said, but I trust that smarter devs than me can figure it
out eventually.
On Mon, Feb 21, 2022 at 4:06 PM hmdne <hmdne@airmail.cc> wrote:
On 2/21/22 20:54, Andy Maleh wrote:
> In any case, the problem might already be solved with WASM today.
> After all, downloading 2.3 MB on common Internet connections today
> (often 10Mbps+) is nothing. It goes in the blink of an eye. I am not
> even sure this is a problem at all. I'd have to give WASM Ruby a try
> eventually, but I am waiting for WASM to add threading support, which
> is on the road map:
> https://github.com/WebAssembly/threads/blob/main/proposals/threads/Overview.md
If you are planning to create a game or a complex web application, then
go for it. But if you plan to create a website, 5s load time (even
discarding the network problem) on mobile devices may be too much.
> On Mon, Feb 21, 2022 at 2:50 PM Andy Maleh <andy.am@gmail.com> wrote:
>> It doesn't have to happen all at once.
>>
>> First, browsers can agree to add one new language other than
>> JavaScript, like Ruby.Question is - which version of Ruby and how much will it impact Ruby's
viability to break compatibility?Will it be MRI, MRuby or clean slate implementations (not fully
compatible with each other) following the ISO standard?As of today, having to deal with browser differences takes a lot of
developer time. Supplying your own stable environment is in this case a
lot better solution. Or people may choose to deal with transpilers.>> A few years later, they agree to add another language like Python.
>>
>> In 20 years, it becomes standard to use Ruby, Python, Perl, Java,
>> Crystal, Swift, C, and C++ in the browser.For the compiled environments it makes little sense and WASM is
absolutely a solution for those. Not having to ship the entire compiler
is a big win. Same with not having to compile sources every time user
runs a page.Btw. browsers today support additional language for a GPU, GLSL ES.
Future implementations, like WebGPU, will go with WGSL. Desktop
applications slowly move to binary compiled formats like SPIR-V. I
assume we will see a similar trend here, possibly something WASM related.>> Also, I'm sure cell phones would have caught up with the terrabytes
>> thing by then.
>>
>> Keep in mind that more than 20 years ago, web developers were already
>> having browsers download plugins for Flash and Java Applets back when
>> modems were 56k and hard drives were barely gigabytes.
Those were times of Internet Explorer monopoly and web technology
stagnation. JavaScript was almost unusable back then. I never wrote it's
worse. Though, I sent some stranger on the internet recently a demo of
OnlyOffice (a great WASM-compiled .NET application). He had to wait half
a minute for it to load and didn't realize it's loading even. A
situation strongly reminiscent of the Java times. As I wrote, it's in my
opinion totally fine for a complex web application and I understand that
Moore's law is not dead, but I can't imagine something similar to be
needed for a regular website (oh well, with the number of the
advertisement/tracking crap and cookie popups it's a reality. I guess
the existence of those makes my entire argument moot... but I hope the
readers will share the sentiment with me, that it's rather a pathology
and not an example to follow)
>> It can't be worse today. It's much better. Intelligent solutions have
>> to be used (yes to polyfills when needed) instead of just repeating
>> the same things over and over. I wouldn't put anything past the
>> smartest developers on earth to solve this problem (even if I
>> personally don't have all the answers right this moment).
>> It's important to put the demand out there first regardless of the
>> solution in order for anyone to attempt to solve any outstanding
>> issues and meet the goals of the demand. Never say never! So many
>> people said that in the past and then suddenly some competitor solved
>> the problem and took over the market (like Steve Jobs solving the
>> problem of phones being computers with the iPhone after so many other
>> manufacturers failed with unpopular heavily computerized phones that
>> were not user friendly and nobody was particularly fond of).While I deeply respect Jobs' decision to kill Flash, iPhones are hardly
computers. Yes, they ship a full Unix operating system, but I don't
think you even notice it much, unless you root your phone. For sure it
was light years away from what used to be with Symbian, but that's
because of the tools Apple provided for developers. What's more, I
rather see a reverse trend - computers becoming mobile phones (eg. in
terms of being more locked down, having poorer interfaces), maybe even
lesser due to desktop application unavailability. But one of the most
user unfriendly decisions iPhone creators made is inability to install
alternative web browsers - it probably is a good business decision, but
one that cements the fact, that iPhone is most certainly not a computer.
But if this situation doesn't change, we may live to see people decide
to embed WASM-compiled JS interpreters... or even the whole browsers
(remember Google Chrome Frame?)Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
--
Andy Maleh
LinkedIn: Andy Maleh | LinkedIn
Blog: http://andymaleh.blogspot.com
GitHub: AndyObtiva (Andy Maleh) · GitHub
BTW, remembering that you're on the Opal team, I do think Opal is a
great practical solution for today in web frontend development.
I am still holding my breath over Ruby WASM being practical or not.
On Mon, Feb 21, 2022 at 4:19 PM Andy Maleh <andy.am@gmail.com> wrote:
Thanks for sharing your opinion, but it sounds like you're very
negative and jaded.Think positive if you want anything good to happen. After all, when
things happen, that is a positive effect (addition). When things are
destroyed, that is a negative effect (subtraction). Thinking negative
is good I suppose every once in a while to remove the dirty weeds, but
it won't take us forward unless we eventually switch back to thinking
positively again.I don't care about the details mentioned in this discussion at all.
From a bird eye's view, I only care about the positive trends of the
future regardless of how we get to them. And, being in a Ruby mailing
list, obviously my opinion is it would be cool if we have a better web
frontend development experience than JavaScript (or any of its es6+
incarnations, which are all just lipstick on a pig) in the future.
Again, I don't care how we get there. I could be wrong about
everything I said, but I trust that smarter devs than me can figure it
out eventually.On Mon, Feb 21, 2022 at 4:06 PM hmdne <hmdne@airmail.cc> wrote:
>
> On 2/21/22 20:54, Andy Maleh wrote:
> > In any case, the problem might already be solved with WASM today.
> > After all, downloading 2.3 MB on common Internet connections today
> > (often 10Mbps+) is nothing. It goes in the blink of an eye. I am not
> > even sure this is a problem at all. I'd have to give WASM Ruby a try
> > eventually, but I am waiting for WASM to add threading support, which
> > is on the road map:
> > https://github.com/WebAssembly/threads/blob/main/proposals/threads/Overview.md
> If you are planning to create a game or a complex web application, then
> go for it. But if you plan to create a website, 5s load time (even
> discarding the network problem) on mobile devices may be too much.
> > On Mon, Feb 21, 2022 at 2:50 PM Andy Maleh <andy.am@gmail.com> wrote:
> >> It doesn't have to happen all at once.
> >>
> >> First, browsers can agree to add one new language other than
> >> JavaScript, like Ruby.
>
> Question is - which version of Ruby and how much will it impact Ruby's
> viability to break compatibility?
>
> Will it be MRI, MRuby or clean slate implementations (not fully
> compatible with each other) following the ISO standard?
>
> As of today, having to deal with browser differences takes a lot of
> developer time. Supplying your own stable environment is in this case a
> lot better solution. Or people may choose to deal with transpilers.
>
> >> A few years later, they agree to add another language like Python.
> >>
> >> In 20 years, it becomes standard to use Ruby, Python, Perl, Java,
> >> Crystal, Swift, C, and C++ in the browser.
>
> For the compiled environments it makes little sense and WASM is
> absolutely a solution for those. Not having to ship the entire compiler
> is a big win. Same with not having to compile sources every time user
> runs a page.
>
> Btw. browsers today support additional language for a GPU, GLSL ES.
> Future implementations, like WebGPU, will go with WGSL. Desktop
> applications slowly move to binary compiled formats like SPIR-V. I
> assume we will see a similar trend here, possibly something WASM related.
>
> >> Also, I'm sure cell phones would have caught up with the terrabytes
> >> thing by then.
> >>
> >> Keep in mind that more than 20 years ago, web developers were already
> >> having browsers download plugins for Flash and Java Applets back when
> >> modems were 56k and hard drives were barely gigabytes.
> Those were times of Internet Explorer monopoly and web technology
> stagnation. JavaScript was almost unusable back then. I never wrote it's
> worse. Though, I sent some stranger on the internet recently a demo of
> OnlyOffice (a great WASM-compiled .NET application). He had to wait half
> a minute for it to load and didn't realize it's loading even. A
> situation strongly reminiscent of the Java times. As I wrote, it's in my
> opinion totally fine for a complex web application and I understand that
> Moore's law is not dead, but I can't imagine something similar to be
> needed for a regular website (oh well, with the number of the
> advertisement/tracking crap and cookie popups it's a reality. I guess
> the existence of those makes my entire argument moot... but I hope the
> readers will share the sentiment with me, that it's rather a pathology
> and not an example to follow)
> >> It can't be worse today. It's much better. Intelligent solutions have
> >> to be used (yes to polyfills when needed) instead of just repeating
> >> the same things over and over. I wouldn't put anything past the
> >> smartest developers on earth to solve this problem (even if I
> >> personally don't have all the answers right this moment).
> >> It's important to put the demand out there first regardless of the
> >> solution in order for anyone to attempt to solve any outstanding
> >> issues and meet the goals of the demand. Never say never! So many
> >> people said that in the past and then suddenly some competitor solved
> >> the problem and took over the market (like Steve Jobs solving the
> >> problem of phones being computers with the iPhone after so many other
> >> manufacturers failed with unpopular heavily computerized phones that
> >> were not user friendly and nobody was particularly fond of).
>
> While I deeply respect Jobs' decision to kill Flash, iPhones are hardly
> computers. Yes, they ship a full Unix operating system, but I don't
> think you even notice it much, unless you root your phone. For sure it
> was light years away from what used to be with Symbian, but that's
> because of the tools Apple provided for developers. What's more, I
> rather see a reverse trend - computers becoming mobile phones (eg. in
> terms of being more locked down, having poorer interfaces), maybe even
> lesser due to desktop application unavailability. But one of the most
> user unfriendly decisions iPhone creators made is inability to install
> alternative web browsers - it probably is a good business decision, but
> one that cements the fact, that iPhone is most certainly not a computer.
> But if this situation doesn't change, we may live to see people decide
> to embed WASM-compiled JS interpreters... or even the whole browsers
> (remember Google Chrome Frame?)
>
>
> Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>--
Andy MalehLinkedIn: Andy Maleh | LinkedIn
Blog: http://andymaleh.blogspot.com
GitHub: AndyObtiva (Andy Maleh) · GitHub
--
Andy Maleh
LinkedIn: Andy Maleh | LinkedIn
Blog: http://andymaleh.blogspot.com
GitHub: AndyObtiva (Andy Maleh) · GitHub
BTW, remembering that you're on the Opal team, I do think Opal is a
great practical solution for today in web frontend development.I am still holding my breath over Ruby WASM being practical or not.
I found this part, which you may find interesting:
Thanks for sharing your opinion, but it sounds like you're very
negative and jaded.
I believe that's not really what happened. If you asked me if Opal would be fit into a browser engine for Ruby, I would answer the same. I spent a lot of time optimizing Opal for load speed and performance and I still believe there's some corner to be cut. And if you asked me a few years ago about Opal, I would answer probably the same, but it doesn't apply anymore, due to my work on it multiplied by Moore's Law and general acceptance for larger bundles. I have seen tangible results on the products I create.
And same I wrote about WASM Ruby - if it is to be viable to be used on regular websites, it would need to allow source to be shipped as pre-compiled bytecode and a possibility to strip irrelevant parts of runtime, possibly a compiler. I also noted that this solution has some unique values that Opal will never match and vice-versa. We are just moving to a space that will be 2 alternatives implementations for a similar thing, just like JRuby is an alternative to MRI on desktop/server.
My main point is that adding Ruby as another language to a web browser environment is going to make Ruby move in the same direction JS is currently moving, which I don't think will be fruitful for Ruby, and even further fragment and complicate the mess that is webdevelopment in general. For this to actually work, JS would need to become marked as a legacy system and no other environment to be introduced. Also I noted a sentiment in your words, that this should happen first to drive demand which is unfortunately a bad and unrealistic idea - the only viable way is reverse and this must be happen globally.
On 2/21/22 22:27, Andy Maleh wrote:
On Mon, Feb 21, 2022 at 4:19 PM Andy Maleh <andy.am@gmail.com> wrote:
Think positive if you want anything good to happen. After all, when
things happen, that is a positive effect (addition). When things are
destroyed, that is a negative effect (subtraction). Thinking negative
is good I suppose every once in a while to remove the dirty weeds, but
it won't take us forward unless we eventually switch back to thinking
positively again.I don't care about the details mentioned in this discussion at all.
From a bird eye's view, I only care about the positive trends of the
future regardless of how we get to them. And, being in a Ruby mailing
list, obviously my opinion is it would be cool if we have a better web
frontend development experience than JavaScript (or any of its es6+
incarnations, which are all just lipstick on a pig) in the future.
Again, I don't care how we get there. I could be wrong about
everything I said, but I trust that smarter devs than me can figure it
out eventually.