9 ms·

Rails (and possibly Django and Laravel) are just light-years ahead of any other stack for building web apps. They have dealt with all the tedium, know all the r

• alanfranz 2y ago
  I must say that even if it’s not a trendy stack, I find Spring Framework/Spring Boot to be the best all-around web application stack. Very easy integration with the tons of java libs you have around that can do virtually anything, a statically typed language which can help in a lot of situations (just data binding by convention via Jackson is great since forever, while it’s an afterthought in dynamically typed languages).
  • t-writescode 2y ago
    I've been incredibly pleased with Ktor and Kotlin, as well. JVM underneath, robust libraries, easy to use infra, using Exposed for the ORM which is mostly (genuinely) a joy. The best thing I think Rails still has is ActiveAdmin. Everything else, I really can take or leave.
    • Tainnor 2y ago
      > The best thing I think Rails still has is ActiveAdmin. Everything else, I really can take or leave. ActiveAdmin gets you off the ground very quickly, but is also extremely inflexible (and, IIRC, poorly maintained). The last time I worked on an ActiveAdmin backend we had to use all sorts of weird hacks to build the interface the way our backoffice team needed it to be.
      • RangerScience 2y ago
        AA is really just some wrapper and glue around some other tools… which aren’t super well documented either, but it definitely does mean that a) you can do weird/custom stuff, and that it’s a PITA to figure out how.
    • dajonker 2y ago
      In another company I had to completely replace ActiveAdmin with "vanilla" Rails abstractions as it was quite buggy and caused Rails to hang indefinitely as soon as you edited any ruby file. The admin part also turned out to be the most used part of the app, so it probably made sense to replace it in any case, but the bugginess at the time was more than I could handle.
    • regularfry 2y ago
      Admin is the one area where Django has the edge, but it's enough on its own for me to push Django over Rails for a lot of "just put a UI around some data, please" use cases.
    • taikon 2y ago
      I recall Active admin having really clunky UI a couple years ago. I just checked it again and it looks really sleek!
  • egeozcan 2y ago
    I did write a lot of Java but never called myself a Java developer, and in my current company there are a lot of hardcore Java devs who used to swear by the Spring stack (some even liked JSF!), and a lot of them are moving things to Quarkus (https://quarkus.io/ https://quarkus.io/). No idea why, just an observation.
    • sagacity 2y ago
      They are moving there because it's new and shiny, not because it's better. Spring and Spring Boot are incredibly productive and give you a ton of stuff out of the box, whereas some people actually enjoy writing a lot of plumbing code as a distraction/challenge from boring business code. Those people will migrate to "lean" frameworks because it will give them the opportunity to write more low-level plumbing code.
      • ffsm8 2y ago
        > They are moving there because it's new and shiny, not because it's better. I highly doubt that. The real reason is likely more about the GraalVM, which spring hasn't supported until very recently. (And still only with caveats)
        • sagacity 2y ago
          That sort of proves my point, though. Spring support for GraalVM is ongoing and will likely be quite useable and mature out of the box. The people jumping to Quarkus or Micronaut are more eager to chase the new shiny and are willing to spend the time debugging not-yet-mature stacks. Edit: To be clear, the reply mentions fanboyism but we are talking about the maturity of a stack. Spring has been around for 20 years and is not going anywhere. Quarkus just reached 5.
          • ffsm8 2y ago
            The GraalVM is significantly more performant. Calling that "chasing the new shiny" redefines the meaning of the expression, which has historically been about side-grades for unclear advantages. Especially considering that Springs support isn't full yet, and quarkus has been around for 5yrs now. They're both production ready stacks though, really strange to have spring fanboyism in 2024
  • michaelmior 2y ago
    I think part of the problem may be that a lot of people are familiar with old versions of Java before things like lambdas and anonymous interface implementations were possible. Writing Java without some of those things can be pretty painful.
  • camdenreslink 2y ago
    ASP.NET Core is similar. Not necessarily trendy, but very efficient to work in.
• egeozcan 2y ago
  From my experience, these frameworks are like the express lane for kicking off a project because there are no big decisions to make. But once you’re knee-deep in Rails, Django, or Laravel and need to do something off the beaten path, things can get dicey. Why? Because you didn’t write the glue code yourself, so there's a gap in understanding, not really a technical roadblock (most of the time!). My point is, if you dive into these frameworks and actually learn the guts, you'll save yourself tons of time coding by, well, reading code. Now, do I actually do this? Absolutely not. Rewriting everything is way too much fun, and I live for the thrill of trying new things, even if it makes zero business sense.
  • whamlastxmas 2y ago
    What’s an example of a feature for a Laravel site where not fully understanding the mechanisms of Laravel under the hood would make that existing code get in the way of building the new feature? Genuine question.
    • egeozcan 2y ago
      Luckily I have a real life example from a customer project I was involved as a consultant: Integrating a custom identity provider with multi-factor authentication. This was from many years ago though. They also used to have some performance problems in some naively implemented middleware and needed to deep-dive into how things actually work before being able to optimize. And commands - I was doing the integration with our software and their command queue was always causing problems with stuck jobs until they read the implementation. The specific problem with Laravel as a product is (was?) that the docs are too beginner oriented and perhaps "you don't need to know what's under the hood" mindset is exactly what's causing this. I got to know many experienced PHP developers who got really frustrated because of the ELI5 style docs. You can't always rely on the docs too, however excellent they may be - some game developers read code from game engines to optimize, some web developers read code from their web frameworks. But, some change their whole stack when they get frustrated, and I argue that it makes little to no business sense to do so. Just understand what you are working with and deeply.
• ethagnawl 2y ago
  I came through to note that most of this applies to Django, too. I've historically preferred RoR but with the tremendous growth of Python in the last 10+ years, Django has become a more practical choice. ML and data science devs are already familiar with Python and, with the Django docs being as excellent as they are, these folks can be productive in a very short amount of time -- should they need to be. I've seen this firsthand on multiple projects. Also, along with the author's case for the path of least resistance, the Django framework results in fewer "decisions" (arguments) about application structure than using a less opinionated library or micro-framework. The Django/FLOSS community is also much more active than I was expecting it to be (Rails bias, probably) and has been very pleasant to interact with. I only wish Django had Rails-like generators and in-built data seeding (e.g. rake db:seed).
  • appplication 2y ago
    Django has been an absolute pleasure to work with. Contrast it to flask, which is a complete footgun factory. I agree 100% on there being (honestly, massive) value in reducing decision points in the project. Very few devs truly have the experience needed to see around the corners in their designs and architecture, and Django represents the culmination of decades of learnings on what works, and works well. Overall, I’ve been very impressed with the product and maintainers. There are so few OSS projects that rise or the level of quality that Django has managed to achieve. Now if only they could sort out type hints ;).
  • physicsguy 2y ago
    You can seed with JSON files as "fixtures" and run `python manage.py loaddata fixturename`. The thing I wish Django had better OOTB support for is background tasks, I've not used it but I understand this is very well done in Rails and Laravel.
    • ethagnawl 2y ago
      Interesting! I will give fixtures a look. I've shied away because -- unless you introduce a manual step to generate them, my understanding is that they're static. You're spot on about background jobs. Rails added support 2-3 major versions ago and there's no shortage of back-ends. With Django, it seems to be Celery-or-bust and there's no Django API that I'm aware of. I actually recently rolled my own solution using SQS and a dedicated compose service which runs a management script (in the Django context). It works but ... it's klunky, the API is ad hoc and there's no monitoring/retries/etc.
