Live data from Hacker News

Matestack – Reactive UIs in pure Ruby

matestack.io

111–120 of 120 posts

Re: Matestack – Reactive UIs in pure Ruby

#111
post #76

Earlier quoted context omitted.

Is it? It has an api mode and I’ve used it extensively for that at multiple workplaces and projects.

Yes but at that point you are getting all the disadvantages of Rails, without the strong points (fast prototyping and everything related to rendering HTML pages, file uploading etc.). Presuming you wanted to stay in Ruby for the API and wanted to stay in a project similar to Rails (so, preserving ActiveRecord), Roda + ActiveRecord gets you there with already much higher performance. If you think about it, a JSON API…

> Yes but at that point you are getting all the disadvantages of Rails, without the strong points (fast prototyping and everything related to rendering HTML pages, file uploading etc.).

Your perception of the strong points of rails are very different from mine. The strong points include rapid data and logic modeling, json serialization (jbuilder), robust libraries for user management (devise) and many other things, built-in security, routing logic, easy testing, and meta programming. You still get rapid prototyping in api mode, with a rails generate scaffold quickly capable of creating tables and a json rest api for that resource in a single line with no additional work necessary (assuming you had no business logic, which is generally easier to write in ruby as well).

Re: Matestack – Reactive UIs in pure Ruby

#112
post #106

Earlier quoted context omitted.

Neither Elixir Liveview nor StimulusReflex are really viable longterm, especially for mobile web. The idea of chattily streaming UI changes over the network doesn't work out for mobile web, where networks are frequently unreliable if not totally inaccessible.

If the Network is unreliable how is that any different to failing to updating / reloading a page? Or you are referring to Web Apps that work offline?

Yes I'm referring to mobile web apps that either work offline, or don't severely impact their UX in the presence of a slow or unreliable network.

Many native mobile apps have these properties, and if mobile web apps want to compete they will have to as well.

In practice, that means generally minimizing network traffic, being smart about caching data, and providing soft failure modes.

Neither Liveview nor StimulusReflex are well suited to this problem space.

Re: Matestack – Reactive UIs in pure Ruby

#113
post #103

Earlier quoted context omitted.

PHP isn't faster for arbitrary mathematical workloads (though the JIT in PHP 8 will help with those). Instead PHP is faster for the things websites normally do, like string manipulation.

I see this is the hill you want to die on... "Instead PHP is faster for the things websites normally do, like string manipulation." No, this is not right for a couple of reasons. NodeJS is potentially slower in certain CPU-bound tasks due to the single-threaded nature of JavaScript. On the other hand, thanks to its event loop and concurrency model, NodeJS is much faster than many languages/runtimes in I/O (reading/wr…

> If you're an engineer or web developer I really suggest that you brush up on these things

I’m doing ok, thanks, and a little humility would go a long way :)

I work at a company where we run PHP as both a shared-memory server and also in a more traditional per-request model, both serving millions of requests a day. Separately I’ve created (and maintain) a 200-thousand-line multi-threaded PHP application with over 4 million downloads. I’m reasonably aware of PHP’s performance characteristics.

I’m less up-to-date on Node, admittedly, but it also intuitively makes sense that the V8 engine will be optimised more for in-browser use than serverside use.

Re: Matestack – Reactive UIs in pure Ruby

#114
post #83
post #45

Even if this was a good idea, the push on commercialisation puts me off. And as other commenters have said, the DSL feels like it would end up being a hinderance. Stimulus (and perhaps StimulusReflex) feel like the safer bets for the dynamic rails future.

As someone who's been involved with the project from day one, I'm genuinely interested in what other suggestion you have for making a living while wrinting OS software. There's a lot of discussions around sustainable open source, and I wonder what's so wrong about asking people that find the project supportable enough to become a GH sponsor (I myself am one, since leaving the company around Matestack as a co-founder…

> there's a lot of "I think the DSL ends up a hinderance" in this [thread] from people that (perhaps) haven't tried it and judge from the looks

As unfair as this seems to you, I think it's also unfair to dismiss them as not having tried it, since I've personally tried many (I can remember encountering them in 2008 on my first ruby project and many times in the interim) and never had a good experience. It feels like a novelty that doesn't really add anything except a disconnect between what I have to write and what I mean, when "what I mean" is actually really simple and not hard to write. Your mileage may vary, but the "DSL hate" is actually rooted in experience for many people.

But you're right, I definitely haven't tried it, and I don't intend to, so I could be missing out. I just really don't think so. More power to everyone who likes this sort of thing. :)

Re: Matestack – Reactive UIs in pure Ruby

#115

Earlier quoted context omitted.

Yes but at that point you are getting all the disadvantages of Rails, without the strong points (fast prototyping and everything related to rendering HTML pages, file uploading etc.). Presuming you wanted to stay in Ruby for the API and wanted to stay in a project similar to Rails (so, preserving ActiveRecord), Roda + ActiveRecord gets you there with already much higher performance. If you think about it, a JSON API…

> Yes but at that point you are getting all the disadvantages of Rails, without the strong points (fast prototyping and everything related to rendering HTML pages, file uploading etc.). Your perception of the strong points of rails are very different from mine. The strong points include rapid data and logic modeling, json serialization (jbuilder), robust libraries for user management (devise) and many other things, b…

Yes, I was highlighting my view. To respond to the advantages mentioned:

- Roda (or Sinatra) gives routing. Actually it's very advanced routing that can be composed

- JSON serialization can be achieved more easily with Hash + Array and a subset of basic types (boolean, numeric, string, nil), which are easier to generate than with jbuilder, and it's also more performant. That being said, nothing stops developers from using tilt-jbuilder (gem) to get immediate support from Tilt for jbuilder, which can be used from Sinatra and Roda seamlessly, and can also be called everywhere, not just views

- Roda has built-in security too (I don't know about Sinatra, but I presume it does), there is a section in the README: https://github.com/jeremyevans/roda#security- as well as multiple plugins http://roda.jeremyevans.net/documentation.html#external

- Rails testing is actually _harder_ than normal Ruby testing. On top of my mind, a glaring example of this is the impossibility to instantiate a Controller and do dependency injection on them, which should be normal for any object. This is not a problem if dealing with just Ruby. Rack-test gives the same "request specs" that are present in Rails (actually it's built on top of that). As usual, the option of choosing different testing frameworks is available, given that it's normal Ruby. There isn't a need for special testing framework integration, so it's possible to use the beautiful Test Bench: http://test-bench.software/

- Devise is actually a bad choice for Rails API. It's poorly documented when used in API fashion (authentication through token), providing a whole set of utilities for sign up that are unneeded for API. However these endpoints do expand the attack surface, reducing security. The performance is also reduced, when authentication can be achieved with Redis instead of an SQL database as backend. The amount code needed for secure and well defined authentication can be written in ~5 hours of production quality code, with extensive testing (I did this quite recently). Either way, `rodauth` is available for every need

- Rapid data and logic modeling, presuming I understand what it's referring to in this context, it's given by ActiveRecord, that gem can be used with anything, there is no necessity to use Rails. This brings data migrations. For logic modeling, that is a Ruby feature, not a Rails one: Rails doesn't provide any utility from the logic perspective. In addition, putting logic into ActiveRecord models is very dangerous and known to be a problem by the community

- Rails doesn't provide metaprogramming, Ruby does. That is available with any Ruby application

- Rails does provide the scaffold command, but if the amount of tables that needs to be written is so large that this command is actually providing a benefit over duplicating a file (the activerecord model. ActiveRecord already provides the command for generating migrations wherever it's used), then the cost for writing a Rake task that generates a migration and a new file with an empty ActiveRecord model is negligible (1 hour)

With Roda I see other advantages: - Highly performant webserver (13 times faster than Rails API, 10 times smaller memory footprint: https://roda.jeremyevans.net/)

- Incredibly faster application load speed. Restarting the server is not a problem, running the test suite is not a problem either

- No autoloader, while preserving the ability to reload code. Now Ruby `load` behaves like the normal Ruby load (not monkey patched). This prevents a gigantic amount of problems reached as soon as the app starts to grow, related to how Rails loads constants: https://www.honeybadger.io/blog/avoid-these-traps-when-nesti...

- Using traditional tools for handling javascript, CSS and public assets, which Frontend developers are familiar with (webpack, parcel)

- Very small project, with ~4-5 files the whole setup is ready

- A tremendously smaller API surface (API as in "application programming interface", not HTTP), this greatly helps reducing bug surface and cognitive overload

Now if the application's need is form-over-data (so, not a JSON API), then sure, use Rails. But in that case you must be using ActiveAdmin, to get real advantages. In that space, there is a large amount of competitors in other languages or no-coding tools that Rails has to face. On top of my mind: Forestadmin, Hasura, PostgREST, Django with Django Admin.

Re: Matestack – Reactive UIs in pure Ruby

#116

Earlier quoted context omitted.

> Yes but at that point you are getting all the disadvantages of Rails, without the strong points (fast prototyping and everything related to rendering HTML pages, file uploading etc.). Your perception of the strong points of rails are very different from mine. The strong points include rapid data and logic modeling, json serialization (jbuilder), robust libraries for user management (devise) and many other things, b…

Yes, I was highlighting my view. To respond to the advantages mentioned: - Roda (or Sinatra) gives routing. Actually it's very advanced routing that can be composed - JSON serialization can be achieved more easily with Hash + Array and a subset of basic types (boolean, numeric, string, nil), which are easier to generate than with jbuilder, and it's also more performant. That being said, nothing stops developers from…

I'll check it out, I'm a fan of Jeremy Evans sequel gem.

Re: Matestack – Reactive UIs in pure Ruby

#117

Earlier quoted context omitted.

Yes, I was highlighting my view. To respond to the advantages mentioned: - Roda (or Sinatra) gives routing. Actually it's very advanced routing that can be composed - JSON serialization can be achieved more easily with Hash + Array and a subset of basic types (boolean, numeric, string, nil), which are easier to generate than with jbuilder, and it's also more performant. That being said, nothing stops developers from…

I'll check it out, I'm a fan of Jeremy Evans sequel gem.

Cool, glad this was helpful. If nothing, it gives a different perspective on the Ruby world!

Re: Matestack – Reactive UIs in pure Ruby

#118
post #102

Earlier quoted context omitted.

Did you miss this part: >1) a websocket-based HTML sync layer, basically shipping over the smallest amounts of render state from the back-end. This is as close as you get to having, essentially, a server-side rendered page that is then updated in real time. Also it's not like you have to load the runtime more than once. So it's not that it's a non-starter for anything performance sensitive--it's a non-starter for any…

Compared to React + React DOM at 109k unzipped Blazor's runtime at 2MB is a significant hike in download size so unsuitable for older devices and constrained bandwidth networks.

1. Being too large for constrained bandwidth networks hardly makes it a non starter for anything performance sensitive unless you have a very narrow definition of performance.

2. 2MB includes bootstrap CSS and they are working on getting that number down.

3. 2MB is only the Wasm version of Blazor. You don’t have to use that version if it doesn’t fit your use case.

Re: Matestack – Reactive UIs in pure Ruby

#119
post #102

Earlier quoted context omitted.

Compared to React + React DOM at 109k unzipped Blazor's runtime at 2MB is a significant hike in download size so unsuitable for older devices and constrained bandwidth networks.

1. Being too large for constrained bandwidth networks hardly makes it a non starter for anything performance sensitive unless you have a very narrow definition of performance. 2. 2MB includes bootstrap CSS and they are working on getting that number down. 3. 2MB is only the Wasm version of Blazor. You don’t have to use that version if it doesn’t fit your use case.

I don't have to use it but Wasm Blazor is the version everyone is shouting about. Well, everybody at the Microsoft hype machine that is.

Re: Matestack – Reactive UIs in pure Ruby

#120
post #119

Earlier quoted context omitted.

1. Being too large for constrained bandwidth networks hardly makes it a non starter for anything performance sensitive unless you have a very narrow definition of performance. 2. 2MB includes bootstrap CSS and they are working on getting that number down. 3. 2MB is only the Wasm version of Blazor. You don’t have to use that version if it doesn’t fit your use case.

I don't have to use it but Wasm Blazor is the version everyone is shouting about. Well, everybody at the Microsoft hype machine that is.

Go to the Blazor homepage. Right there on the front page--the 2nd bullet point is "Run on WebAssembly or the server".

Most people I've talked to using Blazor are in fact using Blazor server not Blazor WASM.

Post reply on HN