Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 11 2019 09:03

    janbiedermann on master

    update config for example and t… (compare)

  • May 11 2019 08:43

    janbiedermann on master

    further readme split up (compare)

  • May 11 2019 08:24

    janbiedermann on master

    fix travis config (compare)

  • May 11 2019 08:21

    janbiedermann on master

    fix links (compare)

  • May 11 2019 08:19

    janbiedermann on master

    exclude specs in fixtures clean up a bit corrections in readme and 8 more (compare)

  • May 11 2019 06:09

    janbiedermann on master

    update branch for compilation t… add es6_modules_string branch t… (compare)

  • May 10 2019 20:11

    janbiedermann on master

    let var be let (compare)

  • May 10 2019 18:42

    janbiedermann on master

    add test to execute ruby with c… (compare)

  • May 10 2019 17:18

    janbiedermann on master

    update doc for branches and PRs (compare)

  • May 10 2019 13:00

    janbiedermann on master

    keep test_apps folder for tests (compare)

  • May 10 2019 12:21

    janbiedermann on master

    simplify a bit spec add owl to dependencies test for 'public/assets' add te… and 2 more (compare)

  • May 09 2019 21:53
    francescoagati closed #2
  • May 09 2019 21:53
    francescoagati commented #2
  • May 09 2019 21:47
    janbiedermann commented #2
  • May 09 2019 16:02
    francescoagati opened #2
  • May 09 2019 16:01
    francescoagati starred isomorfeus/opal-webpack-loader
  • May 04 2019 02:19

    janbiedermann on master

    document file tree more accurat… (compare)

  • May 03 2019 16:30
  • May 03 2019 15:42

    janbiedermann on 0.7.3

    (compare)

  • May 03 2019 15:41

    janbiedermann on 0.7.3

    (compare)

Isomorfeus Robot
@isomorfeusbot
[slack] <Forrest Chang> I think “working out of the box” and lightweight could help for such adoption
[slack] <Forrest Chang> who knows
[slack] <janbiedermann> sure, i agree
[slack] <Forrest Chang> though I imagine duplicating the phoenix live view demo in all ruby might be a good thing, though I hear a lot of stuff around elixir/phoenix like I used to, so maybe not
[slack] <janbiedermann> what do you hear?
[slack] <Forrest Chang> I should still get the elixir newsletter, but I’d say just in general, I’d be getting things in my feeds about great elixir/phoenix were and lots of excitement over there
Isomorfeus Robot
@isomorfeusbot
[slack] <Forrest Chang> Now I don’t hear much of it. It would seem the Rubyists that were going to go to elixir have, and while they seem quite dedicated, no real growth of that commuity
[slack] <Forrest Chang> One should expect the phoenix live demo to get it a lot more attention
[slack] <janbiedermann> yeah, same destiny. So its not about better tech, its about where the money goes and how people can earn money,
[slack] <Forrest Chang> Dan Abramov did his initial react hot loader video and the tech world went nuts. I showed the same kind of functionality with opal hot loader and I got like 40 views - I would think the Rails people would be all over it
[slack] <Forrest Chang> Part of my failed evangelism was that I couldn’t convince something that should be a no brainer to people doing web work with Ruby backends. Which certainly isn’t just me, but mind boggling. I met folks in person, had long discussions and they just didn’t get it
Isomorfeus Robot
@isomorfeusbot
[slack] <Forrest Chang> I suppose Ryan Stout got the most attention because voltrb resembled meteor.js, though I never hear anything about meteor these days
[slack] <janbiedermann> right. It only matters what google, facebook, apple, microsoft, amazon do. Even it is the greatest ever possible overkill BS.
[slack] <janbiedermann> But well, maybe thats not the point.
[slack] <janbiedermann> At least for me, its about my life and time i spend, so at least i try to spend it well, from my point of http://view.no matter what the big five do. Not everybody may have that luxury.
[slack] <janbiedermann> Funny, i use a ', ' and slack still builds a link <- thats big five technology
Isomorfeus Robot
@isomorfeusbot
[slack] <janbiedermann> I have an idea. The idea is, to create a powerful sytem, ruby only, that does not need to build assets at all.
It ships with a default set of assets. Thats it.
Of course, you could expand it by adding javascipt libs, wahtever, but the point is, to make creating apps so easy, that this is not necessary (well, sure, recreate everything all the time may not be the way to go either, but a module system for that will have to wait.)
Not sure if what i envision is feasable. Ill try the next days.
Isomorfeus Robot
@isomorfeusbot
[slack] <janbiedermann> well, the trick is, to ignore the DOM, basically, as much as possible.
Isomorfeus Robot
@isomorfeusbot
[slack] <janbiedermann> One major problem that limits ruby power with existing :isomorfeus: of course, is :react: , becasue it forces us to do some things, which are not :ruby: ish at all.
At the same time, we have problems from js engine and its asynchronousillyty. which is not :ruby: ish either. Both are mostly a problem when loading code.
So its wither ship all code, or jump some loops to lazy load. Because, beacause of :react: , code and html/render result are 2 different things.
[slack] <janbiedermann> Or even 3 different things.
  1. ruby code
  2. compiled to js
  3. html rendered by that code
[slack] <janbiedermann> if one of those is needed, all 3 are needed.

