41–50 of 88 posts
Earlier quoted context omitted.
AdonisJS is also really great, very much inspired by Laravel (which was inspired by Rails)
First time hearing of that, not sure it passes the "battle tested" sniff test here. No offense, might be a great framework but the gist of the blog post is A) what you know or B) Rails (if you don't know what to choose)
I strongly agree with the article's points. While I haven't used Rails, I'm a Django developer and have never built something with Rails; I like the benefits of sticking with full-stack frameworks. Rails is a solid choice, but Django, especially when combined with htmx, also enables quick and robust application development. It's refreshing to read about someone who prefers a straightforward approach (using boring tec…
What is your ideal Django stack (from front-end, to backend, APIs, database, hosting, etc), using well-supported, solid tech?
The good part is that if you start early with a good design, it's fairly clear how to move from views to a REST API (DRF or Django-ninja) later and split the front end if you need to.
Rails is absolutely fantastic for projects below 10,000 lines with 1 or 2 contributors, especially if you want a classic forms-based UI. And you can get a huge amount done under those constraints in Rails. But as of couple of years ago, Rails came with a number of drawbacks: 1. There was no really viable system of static typing that a significant number of people were enthusiastic about. See https://www.reddit.com/r/…
Static typing vs not has clear pros and cons. I do appreciate that JS/TS offers you a choice but I personally prefer Ruby the way it is. Your other comments are basically: - ruby/rails has a great 3P package system - oh and yes you can choose "bad" ones - ruby/rails let's you quickly write great code - oh and yes you can just as quickly write "bad" code
This article is just as valid if you ran :%s/Rails/Django/g. I use Django to run both www.fpgajobs.com and www.firmwarejobs.com and love it.
Rails is great, until it's not. Many of whe successful companies built on Rails were started in a different world without lots of external APIs (OpenAI anyone?) to integrate with, user expectations around central identity, authz and other things you'll want to talk to in order to serve a request. In 2024, I wouldn't start a company or project based on a language and framework that doesn't have a great concurrency sto…
My company (large, well known tech co) actively instructs engineers to not use concurrency features, in a language that is known for having "great concurrency", unless they have a really, really good reason to. The vast, vast majority of workloads, especially at small startups, do not need a concurrency story outside of running N processes. Concurrency often gets in the way more than it helps unless you're actively t…
Rails is absolutely fantastic for projects below 10,000 lines with 1 or 2 contributors, especially if you want a classic forms-based UI. And you can get a huge amount done under those constraints in Rails. But as of couple of years ago, Rails came with a number of drawbacks: 1. There was no really viable system of static typing that a significant number of people were enthusiastic about. See https://www.reddit.com/r/…
For web apps maybe. What's the "boring" / productive stack for desktop apps? There's this weird paradox with programming languages which causes unproductive stacks to become more popular because programmers like "difficult" stuff and they also generate more online activity.
Rails is absolutely fantastic for projects below 10,000 lines with 1 or 2 contributors, especially if you want a classic forms-based UI. And you can get a huge amount done under those constraints in Rails. But as of couple of years ago, Rails came with a number of drawbacks: 1. There was no really viable system of static typing that a significant number of people were enthusiastic about. See https://www.reddit.com/r/…
I suspect you'd find the same thing if you were a python or php consultant diving into python or php projects.