• rockyj 2y ago
  I do not agree. Rails is absolutely great in terms of features and productivity, but will fail you elsewhere i.e. it is not the silver bullet for webdev. Do not take my opinion, look at data - https://www.youtube.com/watch?v=Qp9SOOtgmS4 https://www.youtube.com/watch?v=Qp9SOOtgmS4 If you are using Rails for anything where you are not absolutely sure of how many users or RPS you will have, you are just saving money in launch time but spending more on servers.
  • BoumTAC 2y ago
    Shopify is built using Ruby on Rails, they successfully handle enormous traffic spikes during Black Friday sales without issues. So I think we're good with performance.
    • rockyj 2y ago
      Everything can scale if you throw enough servers at it. Of-course Shopify scales, they even spent time and money to build a JIT on top of Ruby. As a smaller company, does everyone have the time and money to spend on servers or optimising the language to this extent?
      • lentil 2y ago
        Smaller companies have less traffic, need less expensive servers, and have no need to spend money optimising the language. They can focus on that when they make billions of dollars, like Shopify does.
        • axelthegerman 2y ago
          And in the meantime just passively benefit from the OSS improvements along the way
      • chucke 2y ago
        No, they only have time for features and productivity, which is, as you pointed out earlier, what rails is good at.
• awongh 2y ago
  I like the rails dev experience, but it feels like they haven’t come up with nice new front end solutions that an integrated framework like nextjs has done. One specific example is images and srcset. If you are doing a react front end anywhere in your app (not even an SPA) interfacing with the asset pipeline doesn’t have a canonical solution. This just makes it feel behind the times, since what I always liked about rails was the “one right way” that was always reasonably sane. So it feels like nowadays you need to trade user functional front end app things, like load time and LCP for dev experience in rails. Sad.
  • theappsecguy 2y ago
    I mean the Rails way would be Hotwire. It’s dead simple and a joy to program.