[slack] <janbiedermann> So lets make that one and ship components along with code and data, like this:

<script>
<data>

<html>
So above is one component.

[slack] <janbiedermann> Of course, no :react: , only ruby, well mostly, of course compiled to javascript
[slack] <janbiedermann> As now, code is tied to html, lazy loading is not a issue, as we ship it along with html when its needed.
So we do not just lazy load code, but also html, we lazy load complete components (with sub components)
Isomorfeus Robot
@isomorfeusbot
[slack] <janbiedermann> We lazy load a componen tree over websockets on demand.
In theory it can be executed and everything is happy.

[slack] <janbiedermann> Ok, with react, whet we do is:

  1. render (code must be available)
    (we could lazy load with :react: to at this stage, in fact we did in several cases, but its very complicated)

So without react we do:

  1. lazy load above component tree bundle readily from ruby based SSR
  2. execute it
[slack] <janbiedermann> We do so on route/page/path changes.
Isomorfeus Robot
@isomorfeusbot
[slack] <janbiedermann> So we ship with the initial page a static set of assets + component tree (including the component code and data embedded)
On route change, we ship the SSR HTML with the embedded code and data.
[slack] <janbiedermann> We may ship code several times, but that does not matter so much, i think, we can prevent execution conditionally.
[slack] <janbiedermann> Just some more bytes over the wire (for now, until this is optimized)
Isomorfeus Robot
@isomorfeusbot
[slack] <janbiedermann> With empty caches these things need to be done on the server for a component:
  1. compile the ruby code to js with opal
  2. build the script part with conditional execution
  3. execute the ruby code for SSR
  4. get state/data
  5. insert data
  6. attach SSR HTML result
Isomorfeus Robot
@isomorfeusbot
[slack] <janbiedermann> Another Issue with react is , that it has to keep the "mounted tree" consistent with a "virtual tree".
Lets abolish that too (of course, its abolished by not using :react: , and at the same time not using a virtual tree)
[slack] <janbiedermann> This provides us with freedom to modify the tree any time, using the provided ruby ways (as the JS ways dont make sense in our :ruby: system)
Isomorfeus Robot
@isomorfeusbot
[slack] <janbiedermann> Yes, right, i intend to make it pure :ruby: , you can use JS packages, but only client side by wrapping them in "if RUBY_ENGINE ...", but not in SSR.
[slack] <janbiedermann> SSR is pure ruby
[slack] <janbiedermann> Also the render core and state handling client side is implemented in :ruby:
[slack] <janbiedermann> (well, in progress)
Isomorfeus Robot
@isomorfeusbot
[slack] <Forrest Chang> @janbiedermann if you’re dropping react maybe borrow from inesita - I’ve yet to check it out besides glancing docs, but I like the DSL as it’s similar to the react.rb one

[slack] <Forrest Chang> ```class Counter
include Inesita::Component

def inc
store.increase
render!
end

def dec
store.decrease
render!
end

def render
h4 do
text props[:header]
end
div.input_group do
span.input_group_btn do
button.btn.btn_default, onclick: method(:dec) do
text '-'
end
end
input.form_control type: "text", value: store.counter, disabled: true
span.input_group_btn do
button.btn.btn_default, onclick: -> { inc } do
text '+'
end
end
end
end
end```

[slack] <Forrest Chang> It doesn’t look like it does server rendering, but shuld be able to
Isomorfeus Robot
@isomorfeusbot
[slack] <Forrest Chang> Though lissio lets you have css in ruby, maybe best features of both?
Isomorfeus Robot
@isomorfeusbot
[slack] <Forrest Chang> @janbiedermann food for thought, inspired by Live View, I have to digest it a bit, but I do like how the js load is 54K, thinking opal/opalscript type of code on the JS could go a ways for an all ruby experience. I do feel that post watching the livewire demo, that I want to be able to add the new code via the app instead of the command line https://docs.stimulusreflex.com/
Isomorfeus Robot
@isomorfeusbot
[slack] <janbiedermann> yeah, that sounds like phoenix and goes into my direction
[slack] <janbiedermann> However, i have a new problem
[slack] <janbiedermann> I need a Back-Office Web/DB Framework that works on 😱 WINDOWS 😱
[slack] <janbiedermann> (i dont like the new emoji style here, who came up with this?)
Isomorfeus Robot
@isomorfeusbot
[slack] <janbiedermann> Unfortunately :isomorfeus: depends on too many unixish things, even porting to jruby would be some effort.
[slack] <janbiedermann> Not sure what to do. Ruby on windows is not really a kicker.
Isomorfeus Robot
@isomorfeusbot
[slack] <Forrest Chang> jruby was the way I deployed stuff to windows, I tried to use IIS server and what not, terrible and the IT support gave us very limited access, ended up deploying via a war file which the IT folks would run java against (very limited access on that server). What aspects of isomorfeus backend depend on unix things?
Isomorfeus Robot
@isomorfeusbot
[slack] <janbiedermann> Well, iodine for sure,so :isomorfeus: websocket and pubsub support depend on iodine. Then some node things. Then there are some modules which work by poviding a native extension. Thats it. I dont think, :isomorfeus: directly depends on those, except for iodine, but some module. that depends on a module, that dpends on a module ...