Do you eschew RoR and use an alternative Ruby web development approach? (Example: different framework, or writing your own framework)
The Neocities frontend is basically something much simpler built on top of Sinatra and I haven't regretted that decision at all. It's (relatively) clean and simple, and if I need to do something weird that doesn't conform to the paradigm (this happens a lot), it quickly gets out of my way. You can generally do anything you want with Rails, but in my experience that more frequently involves digging through a bunch of documentation and google searches to try to figure out how to get the framework out of my way.
I've also found ruby to be a really solid language for doing lower level glue tasks, for an unusual example I use it to glue a redis database to powerdns, which serves a lot of query requests, it's plenty fast and very reliable. I've never had to rip out ruby from something more performance-oriented and replace it with something "faster".
At the same time if I had a team of 10 people I was working with I might appreciate Rails keeping everybody on the same design structure so I there's not an endless battle over how it should be put together, but in my past experience this kind of just happens with Rails too.
Hey good job on Neocities btw.
I've noticed that a lot, and while it's not wrong to adhere to the "golden path", I take issue when it becomes instilled as rhetoric in a developer and precludes them from understanding or dignifying someone else's choices or questions when deviating from it.
There's always this aggression-of-curiosity in response, never a "well you'd do x, y, and z, but it's not recommended". It's always "Well why would you do that? That's wrong, you're supposed to..." and then an hour later after someone is red in the face just asking a question it comes down to "yeah I've never used 0mq before with rails, sorry maybe try Slack"
[edit: The comment I was originally replying to has gone from 1 sentence to a paragraph and is still receiving edits. Including this note for posterity just in case it looks like I'm talking to myself in a closet.]
(I'm not saying it's better than Rails, just that it's better than Rails for me.)
> We’ll be doing some deep dives into our new infrastructure in the future, including discussing how we built our own anycast network
(https://blog.neocities.org/blog/2017/03/26/huge-space-increa...)
Rails 7 has been my favorite version since 3. Version 3 was probably the peak of metaprogramming and when basically anything you tried worked which was fun but really cowboy.
This!!! I can't express this enough, Ruby is the sweet spot for gluing things togheter and rapid prototyping.
I've built a few Sinatra/Flask systems since, so I'm definitely a fan of the virtue of simplicity, no matter the language.
The design mistake here is not applying lessons learned reading Danny Greenfeld's book (which I don't believe shipped before 2012) on Django and realizing the chapter on "vanilla Django" applies just as much to any system, like "vanilla Rails", because they are the same "stranger in a strange land" problems where the system as we know it becomes undocumented and unbounded by architectural style - a kind of McMansion Hell for system design.
The use of DSLs is complex territory. When in the hands of a master, amazing work can happen, but when too many DSLs are combined together, you wind up with exactly the opposite of what Greenfeld described in the chapter on vanilla Django, you wind up with byzantine Rails, because the boundaries that Alan Kay described decades earlier are not architectural. As with much software, there is no physics, real or implied, that applies to the phenomenological understanding of the system, the individual and social human scaling of brains that turns out to be a larger problem than computer hardware and software scaling.
There is a semantic asymptote, if you will, where the problem leaves the empirical world and becomes phenomenological - very difficult to share socially unless you are Kay, Knuth, or one of their contemporaries.
Jeremy Evans is the creator and maintainer of both of these Ruby gems and is super helpful in resolving ask kinda of issues.
I started the codebase over a decade ago now, and at the time Rails felt a little heavy (inline with your comments). That said, Rails does let you get started pretty quickly without needing much of anything else.
Rails has more magic. If you prefer less magic, then Sinatra is the way.
See https://richstone.io/why-do-we-call-it-ruby-and-rails-magic/
What problem are you trying to solve by asking these questions? What context is this question for? Are you curious how many people use a non-rails solutions for enterprise apps? Cloud apps? Personal projects? Apps you want users to pay for? A blog?
I'd suggest stating what problem you'd like to solve by asking this question so you can receive more detailed feedback. For example, if your company is spinning up a new app and you're evaluating choices, someone may respond that they used sinatra but found themselves reinventing rails so they wish they would have used rails. I'd say this is more insightful than "yea, we use sinatra". Alternatively, maybe someone used sinatra for a personal project and found the experience of reinventing rails rewarding and educational on their own time. Let us help you!
Rails latest release (7.0.4) have 386,970 lines of code in total, 310,779 of it being Ruby code. 3000 files in total. Just the `lib` directory of `activerecord` has 33,036 lines of code, across 369 files.
By most metrics, RoR is pretty heavyweight, as their literal taglines are "Ruby on Rails scales from HELLO WORLD to IPO" and "A web-app framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern", so it needs to be pretty big to support those use cases.
Full `cloc` report in case someone is curious:
4268 text files.
3839 unique files.
511 files ignored.
github.com/AlDanial/cloc v 1.96 T=1.25 s (3079.1 files/s, 434339.6 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Ruby 3013 73152 54669 310779
Markdown 92 19324 388 45525
JavaScript 87 2974 2170 20955
YAML 171 406 350 3679
CSS 23 347 152 2409
ERB 386 303 9 2244
CoffeeScript 12 97 125 413
JSON 11 7 0 372
HTML 21 15 3 200
Bourne Shell 2 20 25 167
Text 7 0 0 51
yacc 1 4 0 46
SQL 1 6 0 43
Dockerfile 1 7 7 40
SVG 7 0 1 36
builder 3 1 0 10
DTD 1 0 0 1
-------------------------------------------------------------------------------
SUM: 3839 96663 57899 386970
------------------------------------------------------------------------------- --skip-git Skip git init, .gitignore, and .gitattributes
--skip-keeps Skip source control .keep files
--skip-action-mailer Skip Action Mailer files
--skip-action-mailbox Skip Action Mailbox gem
--skip-action-text Skip Action Text gem
--skip-active-record Skip Active Record files
--skip-active-job Skip Active Job
--skip-active-storage Skip Active Storage files
--skip-action-cable Skip Action Cable files
--skip-asset-pipeline Skip Asset Pipeline
--skip-javascript Skip JavaScript files
--skip-hotwire Skip Hotwire integration
--skip-jbuilder Skip jbuilder gem
--skip-test Skip test files
--skip-system-test Skip system test files
--skip-bootsnap Skip bootsnap gemIf you ever plan on becoming liable for the framework code you're doing something very wrong.
Do you have the same concerns about your compilers? Your web servers? "More code, more liability" is a very sloganeering/cargo-cult take.
I’m currently down with the Flu B, so don’t feel like looking up citations, and for that I apologize. My recollection is that this was, unsurprisingly, a fluid estimated, with lots of caveats attached to it. Regardless, it struck me as true, and something I’ve never failed to take into consideration when writing my own code.
And does ANYONE here want to compare Rails with the standard "enterprise" stack of Java and React, and all their implied dependencies (Spring, Lombok, etm.)?
Not sure what do you mean by "most metrics". Framework supporting features is not same as they being used all at once in every app.
PostgreSQL has more than 1.3M lines of code and it gets used by projects of all sizes, would you call it "heavyweight" too?
some people don't want have a server only for this and accept the drawbacks of not having a full database server, for example remoteok.
Suggesting that LOC does not support this argument, and perhaps is not a great metric in general, especially across different languages.
https://www.sqlite.org/amalgamation.html (as of Version 3.37.0 - 2021-11-27)
Maintaining a Postgres server or cluster is hard. But it offers way more functionality.
I agree that the term heavyweight can mean many things to people. I’ve take it as a generic mix of maintenance, complexity of project, ease of use for your purposes.
Yes. There’s not a definition of “lightweight” that could be applied to psql, at least without making the word useless.
One issue I could think of when a framework dominates a language is that it could steer changes in that language that benefit itself more than the language.
The whole service (which isn't too complex) is a file script in Ruby managed through SystemD. This script turns off/on the screen based on API calls, and is also in charge of scheduled/remote restarts, pinging the backend and stuff like that.
What I like the most is how easy and reliable is. Beeing a below average guy, ruby makes really easy to combine system calls, API calls and shell commands within the same context.
I first started writing my APIs using Sinatra about 10 years ago. I had started with Rails when it first came out around 2005, liked it, but then ran up against a lot of issues. Sinatra and the Sequel gem were amazing so I switched to that, since I didn’t need most of what Rails had.
Now I just use those two out of habit. Rails is a LOT better now, but i still just reach for Sinatra and Sequel usually.
It does seem to be much more the exception than the rule. But it may be getting more common with kubernetes deployments which make lots of individual services a bit easier to manage.
I started with Rails when migrations were just .sql files you wrote by hand. I switched to Sinatra mostly to use Sequel, because ActiveRecord at the time would do horrible queries unless you wrote them by hand. I know they have solved that issue, so I should try Rails again… but my Sequel muscle memory is pretty strong at this point.
An old joke: any sufficiently advanced Sinatra app is indistinguishable from Rails.
You kind of do. First, you have to opt-out, not opt-in. And the opt-out path is less battle-tested, so there's a lot of skeletons to be found there. Use it at your own risk.
If you want the best modern example of a ruby framework which starts small (like sinatra) but allows you to opt into a wider feature-set (like rails), you should give roda a look: https://www.youtube.com/watch?v=9fukis_VHl4
Turns out, Rails is a really good web framework! I tried building Sitepress on something “light weight”, Tilt and Rack, and it was a pain. I found myself constantly solving the same problems that were already solved in Rails. At some point it dawned on me that I could just build on top of a few parts of Rails, so I did. I wrote about it at https://fly.io/ruby-dispatch/single-file-rails-app/
I’m glad I did! Now I can plug all of the Rails template handlers, view components, and other Rails plugins into it and ride off that entire community’s docs.
If you find yourself thinking, “rails is too heavy”, consider shedding the parts of Rails that you don’t need. Then as your application grows in complexity and you find yourself needing more parts of Rails, bring it back in.
I have a small project to explore the various multitasking paradigms in Ruby, here: https://github.com/rickhull/miner_mover
It provides everything needed, while still allowing to fully control which features I want to disable.
I'm using the async-http gem for the HTTP/2 server and it works great for my use case.
I would bet that Stripe is the large non-Rails Ruby user in the world?
I've used Sinatra plenty of times but only used as a backend api, no frontend rendering.
I have tried Ruby CGI but very barebones - no MVC.
I haven't tried Sinatra, but someone at a Ruby web development company told me Sinatra works for APIs but difficult for websites, but it isn't battle-tested like Rails.