Live data from Hacker News

Django and Postgres for the Busy Rails Developer

andyatkinson.com

71–80 of 127 posts

Re: Django and Postgres for the Busy Rails Developer

#71
post #35

Earlier quoted context omitted.

A bit off topic, but whenever Rails and templating get brought up, I have to plug my absolute favorite project out there: Phlex https://beta.phlex.fun/ . It's like ViewComponents, but swap out the ERB for pure Ruby. It has been a joy to develop with. With the addition of Phlex::Kit, it has made building out a component library pretty easy too. RubyUI https://github.com/ruby-ui/ruby_ui does a great job of showing off…

Those kind of things used to be a lose lose proposition back at the time of haml (?) and all the yaml like templating languages. That was more than 10 years ago. The reason was that any designer that could actually do html was able to write an erb page, maybe except loops and logic, but they could understand them if a developer added them into the page later. On the other side with one of those languages, and more wi…

https://www.phlexing.fun/ We have this for that. :)

Re: Django and Postgres for the Busy Rails Developer

#72
post #4

I'm working on a Rails and on a Django project for two different customers and I've been doing that for years now. I'd pick Rails over Django any time for every single feature. The absolute worst Django feature is the templating language. It seems to be designed to slow down developers to the like of old time Java web apps, almost mandatory templatetags et all. The query language is moderately bad, quite verbose (Mod…

Python is used for much more than just web dev and Django, whereas Ruby seams to only be synonymous with Ruby on Rails. Do you think Rails is still worth using when investing in learning Python and Django has a much higher roi?

> Ruby seams to only be synonymous with Ruby on Rails.

Seems to be... But it can be used for anything Python is. There's ML libraries, bindings to stuff like Torch, all the math-y stuff like Python, all sorts of stuff. Also it's a great language to just roll your own scripts, programs, etc... Then there's also mruby, which can be embedded like Lua...

Re: Django and Postgres for the Busy Rails Developer

#73
post #44
post #19

Earlier quoted context omitted.

Ruby, and Rails in particular, has a lackluster dev experience with any editor that isn't RubyMine. That's been a huge obstacle for me personally.

Each to their own I guess. Personally I like the ruby-lsp and TPope’s Rails plugin in NeoVim. I dislike heavy weight IDEs, I never find the juice is worth the squeeze.

I want to like ruby lsp but it takes about 8 seconds to get method references in a large monorepo. It’s simply not good enough, and forces anyone looking for a good devex into rubymine

Re: Django and Postgres for the Busy Rails Developer

#74

Well. I use GeoDjango with PostGIS. Django supports it natively. And django-rest-framework takes it to another level. Python has the best machine learning and AI support too. It is very easy to mix geographic libs with data science tools. To build a simple CRUD software with vanilla SQL you really don't need Django and Python. But I challenge any one to try a GIS full stack without Django and Python. Just look for GD…

I second this 100%

Re: Django and Postgres for the Busy Rails Developer

#75
post #4

I'm working on a Rails and on a Django project for two different customers and I've been doing that for years now. I'd pick Rails over Django any time for every single feature. The absolute worst Django feature is the templating language. It seems to be designed to slow down developers to the like of old time Java web apps, almost mandatory templatetags et all. The query language is moderately bad, quite verbose (Mod…

Shameless plug for https://www.reactivated.io It swaps the templating engine for React. But still server side and using all the Django features you know and love. No SPA needed.

thanks for sharing! The server side story is definitely a consideration why I'm not hyped on Inertia.js for now, this seems to solve it. My current nitpick is my personal preference for Svelte/SvelteKit. I hope you don't mind me taking a look at the repo and try to have Svelte as an option.

Re: Django and Postgres for the Busy Rails Developer

#76
I’ve spent a lot of time with Django, and not a lot of time with rails.

For me, if I was doing minimalist CRUD and wanted to ship to mobile or a lot of users, I’d reach for Rails. Hotwire and Turbo seem great, and the ecosystem just seems better and more developed for customer facing stuff.

Most of my work has been internal tooling with an emphasis on data analytics or geospatial. Having python libs run natively is a big win for data analysis, and as another commenter posted, geodjango is very tough to beat for usability for geospatial work. For this I still maintain Django is pretty unbeatable.

I am happy to be corrected in both domains though, again, not much rails experience here beyond a couple toy projects.

Re: Django and Postgres for the Busy Rails Developer

#78
post #64

Earlier quoted context omitted.

I've used them both in production enough to feel qualified to counter these, but we'd all just be arguing for our opinions. Both are excellent frameworks, with no clear standout IMO. I will say one thing in response: we've found it approximately 10x easier to find devs having years of experience with Python than with Ruby. That's a non-trivial argument in Django's favour in our organisation.

Perhaps, but ruby is trivial to learn.

The basics are trivial to learn but the object model and lambda style programming as well as metaprogramming (method_missing, etc) can be overwhelming for some folks to pick up quickly. I absolutely love Ruby though.

Re: Django and Postgres for the Busy Rails Developer

#79

> Migrations in Django > > The Django approach has noteworthy differences and a slightly different workflow My explanation of Django's approach to migrations would involve a lot more expletives. It is by far my least favorite thing about the framework. - Fields are not-null by default, the opposite of SQL itself - Field declarations use argument names that sound like the SQL equivalents (default, on delete cascade/re…

> Generally the field declaration/migrations system in Django feels to me designed to lead people down a garden path towards bad and dangerous behavior. If I had my druthers I'd enforce a policy in our Django app of "never run makemigrations, all migrations must be manually written SQL". `makemigrations --dry-run` is helpful to see if your manual migrations are complete but besides that I agree

I believe `makemigrations` builds up its conception of "what the schema is" from the `CreateModel`, `AddField`, `AlterField`, etc. ops in the migrations files. But it doesn't incorporate `RunSQL` ops into building that model of the schema. If my migrations were just a bunch of `RunSQL` ops, I think `makemigrations --dry-run` would basically just see everything from models.py as always needing to be added.

This behavior is why `SeparateDatabaseAndState` is a necessary hack in Django: sometimes you need to do an `AlterField` where the SQL Django would generate is really bad, so you need to write your own `RunSQL` to do the right thing, but you also need Django to see the `AlterField` as applied or you'll have problems with future migrations.

I suppose I could modify my preference to "run makemigrations and then wrap every single op in SeparateDatabaseAndState", but that does not sound fun :).

Re: Django and Postgres for the Busy Rails Developer

#80

Earlier quoted context omitted.

Shameless plug for https://www.reactivated.io It swaps the templating engine for React. But still server side and using all the Django features you know and love. No SPA needed.

thanks for sharing! The server side story is definitely a consideration why I'm not hyped on Inertia.js for now, this seems to solve it. My current nitpick is my personal preference for Svelte/SvelteKit. I hope you don't mind me taking a look at the repo and try to have Svelte as an option.

Sure thing. The magic is in vite.mts, render.mts and renderer.py

In theory, you could swap in Svelte in there.

Post reply on HN