• pjmlp 2y ago
  As someone that used AOLServer, was in a startup doing something like Rails but in 1999 with Tcl, I don't really agree. The Rails demo wasn't that appealing to me, other than showing the difference on how lucky one might get regarding adoption and spotlight being in the right place. Nowadays I still don't see a value, and rather go for Spring or ASP.NET. By the way, the founders of that Tcl based startup, went on to create OutSystems, which is one of the few successful RAD tools for Web development at enterprise scale, and Portuguese success stories in IT world.
  • ridruejo 2y ago
    Tcl for web development was great and AOLServer ahead of its time
• gardenhedge 2y ago
  I disagree. Rails is fine but just a differential approach. I prefer a standalone fronted that talks to an api layer. Web Frontend for me is remix. Mobile is react native and api layer could be any language you're productive in, eg. Java,.net or javascript.
• tomwphillips 2y ago
  I agree. Unfortunately every team I’ve worked in hasn’t seen the light and prefers FastAPI/SQLAlchemy/Pydantic (before FastAPI it was Flask). My theory is that the initial learning curves are different: with FastAPI it’s quick and easy. You barely have to read anything. Django has a steeper learning curve. There’s a lot of reading involved. Type hints aren’t a big thing in Django, but they are in FastAPI, and the average full stack dev seems to like them. Later on it’s totally different of course. With FastAPI you’re building it all from scratch, and it’ll be much worse than the Django solution.
  • allendoerfer 2y ago
    Type hints are were the whole Python ecosystem is going, so using them is more integration at a deeper level than using an integrated framework, which is not relying on them. SQLAlchemy was historically a much better ORM than Django's. It's layered architecture combined with Alembic does make a difference. I still agree that using the integrated thing anyway is probably the right way to do it if you are working in a team. I also think Django should just adopt these components and we would not have the discussion in the first place.
    • jonatron 2y ago
      I think SQLAlchemy vs Django ORM was a 2007 blogging topic: https://www.b-list.org/weblog/2007/sep/04/orm-wars/ https://www.b-list.org/weblog/2007/sep/04/orm-wars/
      • allendoerfer 2y ago
        While it is not Django's responsibility to unite the Python ecosystem, continuing to rely on a tool a sizeable share of the community deems inferior to a popular alternative will keep these discussions open and results in the fragmentation OP is talking about. Now of course it is not Django's responsibility to unite the Python ecosystem in the first place and they can value other factors and arguments as they see fit. Although this very thread shows that there might have been something to it.
• Volrath89 2y ago
  Dotnet is also very good for building web apps, it also includes static typing and a huge ecosystem. I agree that web dev is basically a solved problem, I don’t know why stuff like next.js exists
  • phist_mcgee 2y ago
    Some people like writing typescript. This forum leans backend heavy and there's definitely a bias against using javascript on the backend. But many top websites use it for their infrastructure. It's not all hype driven development.
• toastercat 2y ago
  I've been working on a Rails codebase for a few years now. The biggest downside coming from TypeScript codebases is that lack of static typing and the immature static typing ecosystem in Ruby. I know DHH publicly denounced strong typing, but if you're coming from a language with it, Ruby & Rails is a hard sell.
  • avaldez_ 2y ago
    There's some progress in typing ruby code. You may want to check https://github.com/Shopify/tapioca https://github.com/Shopify/tapioca
• timkofu 2y ago
  Django. Plus with Django and Py03, one can write the service layer in Rust(if you’re into that). It also enables building an interface to Python’s data tools.
  • pooingcode 2y ago
    I use Django and did a deep dive into py03 the other month seems straightforward to use. What use cases with Django would you say it makes sense to reach for?
• gepardi 2y ago
  “… the rest is developers wanking off …” Hahaha this made me chuckle out loud.
• shtopointo 2y ago
  Why bunch Node w/ Express together with the others and dismiss it? (genuinely curious). Rails has a high learning curve. Perhaps people working with it for years don't notice it. Node + Express seems faster to learn and ship, but my experience with Rails is limited.
• vr46 2y ago
  I just spent two weeks wasting my time trying to code my pet project in various flavours of Next.js plus Prisma/Drizzle etc and gave up at having to constantly reinvent the wheel or work around some incomplete/naive implementation. And then went back to Rails where everything just works. Etc etc etc
  • mattgreenrocks 2y ago
    It always sounds mean to say it, but there are definitely some things in JS land that feel way more amateur hour by comparison to more established ecosystems. Somewhat unfair comparison but I expect authors to at least learn from the mistakes of the past.
    • vr46 2y ago
      Reinventing the wheel suggests they're not even paying attention to the past, let along learning from it...