You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The impetus for making Porous is to build applications that can be broken down into smaller components that are easier to reason about, similar to many frontend frameworks, but to avoid the added complexity of having a whole slew of toolchains to make an application that runs partly on the server and partly on the client. Hence, components need to build on the server and run in the browser with the same code. A goal of the project is to try and keep the way these components are defined as simple and intuitive as possible.
This is one of the core features needed to make Porous feasible.
While the ideal long-term solution is probably to write a pure ruby application, compile it to WebAssembly and run it in the browser, this will require that a layer of software be written to manipulate the DOM as needed. The simpler approach is to use the existing libraries that wrap the browser's JavaScript API so that we can write Ruby that is close to a typical frontend framework's JavaScript.
To start with I used the component architecture from Inesita, which already renders in the browser, combined with the VirtualDom Ruby (Opal) wrapper which adequately describes the HTML structure so that strings can be rendered on the server. This gives some handling of client-side interactions by wrapping browser events and APIs, and providing a way to manage some component state.
I don't know if this will suffice to build sufficiently complex application behavior, but my plan is to refactor this as I go and perhaps replace the rendering code to depend on Paggio, since it is already a dependency in Opal::Browser and that will be needed for many other features it provides.
The text was updated successfully, but these errors were encountered:
The impetus for making Porous is to build applications that can be broken down into smaller components that are easier to reason about, similar to many frontend frameworks, but to avoid the added complexity of having a whole slew of toolchains to make an application that runs partly on the server and partly on the client. Hence, components need to build on the server and run in the browser with the same code. A goal of the project is to try and keep the way these components are defined as simple and intuitive as possible.
This is one of the core features needed to make Porous feasible.
While the ideal long-term solution is probably to write a pure ruby application, compile it to WebAssembly and run it in the browser, this will require that a layer of software be written to manipulate the DOM as needed. The simpler approach is to use the existing libraries that wrap the browser's JavaScript API so that we can write Ruby that is close to a typical frontend framework's JavaScript.
To start with I used the component architecture from Inesita, which already renders in the browser, combined with the VirtualDom Ruby (Opal) wrapper which adequately describes the HTML structure so that strings can be rendered on the server. This gives some handling of client-side interactions by wrapping browser events and APIs, and providing a way to manage some component state.
I don't know if this will suffice to build sufficiently complex application behavior, but my plan is to refactor this as I go and perhaps replace the rendering code to depend on Paggio, since it is already a dependency in Opal::Browser and that will be needed for many other features it provides.
The text was updated successfully, but these errors were encountered: