Comment by dperfect | Hacker News Reader

Comment by dperfect | Hacker News Reader

Parent Full thread

I used Rails for a lot of projects starting ~10 years ago, but slowly gravitated towards a stack based on Sinatra (for a lean REST API), Middleman (static site generator), and webpack/react/etc - for mostly the reasons you describe.

In hindsight, I can't blame Rails for the direction it took; JavaScript's path (the language itself, as well as the tools) has been extremely volatile in that time. Rails is opinionated, which is part of what makes it great, but to be more opinionated on JS in the past probably would have been detrimental to the Rails community. I've felt the pain in my own work: every 2 weeks, it feels like my webpack/react/babel/etc toolchain and codebase need to be refactored because what was recently best-practice is now considered "legacy" and unsupported. When you embrace a specific set of technologies, you take on a certain amount of risk that those technologies will be deprecated, unsupported, or unpopular tomorrow.

I believe (hope is probably the better word) the JS landscape is getting more mature and stable, and it makes sense that the recent versions of Rails have incorporated more of what has become "standard" JS tooling. I'll always love Ruby, and even if I don't use Rails at the moment, I appreciate what Rails is doing and I directly benefit from the contributions of the Rails community.

More recently, I've been trying to learn some Elixir (those Phoenix LiveView demos look amazing), but not sure I'm ready to jump in 100%. Looks like matestack is essentially doing something similar with Ruby, so I'll be interested to see where it goes.

This is probably a very dumb question but I'm new to all this and trying to figure out how to mix/match these frameworks like you're describing. I have primarily a static site (using Jekyll, but Middleman would apply) but now need to add some server side stuff (e.g. with Sinatra). I see how I could dump my generated site into the Sinatra /public directory, but then I'm serving everything through the sinatra server when I really only want to hit that when I need the dynamic content/calls. How would I keep them separated while still having a single environment? Have tried googling to no avail, don't know if I'm asking the right questions. Any pointers would be super helpful! Thanks

Not a dumb question! I'm sure there are a lot of different approaches that could work.

For my own projects, I like to keep client-side code separated from the server-side code. The static site (with compiled JavaScript) gets deployed to S3/CloudFront, while the Sinatra API is packaged as a Docker image and deployed to ECS (or any container service)[1]. This means that Sinatra is only handling the API requests, and all of the markup, JavaScript, and other assets are served from a CDN.

[1] For this to work, you'll likely need to set up CORS on the server side, but that's well-supported now and fairly simple to set up.

If you want a sinatra equivalent for elixir, you can use plug.

You can try out Turbolinks, the Rails equivalent for LiveView.

This is not exactly a great characterization of turbolinks. TL definitely is great and useful for blurring the lines between server rendered and SPA, but it isn't anything like liveview. For that you're looking for something more like Motion (https://github.com/Unabridged/motion). Disclaimer, maintainer, but the comparison is much closer.

And StimulusReflex, although Motion is slightly closer to LiveView, but both are in the same Category as LiveView. Turbolink is definitely not though.

No, liveview does everything on the server, including holding the frontend state, which is why it's so powerful.

Liveview can't be reproduced in ruby, currently. It might be a possibility once Ractor are there, but even in that case Ruby doesn't have the performance optimizations of elixir templates (and given how liveview works, those are needed). It might never be possible, or it might be possible in many years.

Yes this is where I see Ruby 3 being irrelevant, unfortunately. Ruby and Python are single-threaded, dynamically typed languages designed for the 1990s. You can try to retrofit anything you like and pretend you have real concurrency or static typing but it will never be the real thing and you'll just end-up with thousands of legacy libraries.

I think Erlang is older than Ruby? (Not sure, but it's pretty old!) As for single threaded, they are not, even with green threads, IO is usually the problem (otherwise you chose the wrong language).

As for static typing, there advantages and disadvantages to that, I wouldn't consider that a minus at all. A good engineering culture brings you in the same place with a dynamic or static typed language. Same goes for a bad engineering culture.

Reply on news.ycombinator.com