Hacker News new | past | comments | ask | show | jobs | submit login
I Miss Rails (chanind.github.io)
664 points by chanind 54 days ago | hide | past | web | favorite | 504 comments

> if the modern equivalent of Rails already exists, please let me know!

You're in luck. Rails 5.2.3 was released 20 hours ago.

More seriously, I feel rails is still excellent and I'm happy to work with it every day. I'd be interested to hear more about what makes rails not modern? I find it a very productive framework.

EDIT: If you're talking about missing a JS equivalent of rails, do you know about Loopback? https://loopback.io/

I know this is the opposite of what you asked but I find Rails to be keeping pace with modernity much better than its conemporaries! Django seem to have given up on integrating websockets (ActionCable has been in Rails for literally years now), nor is there trivial integration for JS assets/asset pipeline functionality. I don't write much of either anymore, but I'd still reach for Rails the instant I need to get something done quickly.

Django has multiple good asset handling libraries. I like https://django-pipeline.readthedocs.io/.

And with django-channels (https://channels.readthedocs.io/) Django goes way beyond just WebSockets. You can now do fully asynchronous data processing pipelines.

I'm still happy working with Django (which is not something I can say about the JS ecosystem). Especially when doing APIs with Django REST Framework.

Fully agree with you - been in the JS world a lot lately and it's not as polished as the more 'traditional' web frameworks.

Channels was supposed to make core but never did - what happened there? That's what I was driving at really - if I were stewarding a modern web framework, I would be integrating websocket support. It never sat right with me that something as common as APIs is farmed out to a library in Django (this comes out of the box in Rails with no configuration) either.

I don't dislike Django, but I certainly find that there's a lot more messing around to get done things that I would consider pretty standard. I used the new Rails beta last week and I noticed that Webpack integration is now there - how long until we see something like that with Django?

>Channels was supposed to make core but never did - what happened there?


Andrew Godwin (creator of django-channels) has recently handed over the repo to other maintainers and moved on to some role on adding `async` support to Django Core. (Channels was officially adopted by the Django project, but isn't part of the Django-core — you still have to add the package separately.)

This async support is hopefully coming within 2019. I'm super-excited about using it in future django projects.


In short, the efforts are constantly undermanned, leading to developer burnout. Andrew had since came back to pushing things (ASGI 3.0 came out last week), but it seems like he intends to focus more on the big picture (standardise async web stuff in Python) than spending time on Django specifically.

Step up if you believe you have good visions on making Django a “modern web framework”.

Django channels sounds like a great idea and I really like the conceptual step it made with ASGI, but in practice I found it to be riddled with problems.

For instance, the posix IPC implementation of ASGI is very buggy and "not officially supported". The other implementation uses Redis (so, yet another component to take care of) and is quite brittle as well. We've noticed severe slowdowns of downloading images when using the Daphne web server in development mode, many issues running out of memory, clogged queues and so on. This is also very difficult to debug, due to the many moving parts, and of course it only happens on production, so good luck trying to reproduce it locally.

For this project (which is still in production), we ended up falling back to a standard Gunicorn web server setup using traditional WSGI to handle regular HTTP traffic, and relying on channels only for websockets. For new projects, we've moved to a tiny standalone gevent-based websockets server (https://pypi.org/project/high-templar/) which we deploy next to a standard gunicorn stack. It is much simpler and much more stable. Unfortunately, it's something we've developed in-house, so if there are issues we have to fix them ourselves. There've been some problems with gevent which apparently have been fixed in the latest git repo, but there hasn't been a release since last year. So many issues....

In Rail 6 webpack (with a framework integration via the webpacker gem) is the default system for handling JS, CSS still goes through the asset pipeline though. I wouldn't be surprised if Rails 7 drops sprockets entirely.

And I have been wondering why it doesn't push the CSS to Webpack as well. There is no way in the foreseeable future that Rails could do without JS and hence Webpack is mandatory. We might as well push it as default or easily enabled / disabled via options.

It's clunky to build CSS 'packs' and it's unclear how to wire in asset helpers e.g. checksum'd file names for images. It's not insurmountable, but there is no obvious best path forward.

I saw this! It makes sense with the proliferation of front end view layers so I'm pleased that there's less work for me to do to integrate things like Vue and React. I was very late to the party with Rails but I do think it gets a lot of things right.

There may be packages in the community but the entire point of the article was highlighting the advantages of having framework level choices that 1. Are maintained by the framework team, 2. Establish patterns where the community can build other packages based on those assumptions. For example, now that yarn and webpack are standard in rails, we can build gems that can import and configure JS packages in a consistent and modern way, knowing exactly how most rails projects will manage JS. I have been frustrated that rails doesn’t have default admin, authentication, and authorization for this exact reason.

On the php side of things, Laravel is doing very well and is very "rails-esque".

Heard of Laravel, it's a Rails fork right?

Laravel is definitely Rails inspired, but also takes inspiration from a lot of other frameworks (CodeIgniter, Symfony, .NET, etc).

I was just teasing, Laravel looks solid. It's also comforting to know that if you move from Laravel world to Rails, a lot is familiar out of the box. It's good for us developers and good for the industry. Which I can't say about js stack/elixir/Golang/Spring etc etc.

Laravel doesn't follow semantic versioning and more important they are sloppy about backwards compatible changes been documented anywhere.

Symfony 4 however is wonderful, they modularised everything, kept backwards compatibility, properly deprecate things and it's fast, like really fast.

Laravel as of > 5.5 (5.8 is current) does not release breaking changes in point releases.

Yes they don't follow semver but a modified version of paradigm.major.minor

Interesting. I always found Django so much more productive than rails due to the auto admin panel being out of the box. If I’m starting something new than its nice to have a place for non devs to enter data immediately.

Both do quite a bit better for cleanliness and setup time than any of the other platforms I’ve used for web development.

You can easily generate scaffolds with rails that take the place of Django's admin.

Its also a really good way to see that your data is working correctly.

I'm interested in hearing about applications successfully using ActionCable for what and how. It's unclear to me how much use it's getting, or how well it meets actual use cases.

ActionCable is super easy to use out of the box to get WebSockets running, but it's incredibly non-performant. Anything more than 100 concurrent users took the time taken to a send a message to the socket from milliseconds to seconds. Replacing it with the AnyCable gem in conjunction with AnyCable-Go got us to over 1000 concurrent users without a hitch.

Is Redis the bottleneck?

Nope it was Ruby / Rails itself.

Was it an issue with Passenger and the number of concurrent connections it could hold?

I just deployed ActionCable into production yesterday. I’ll be using it to share some information between our users’ mobile app and our web client.

I’m concerned about performance. As much as I know that premature optimization is the Devil, it’s hard to stomach deploying something that is so notorious for becoming a bottleneck. Once I get past my MVP of this feature and have some maintenance hours budgeted, I plan on exploring AnyCable.

> nor is there trivial integration for JS assets/asset pipeline functionality

...WHY would anyone ever want that?! I thought that splitting an app into one frontend-app and one backend-app, each in its separate repository too and runable alone is the very minimum everyone does nowadays.

(Yeah, later you may go on and chop the backend into microservices, but for starters you at least keep these two sepratate - why would you want to impose knowledge of Python or Django as requirement for your frontend developers?! Even if you start with a couple full-stackers, you'll want to later be able to hire more narrow focused specialists.)

> as requirement for your frontend developers

It depends on how big your project is. If you only have one developer it's fine to have to it tightly integrated.

for websockets, django has django-channels https://channels.readthedocs.io/en/latest/ . But I do agree, django has been a little late to this party.

What happened to bringing this into core? Last I was using Django that was the next big integration and it just sort of faded away.

Andrew Godwin (the main hand behind the push) burnt out and halted all development until he can find someone someone is willing to help.

There's a team of 3 now maintaining django-channels, including Carlton who is paid by donations to Django Software Foundation:


Serious question: Django doesn't even have lazy loading. Why do people use it? Am I missing something? No way I'd wait a few seconds to get something big from the db

What are you referring to?

Lazy loading in Rails tends to refer to how Active Record waits until access time to send the query: https://rubyinrails.com/2014/01/08/what-is-lazy-loading-in-r...

It's still synchronous.

Django has this type of lazy loading as well: https://docs.djangoproject.com/en/2.1/ref/models/querysets/#...

Yes it does, the problem seems to be that no one bothers to learn how the ORM works.


I work on a hybrid React-on-Rails application and working on the React portions is so. fucking. painful. Seriously the shit people come up with with this "tool" makes corporate-hack Java programmers look good. I am always taking the backend Rails-y tickets if I have the chance

Blaming complexity on React is a bit like blaming complexity on ERB. The problem isn't React, the problem is the massive hole where React doesn't have an opinion. React improves the area around the hole so much that the technologies we use to fill the void look obviously deficient in comparison.

This is actually the bane of JS community's existence. JS developed so fast and so wildly that there was never a breather to form and write down best practices or opinions. This is jarring to someone coming from the Rails world where a lot of magic is happening, there are strict opinions (heck, it's in the subtitle of the copy) and strict conventions to adhere too. JS is wild west compared to that.

This is not to say that JS is shit but both JS and Rails have their place. If you want flexibility, you need JS. If you want iteration speed and dev productivity you need Rails.

I don't understand. One is server application development, one is client development. They are two vastly different things.

From this hot take on JS, I'd think people are suggesting that the development experience of all the other available clients are a lot better, but then I became an Android and iOS developer and that's not true either.

Swift isn't bad, but the language isn't the only thing that dictates how hard client development is. I'd rather use React than UIKit abstractions, that's for sure. And CoreData is probably the worst and most outdated abstraction I've used across all platforms. And even if I think iOS development is the ideal way to write software... it only runs on iPhones and iPads.

I mean, of course the Rails side of your application is probably nicer than the client side where you get to stay in your simple request -> response realm that runs on the same machine. If given the option, I bet almost every HNer would rather be the person paid the same to build the API endpoints vs the crapshoot that is client and UI development.

But I see this perpetually confused as Javascript vs <my favorite language I use on the server>. For example, Ruby fares pretty poorly against Node if you forget the client, like Sinatra vs Express/Koa.

I think we're diverging. The mental model of a Rails developers is well formed and if you're a beginner then you can rely on a very strong community for opinions, best practices and conventions to follow. This greatly decreases cognitive load and immensely improves productivity.

When you make a jump to a JS stack (whether client side or server side) you have a lot of options but no best practices or conventions to follow. You have to make a lot of choices which have already been made for you in RoR. Even though SPA frontend dev has settled between React and Vue, you still have to make a lot of decisions. React also bills itself as a view library. You have to make decisions about state management (if needed), routing etc etc. A vast chunk of these decisions are made for you in RoR so that you just work on the app. I think this is what the author was lamenting about.

People REALLY underestimate how much those opinions help when it comes to software development. If you start a project or new feature and your team is going to have lots of opinions on how something should get done. It’s typically easier for people to ingest the idea that something is “best practices” than have to follow whatever someone in the room is saying.

If the platform is too unopinionated you will generally wind up with: 1) A project with many competing ideas (most js projects I see end up like this) Or 2) A team with some people feeling like they are not heard

Ah, I see your point. I definitely was that beginner that was originally compelled by the ease of Rails. I would watch RailsCasts for fun and be amazed at how much you could do with so little. I thought it was the ultimate developer experience back then.

These days I prefer building something up from microframeworks and I like to take the opposite side of the trade-offs you mention in your comment. There are a lot of aspects of Rails I ended up really disliking over time.

But at the same time, I still find myself thinking back to some of the pleasantries that Rails gives you and wishing I had them in my bespoke applications. Even just things like being able to enumerate your routes from the CLI or seeing your SQL queries and query response time in the terminal during development. If it's something you have to implement yourself, you just tend to not do it at all. And there's a lot a framework can do for you with some opinionatedness.

I think the classic example of this realization is when you deep dive on microframeworks, accumulate them in production, and encounter things like performance issues but realize you don't even have the tools to debug them because you didn't build them.

Rails was somewhat unique at its birth with its opinionated-ness. Outside of that world, in "respectable" programming environments with smart people who were good at algorithms and O(n) notation and all that (which was not me) it was rare that I encountered the kind of insanity that I seem to run into daily with PHP and later JS.

Agreed, though I use Django. Two Scoops in a great book for going from someone who knows how to use Django, to knowing how to use Djnago well.

> “...JS developed so fast and so wildly that there was never a breather to form and write down best practices or opinions.”

js and ruby were released in 1995, with rails coming 10 years later. so js development wasn’t fast in the least. after the little ajax blip resulting from outlook web access’s release in 98, js stagnated until node came along and made it interesting again.

prototype/jquery a little before it and later front-end frameworks like backbone, ember and then angular helped cement js as a thing. it only seems fast and wild because the ecosystem really only woke up again in the 2010s.

(i tooled around with js on netscape right after it came out but then lost interest)

JS may be released in 1995 but it was not used much for anything except changing status bar messages, or image rollovers (remember those?) for at least ten years. Sure there also was Microsofts DHTML on IE, which failed to get much traction. Only starting with GMail and AJAX in 2004-2005 JS started to be treated seriously, it still took some years and SPA hype to become "a must". So about ten years max. Also Rails was constantly evolving since inception, alas, a lot of JS is revolving, i.e. solving the same problems over and over again, just with different approaches. The last point would be that people initially taking up Rails were not new to programming and usually switched from PHP or Java. Now Javascript is often the first (alas, often the only) language people learn. So I'd say the culture is quite different.

yes, agreed, ruby is a much friendlier language to start with, but javascript is more accessible since everyone has a browser or three.

while gmail brought a nicer ui/ux, i still credit ms owa for showing the world what js could be when it grew up.

Well of course js development is slow - you can upgrade Rails v1 to differently opinionated Rails v2 on a server overnight. Try upgrading 8 billion people to a browser that supports eg. ES6.

sure, but that wasn’t a problem 10 and 20 years ago when js development was even slower. the language just hasn’t evolved as much as others.

> This is not to say that JS is shit but both JS and Rails have their place. If you want flexibility, you need JS. If you want iteration speed and dev productivity you need Rails.

Not true at all. Rails can be extremely flexible; it's all modular and you can reduce it down to almost nothing if you want. Javascript's only place is to run in the browser; it lost its way once people decided to make a server platform out of it. JS is far too forgiving of mistakes to be running backend code, full stop. ES6 and up are vast improvements but the damage has already been done.

And in any case I have yet to work in an environment where I am not writing at least some ES5...

I'm not so sure about that... maybe I'm just old but React provides very little of anything compelling other than shadow DOM and databinding. It seems like every opinion it has outside of those two very narrow areas is INSANE

The funniest part about the enthusiasm for React masochism is that the best parts of the library are better accomplished with a combination of Turbolinks 5 and Stimulus. Not a coincidence that they're all Rails extractions.

For me, the more interesting question in all of this is where did this fervour for JS-and-the-way-down actually come from?

My hypothesis is that it's the natural result of a huge mess of new talent - fresh out of various overpriced Bootcamps and told that their 9-week educations give them a credible opinion in true post-modernist fashion - all being released on the world at the precise moment that a predictable police lineup of over-promised technologies were all at the top of their respective hype cycles.

Humans have a predictable tendency to assume that the thing they are thinking about at the moment is far more important than it actually is. If you have a very short institutional memory and everyone you know in your bubble has been programming for a relatively short period of time, pretty soon you can start to believe that if everyone is doing it, you couldn't all be wrong.

What purpose does it serve to take such an uncharitable view on other people?

This community is full of experienced professionals who use Javascript even in the face of alternative options, and we belabor this topic every day.

So what excuse do you have for assuming and hypothesizing that everyone must be an unenlightened boot camp amateur when you could've turned to anyone and simply asked?

For example, to me, modern JS is not substantially worse than other dynamically typed languages. Give me Python and Ruby code and the Javascript version probably looks the exact same. Meanwhile, those languages don't have a 1:1 version of `results = await Promise.map(urls, (url) => crawl(url), { concurrency: 8 })`. And that's not to start a language war but rather to demonstrate a concise example of a technical strength, aka a purely technical ground that a craftsperson could reach for that tool.

But now fold in its advantages like ubiquity, async-everything, runs natively in the browser, and has a static-typing system that's actually catching on, and it should be pretty obvious why someone could pick it when given an option beyond "they don't know any better."

Also, there's the obvious trade-off of treating your server as the API for all of your clients and treating the web as just another client that runs on the user's device instead of essentially coupling it with the server.

But surely these things are obvious or easy to find out, so it's hard to assume good faith in your post.

why is async everything a strength? I find it an unnatural way to think about coding, just like threading. Sure if performance absolutely requires it I'll start using threading, but why do it by default? A strength, in my eyes, is simplicity. What's simpler than a code that runs sequentially?

Node is single-threaded + async-everything which gives you simple concurrency with the async/await abstraction. It's these there things that come together to make building async apps simple. For example, I went out of my way to avoid Node before it had promises and async/await, and that seems to be the Javascript most HN users remember.

Concurrency in this situation almost becomes free at the expense of changing

    user = db.findUser(42)

    user = await db.findUser(42)
So when writing programs where you want more than one I/O thing to be happening at a time whether it's network requests or a bunch of concurrent workers, which is pretty much why you'd use Node, you get it trivially.

Even something like running parallel DB queries trivially inside an Express route:

    const [a, b] = Promise.all([db.findUser(42), db.somethingElse()])
Or starting one async early, waiting on another, and then ensuring that the first async thing is done later on:

    const a = runA() // returns a promise
    const b = await runB()
    return [a, await b]
And once again I think this is the a great example of a useful abstraction when writing anything with an I/O boundary:

    const results = await all(urls, url => crawler(url), { concurrency: 8 })
That code in Go would take me 40 lines and involve wait groups.

Compare that to Netty or trying to write async code in Rust where it's really easy to block the event loop because all libraries and stdlib are sync by default. So you're passing around a CPU pool to run sync code inside your async context. It's hard to look at that sort of code and understand its runtime behavior. Oops, you accidentally blocked. Oops, the pool gets saturated immediately and starts blocking. It's hard to straddle both worlds, and the code is constantly trying to "return to its sync default" so you have to be eternally vigilant. Sync isn't necessarily the default you want, either.

Of course, this comes with other expenses like needing to run one process per core and you can't do CPU-bound work in-process. But you may be used to that limitation using Ruby or Python for example.

I'm not trying to start a language war or tell you that you should drop what you're doing to use Node because it's The Best.

What I'm responding to is this idea that you couldn't possibly have a technical reason to use Node given a choice unless you're fresh out of a boot camp and know no better.

Node + Express is just fine for the same sorts of things that Sinatra is fine for. If you are more comfortable in JS than Ruby, please know that you have my full encouragement and support.

However, you are (perhaps unintentionally) twisting my words. I brought up bootcamps because I can demonstrate a strong causal association on a timeline.

The beef, such as it is, is with the 750k npm packages, the brutal moving target that is the packaging/transpiling/dependency hell/OCD bikeshedding that comes with a commitment to the JS ecosystem. And given that you used to be a Rails user, you know full well what giving up sane defaults in favour of the pursuit of pure compositional bliss looks like, but you're choosing to forget the trauma.

Meanwhile, there's an entire generation of new devs that have been told that Rails (or your favourite server side alternative) have been eclipsed by better thinking. I don't think I'm just an angry old man screaming at cars from my porch when I call bullshit.

Javascript is good for async code, still not sure why this is a great thing by default. It's nice when you want to write async code, do you always want to write async code? For most web apps I've seen you simply don't need to write them in such a way. Blocking IO will switch to a different thread in most ruby web servers anyway.

All that's nice at the language level in favor of JS, but it doesn't speak to the framework level of what all Rails offers compared to everything additional you need to add to React to be comparable. Same deal for some of the frameworks in PHP like Laravel or Drupal.

Comparing React vs Rails is like comparing an iOS app to Rails. I don't really see the point since they are fundamentally different, and whether your application should run on the client or not is a bedrock decision long before you get to "React vs Rails". Rails isn't even an option in one of the branches of that decision.

I assume you meant to instead draw a distinction between a large framework like Rails and a tiny one like Sinatra. And I'd say that ranges from a matter of taste to the composition of your team more than anything else. Obviously there are upsides and downsides to any point you can mark on the continuum.

I meant that if the Ruby community had an inherent preference for Sinatra-like frameworks such that Rails had the same status as Meteor or Sails does these days, then you would get articles by developers saying how they miss Django when having to reimplement a bunch of stuff in Sinatra that you automatically get with Django.

But you're right that I made an invalid comparison to React. It's more the starting with Node and having to add a bunch of functionality that you would get out of the box in Rails, because a front-end framework like React is the preference, and lots of developers would rather write isomorphic apps/sites.

It's difficult to convey context or background in these conversations, and they quickly become circular based on each participant's favourite default assumptions. For example, you're clearly excited about asynchronous, Promise-driven code patterns. I am preoccupied with developer happiness and ergonomics that come primarily as a result of opinionated defaults and a relatively stable ecosystem + build process. The simple truth is that if I needed results = async map -> crawl() in rb, I would call a service written in Go or Rust... but also, the number of times where I need to green-field a web crawler is dwarfed 250-1 by building the sexiest, snappiest CRUD UIs possible.

Meanwhile, there was once upon a time a perceived crisis of junior talent which led to the creation of the first code bootcamps, all of which were taught Rails, jQuery and Sass. I'm not trying to be shitty, classist or ageist in suggesting that the bootcamp phenomena suddenly started emitting a large number of blank-slate new devs that would understandably treat every exciting idea as the most incredible thing since <insert your fav noun>. After all, if you have few previous experiences, what can you compare against?

Previous generations of devs learned predominantly through either auto-didactic persistence or academic lectures; this new crop was suddenly predominantly learning from (and influencing) each other.

I recently read an excellent book called The Death of Truth, which technically has nothing to do with programming... except that in this conversation, it's totally about programming. If every coder's ideas are treated as equally valid truths even though there exists a massive gulf between their relative experiences, then we're confusing feelings with good engineering.

I think it's that, and the general accessibility of Javascript. Before this JS craze you saw the same shit with PHP and Visual Basic, though for the most part people weren't trying to build and rebuild the same platforms nearly as much as now

I know that it's 2008 calling, but seriously: when did Heroku, Github and the bundler/gem ecosystem stop qualifying as accessible? Deploying an MVP Rails app with sophisticated functionality is so effective that it still qualifies as erotic.

For me, the most compelling example of progress coming from the JS camp was my shallow investigation of the Expo platform for React Native. It has some genuinely sexy developer ergonomics features which I'd love to see make their way back into Rails.

I've been trying to learn some Rails and it's not that simple. People tend to say just read Hartl which is 804 pages according to Amazon. It may seem simple once you are familiar with a few dozen gems, action this, active that but there are a lot of bits to learn about.

I'd like to formally extend an open offer to help you or anyone else reading this to contact me for help if you're stuck learning Rails. Just reply with an email or some other mechanism and I'll follow up. If you have questions about best practices or you're just stuck on something, hit me up.

Hartl is great, has his/its place etc. Sometimes you just need a smart person with experience to add personal context. Happy to be of service.

Hi, if you are interested in helping people with their ruby/rails issues, there is also reddit / ruby discord / rails slack / and stack overflow. I'm trying to be active on Reddit and the Discord but not very active on slack/stack overflow. There are already quite a few people helping but more people would help :).


True, any 15 year old framework will have bloat. But Rails is absolutely skinny compared to Spring, ASP and fellows. Its probably easier than a MEAN stack also.

That book is long, not because rails is bloated, but because there are very in depth sections building things from scratch like authentication that in practice are solved by gems. They are important for beginners to learn but are rarely reimplement from scratch in rails projects.

I think the React props+context API for nested components, plus state management for updates, is better than partials in Rails.

It's not perfect by any means, but I think it shows the shape of things to come.

I think you mean virtual DOM -- shadow DOM is a subtree of the DOM supplied by browsers (like the handle of a range slider).

Not quite true - React confuses inputs with outputs by taking in callbacks as props instead of just emitting events. This makes shouldComponentUpdate very error prone, and memoizing callbacks to work around it is a mess. This is a large contributor to complexity and bugs in React apps.

Have you used Vue? From reading it appears Vue has an opinion many places where react does not, but I have built nothing serious in either.

As does Angular. That’s kind of its thing...full, opinionated framework.

That's a great observation -- one that's true of, say, jQuery too, which handled the problems of cross browser compatibility, over-verbose interfaces, and DOM manipulation so well that... we got to really take a hard look at the problem of doing everything we wanted by direct DOM manipulation.

Honestly, I just wish Rails had some degree of static typing (a la TypeScript.) As a Rails code base grows and patterns are required beyond the basics, it becomes a nightmare to tell what comes from where. You'd probably gain some mileage from that in your React codebase.

I've been meaning to revisit Kotlin's web framework offerings. I've used it in small doses for Android and AWS Lambda functions and, IMO, it seems to potentially be the best of both worlds; strict where it needs to be and flexible where it doesn't. I'm currently supporting a few Python Lambda functions at work and they feel very slapdash in comparison.

The biggest problem with Kotlin is also it's biggest strength: excellent interop with Java. This means that you can use all of the Java libraries...but that also makes writing new libraries in idiomatic Kotlin unnecessary, so you're going to get less of them, and have to use a lot of crummy old Java APIs.

Try Kotlin with the Spring Boot framework. I view Spring Boot as the Rails of the Java world and the Spring team has done a lot of work lately on Kotlin compatibility and idiomatic APIs.

This week I’ve been porting one of my Spring Boot apps to Kotlin and that was a great experience.

The only thing I’m waiting for is good reactive drivers for Postgres and then you can go with their new reactor based apis instead of the older one-thread per request Spring MVC.

+1 - Kotlin/Java with Spring is a totally different beast as compared to java apps of yester years.

This is a good point. I haven't used Spring in forever, so I don't know if/how it takes advantage of any modern Java features, but I could see Java 8/9/10 and (a framework like) Spring being pleasant and productive.

The Spring and Spring Boot teams have done a lot of work on this. IIRC Spring Boot 2.1 is compatible up until Java 11, and Java 12 support should be in 2.2.

Some API's are adapted to take advantage of modern Java features like for example JPA repositories that can return Optional<T> for single row queries and Stream<T> for multi row queries. Some API's have been improved with functional equivalents.

If you combine this with Kotlin you get all the power of the Spring framework together with excellent nullability checks and modern language features that Kotlin brings to the table.

Kotlin + Dropwizard is a great choice (or Spring Boot). I've used it in production and it's got the best aspects of Rails (opinionated) with the best aspects of a modern, statically typed language running on the JVM (need I say more?).

Static-typing seems so at odds with Ruby/Rails that I can't even imagine what that would look like.

I'm waiting for a chance to try out Crystal/Amber, which is type-checked (not sure how safe?) and can be pre-compiled like Go apps. It looks really close to Rails:


(I couldn't find any code snippets on the official Amber framework page, I hope this is representative.)

Crystal/Amber combination is such a joy to work with, it's too bad it's not more popular, I'm contributing a bit to the project sometimes and use it for personal stuff. I regret it's not that trendy because it's the best web experience I ever had.

Crystal is definitely type safe, I’d recommend taking a look at the Lucky web framework also written in Crystal.

Kemal is great, too. Though, IIRC, it's more akin to Sinatra.

Stripe has built a type checker for Ruby that they're using internally. I don't think it has been released yet, but you can get a preview of it at https://sorbet.run/.

So it's something along the lines of Erlang / Elixir dialyzer. I don't like it much (dialyzer) because of the verbosity and unDRYness. Every function definition becomes two lines and the name of the function is repeated in both. Type names are longer than they should and are separated from argument names.

We had a discussion about Ruby's type annotations 4 years ago at https://news.ycombinator.com/item?id=9481186

I found it by googling the status of the work on Ruby 3 type annotations. The top comment is mine and I still agree with the past myself.

It would ideally look pretty similar to typescript. There's actually a few projects adding typing to ruby, but they seem to be mostly trying to catch issues at runtime, which to me is pointless. Or the syntax is onerous, using decorators and/or separate type definitons.

I'd be really interested in a typescript like superset of ruby, and I've even thought about building a prototype of it, though it's quite outside my area of expertise.

I don't mean the syntax, I mean the abuse (ostensibly a language feature) of method_missing that's incumbent in the ecosystem. What would be the type signature of Active Record?

Aren't your ActiveRecord models basically the only place in a Rails app where you do specify the types of your properties?

I'm referring to things like dynamic find_by_* messages since more people might be familiar with that.

But I don't know why you'd say that. ActiveRecord models are one of the main places you'll see a bunch of `use SomeGem::Thing` that introduce a bunch of magic methods on model instances.

And my point is that we aren't talking about method composition here that you can statically analyze with a bolted-on type system. Ruby's metaprogramming runs so deep that it's a substantially bigger challenge than other dynamically-typed languages.

One clue is that humans even have a hard time with it. The first shock that people have with Ruby is when you see a method or identifier and grep shows up with zero results.

Aside, I can kinda tell that Ruby is entering Perl territory when there are no beginners around to chime in with their gripes.

The magic stuff's awful. Any time you have to dig into a mothballed Rails codebase from a version either older or newer than what you're used to, or with a bunch of Railsy magic gems that aren't in your usual toolkit, it's hell. I'd rather let the computer tell me what stuff is and where it's defined than memorize a bunch of magic prefixes.

I only say that because it seems like low-hanging fruit. If I have a class with a random @ivar that's added inside a random method, there's nothing up-front to check against. An ActiveRecord subclass at least has a database schema to validate against.

I am a beginner. I don’t know enough to gripe, I bet that’s a common feeling among beginners.

Have you tried elixir?

That's more a Ruby issue than a Rails issue.


Stripe have been working on a type-checker. No idea when they're going to release it to the public though.

We are doing Rails/Vue. Both sides are pleasant to work with. I prefer working with Vue, but don't see any reason to remove Rails from the backend.

(but yeah, ActionCable was a no-go. We use Pusher instead)

I truly agree with you. I absolutely love Rails and what it has to offer, ever since working with it since Rails 2+. Truly one of the best bet I've ever made!

Try this out: https://github.com/jho406/Breezy, its a library i wrote that makes working with the React/Redux portion feel like a classic Rails app. Its inspired by turbolinks and doesn't require APIs to work.

> If you're talking about missing a JS equivalent of rails, do you know about Loopback?

I would not go down that route, because at least Loopback 3 looks promising at first, but after a while it does not scale dx-wise. The biggest trap my team fell into, was that you could „include“ related models in a request, that you did not have permissions to. Media management was also very poor and did not integrate well into the whole eco system.

We are now using TypeORM[1] and routing-controllers[2] which has been very nice so far. I have been building my own framework at work on top of these and it safed us a good chunk of time. If you want to have a look, go to my profile, I have put a link there.

[1] https://typeorm.io [2] https://github.com/typestack/routing-controllers

LoopBack 3 was terrible - complicated, added no value, encouraged creating vulnerabilities, had lots of obvious vulnerabilities in official components. LoopBack 4 looks pretty different, but I wouldn’t trust it to be good unless the entire team and philosophy behind it has been replaced.

I've been using LoopBack 3 in production for 18 months.

> added no value

It gives you an API explorer, routing, ORM, validation, error normalization, authentication, authorization via ACL, and more out-of-the-box. I'd consider this value.

> had lots of obvious vulnerabilities

I'd like to know more about this. The only thing I can think of is bypassing ACLs via fetching records and including relationships. I don't know of any framework or combination of libraries that doesn't have this vulnerability.

> LoopBack 3 was terrible - complicated

This is probably true. LoopBack 3 essentially uses a single model to represent your API and data model. This is the single responsibility principle taken to the extreme opposite. It's a complete nightmare at times. If you have an exact one-to-one mapping of your API to database, this may not be a problem.

> unless the entire team and philosophy behind it has been replaced

Loopback 4 seems to be the same team, but I believe they have learned a lesson on coupling. https://loopback.io/doc/en/lb4/Crafting-LoopBack-4.html

> Models are overloaded with multiple responsibilities, such as data representation, persistence, and mapping to REST.

They have a way to go to reach feature parity with LB3: https://github.com/strongloop/loopback-next/issues/1920.

BTW, I also miss Rails.

Or try Kemal with Crystal. Kemal is very Sinatra like. And Crystal is very Ruby like but it's compiled so it's much faster.


Have you heard of FeathersJS? It is more akin to rails, supports many databases (neo4j, postgres, mssql, etc), runs on plain node.js, offers soa lifecycle hooks like rails, websocket/realtime support ootb and graphql via third party libs. https://feathersjs.com/

Let's say the last time I really worked on anything Rails related was 2011-ish, and while I got stuff done OK, I never really particularly fell in love with it (and in fact was often annoyed that most projects I worked on seemed to start with a week of hacking through environment and gem snarls).

Where would people recommend I read about (a) getting up and running with rails 5 and (b) appreciating what's new and improved in the last 8 years?

I use RVM and create .ruby-version files for every single project I touch. Occasionally I'll let more than one project share a Ruby version/Gemset combo, but often I'll make sure each is unique.

No need to "bundle exec" anymore, because simply cd'ing in and out of project folders resets your gems to a clean list only required by that app. It's great. The years come and go and I still hear people complaining about Ruby version and gem hell and I wonder why the heck they aren't using RVM!

A lot of things improved but a lot of things stayed the same. Rails is like oysters - not for everone...

Try looking into Nuxt which is built on Vue. Docs could be better but once you figure out a few things I found that you can be highly productive. But it's strictly a front end tool. Some guys use Laravel on the Backend but I'm partial to Taffy.




Sails.js [1] is a good JS equivalent of rails.


I worked extensively with sails.js about three years ago and it was an unmitigated disaster. The ORM has about 1/8th of Rails' functionality and queries that would be trivial with Active Record were a nightmare. On top of that the community was a mess and around the end of that time, a lot of the core maintainers dropped out because there was so much in fighting.

Unless there have been some major changes I highly advise staying away from sails.js.

It's been about four years since we touched it. When we used Waterline (the Sails ORM), we discovered two distinct SQL injection vulnerabilities in it, without intentionally looking. I would link the related issues, but they seem to have disabled Github issues in the waterline repository[1]. That--and lots more--scared us away. We switched happily to Hapi[2] with about a week of work and never looked back.

1. https://github.com/balderdashy/waterline

2. https://hapijs.com/

The major stable version came with a lot of improvements. I'm not saying sails.js is the best option for a big project, but is pretty decent for prototypes and fast development.

Related: https://dev.to/imthedeveloper/comment/2615

That was the promise. The reality is sails never really took off, fighting within the core team derailed development and fractured the community, and its opinions are so poorly documented that you basically have to learn it from reading the source. The founder will occasionally chime in and say that it's still alive, and his company has great success using it, but unless you are one of the core maintainers I doubt you will have a similar experience. There are very few people that have used sails in production that would recommend it. The author is undoubtedly a brilliant developer and light years beyond my own skill, but that does not matter when the community is tiny and bugs never get fixed.

I haven’t used sails in production, but I have tried in on a side project and it definitely was a disaster. We just started using Nest at work, which is a TypeScript framework that feels sort of like spring. It’s been nothing short of great, and typeorm is BY FAR the best orm in the node ecosystem.

Did you try it or maybe even use it? I tried Sails a year ago but the learning curve felt really steep and it wasn't super popular at that time :(

I used it in production for 2 years w/ MongoDB and it worked fine for fast development. At the time the main knowledge resource was the Manning book "Sails.js in Action".

>More seriously, I feel rails is still excellent and I'm happy to work with it every day. I'd be interested to hear more about what makes rails not modern?

The whole thing he explains in the post: he wants an all-rounder like Rails but which covers the SPA/JS side.

I think many of us have realized that the SPA, which introduces an entire second application into your stack, isn't that cost effective. I'm more interested in turbolinks and if absolutely necessary, maybe something like http://instantclick.io to get an 80/20 payoff.

For folks here doing startups, imagine the speed boost of maintaining one less entire application than your competitors.

Turbolinks and some dirty jquery here and there is all I really ever needed.

Everything more than that just feels to much like having multiple code bases.

Speaking of JS, do you guys have a suggestion for good SQL querybuilder and maybe a migration tool for Node? I prefer to do everything else by hand or use smaller libraries.

Not that i don't know how to write SQL queries by hand, it's just raw SQL queries with conditions is just ugly.

Knex is really nice. I use objection which extends it for orm stuff. The insert graph features are pretty neat. I definitely don’t use all it has to offer.

I've been satisfied with Knex.js. It handles query building, transactions, connection pooling and migrations


I'm using sequelize with an SQL Server database, it's decent so far. I do migrations by hand with a custom __migrations table.

I really like TypeORM (for Typescript projects) & Knex (for non-TS projects)

Have you heard of AdonisJS? It is more akin Rails/Laravel than anything else before it. https://adonisjs.com/

I love Rails. I also like React. What I really miss is an easy way to connect the two - a Gem or a generator that connects models on Rails, through REST API endpoints, to a front-end state management library (Redux or MobX).

But I suppose that DHH got burned with Prototype and then CoffeeScript and wouldn't endorse something like this.

I think what the OP meant by 'modern,' was an equivalent of Rails that uses the technologies demanded by the tech industry today. On the one hand, the industry went to Python because a ton of data science libraries were written in that. On the other hand, React ended up real dominant on the front-end because of all the sh*t code people put between HTML JavaScript tags. Another route, is any promising asynchronous and scalability like Node or Elixir. So these divergent vectors make something like a Rails that can serve the needs of big data, snappy UI and scaling while at the same time using the team we've got super difficult. The needs of the industry have created an oblivion of the solution that was always already there, Rails.

>demanded by the tech industry today.

That attitude needs to get out of everyone's head. You are the tech industry. If you want to build something in Rails, a mature and capable framework that has tons of support and won't go away, just do it. Who's going to stop you? Applies to any other technology that's stable as well.

The Whims of a Fickle Manager.

The trouble is "we," the developers aren't the tech industry making the decisions. The managers, who once were full time developers, are making the decisions. I can say hey let's use this stable, mature tool, but which catches enthusiasm more? That or the guy drooling over React and all the complex mystery JS libs saying it's the best thing ever?

And/or the poor PHB falls prey to the sales pitch of "if you rewrite it in fad.js, you'll save tons of money".

Yup - unless The Tech Industry is going to come in and rewrite all our code into Flavor Of The Month (and do that every 3 months forever) I don’t really care what they “demand” - I’m too busy providing value for my customers to be shaving that yak

> these divergent vectors make something like a Rails that can serve the needs of big data

So, Python has the ton of data science libraries, and it also happens to have Django...

And now I’m seeing more when more migrate to Go.

I actually have gone back to writing server-rendered apps like it's 2012 and it's been wonderful.

Server-rendered used to mean slow and clunky but I've found that using Go my page loads are super fast. The inter-page transitions can sting a little on really really slow connections, it's true. But users are much more willing to deal with them if they haven't first been subjected to a minutes-long spinner while the SPA loads up all its libraries and state.

A little game I sometimes play is asking fellow developers to try and guess the frontend framework used on one of my apps. They click around for a little while wondering "Angular or React" before I tell them it's actually just some Go templates rendered on the server. It often opens their eyes that the loads were so fast they couldn't actually tell they were happening.

SPAs have their place and I've written a lot of them. It's amazing how far you can take server rendering in 2019, though.

>Server-rendered used to mean slow and clunky

I don't get why everyone keeps saying this. Is it because of WordPress? In 2005 I used my own MVC framework with ORM and stuff. It was written in PHP. My pages had the usual generation time of 0.03 seconds. And that was with no specialized caching or any crazy optimizations. Even with no AJAX, page loading seemed instant, unless you connected to the server from across the world.

I completely agree. In 2008 at my first coding job we used plain php/MySQL with no caching and the sites were responsive. Plus they required like zero maintenance! In 2009 I went to work for a Django shop and was introduced to caching, reverse proxies/wsgi servers, templating, etc. It took a long time to buy in to this way of doing things, as it seemed intentionally complicated for no reason. Over time I've learned to appreciate that there are real benefits, but it wasn't immediately obvious to me. Regarding js templating, spa's, and all that stuff: I've tried to keep my previous experience in mind, and be open-minded about the potential benefits of these technologies. But I haven't seen any as yet.

Serious question. What's wrong with simply having a static directory from which you send html files to the client? I do that all the time with my servers and the load times and the complexity of the project never seems to get out of hand. When the app needs to be highly interactive, I perform simple fetch requests and DOM updates from JS. Am I missing something here?

You (and most web developers out there) don't work on projects that actually need to be SPAs.

the lighter text means the post has been down voted correct? Why was the parent post downvoted then? They make a perfect point, there's nothing inherently slow about traditional web apps. There's definitely things regarding the UX that traditional server side web applications can't do vs browser side but they can be incredibly fast.

one nit pick, what does "server-side rendering", and even "client-side rendering", even mean? The browser renders HTML, it's always client side and it's always outside of the scope of application code. Does "rendering" really mean template parsing?

Server side rendering means the server converts a template into a fully formed html page by pulling layouts and partials together, adding JS/css assets, interpolating dynamic sections with data from the database. The response to the browser is html ready to parse and display.

Client side means the layouts, templates, partials, components are on the client and are stitched together their. The server only send data and the client app handles interpolation and generating the html.

>one nit pick, what does "server-side rendering", and even "client-side rendering", even mean? The browser renders HTML, it's always client side and it's always outside of the scope of application code.

This is an excellent point. Both HTML and JSON are string representations of data structures. Both are eventually transformed and converted to DOM.

> Does "rendering" really mean template parsing?

It's kind of a misnomer; it usually means generating a "renderable" thing (e.g. HTML) , not actually rendering it on the screen because yes the browser does that.

How many "quality of life" features does your website have that require some JavaScript that you end up writing as one off functions/endpoints/etc? (various kinds of autocompletion, live search, notifications, messaging, etc.)

I'm all for server side rendering - I maintained several vanilla PHP/HTML/CSS websites in the 2000s, and only used jQuery sparingly when things grew in complexity. I later used Django for many years similarly, and when react/ember/angular/etc. started blowing up is when I started feeling like performance was something we had to worry more about.

That being said, server side rendering shows its limits when you build an application with lots of actions your users can perform on the data shown in their window, and reloading the page every time would significantly slow them down. That's when you're tempted to start going the SPA route, but those frameworks tend to be pretty opinionated about how you should structure your code and data, a slippery slope that leads to the stereotypical bloated, unresponsive JavaScript mess some websites have become famous for.

There is certainly a balance to be found, but it's a tricky one.

It depends on the application of course, but some of them do end up sprouting a bunch of little "quality of life" JS functions. Writing these is happily a much simpler experience than it was in 2012! The most complex app I run also has the deepest browser support requirements, back to IE11. That said, I still have document.querySelector in all my target browsers so I find I don't even need jQuery.

For autocompletion, datepickers, etc I use drop-in components. These tend to be jQuery based but it's not the end of the world.

When I do have a particular view or flow that outgrows the "bits and pieces of JS" phase it's actually pretty straightforward to use a modern UI library like React or Elm on that view alone. Reducing the scope of the area you're using the framework in rather than writing the entire app in it simplifies things pretty dramatically. The JS doesn't need to worry about routing, pushState, etc etc etc. It just deals with its own little patch of DOM and state.

I haven't developed any website but my server-side preference would definitely lead me to something that is always server-side-rendered. It's no surprise we all like HN, the experience definitely feels more than good enough.

There was a standard (https://tools.ietf.org/html/rfc3229) to diff pages so that only the delta would be sent to the browser. After that the only missing piece would have been that the browser doesn't refresh the whole page but intelligently re-renders the difference in the DOM, and that would have been the perfect world.

I'm really only familiar with ASP.NET, but do other frameworks not include support for partial page rendering? The ASP.NET `UpdatePanel` is simple and even has gracious degradation. (If client doesn't support for whatever reason, it will just revert back to doing full page POST and refresh.)

Of course, this is just wholesale replacing a DOM subtree with another. But there's also probably some point where just parsing the new subtree is faster than attempting to create and apply a diff.

Just because you have some interactivity doesn't mean you have to jump to an SPA, vue/knockout work well in the hybrid scenario and then you only have the complexity where it makes sense as well.

I can recommend Mithril, which can support a full spa but is also very practical if you just want small parts of the page to be dynamic. It is a great little component based spa library that is small in size and has a simple api. It is very similar to react and doesn't require a compile step.

Libraries like IntercoolerJS really help with page transitions and other dynamic interactions, while still letting you do all the rendering on the server.

Also https://instant.page/. It preloads a page when the user hovers over a link.

I like intercooler.js a lot!

SSR + Pjax + React on the components that really need it seems like a much-simpler combination to me than what seems to be generally considered 'state of the art' these days.

This is where Elixir and Phoenix really excels. It just renders pages so damn fast!

Are any of your apps public? I want to try using them.

"takehome" seems like exactly the right solution for technical interviews. Have you gotten much traction?

Thankyou, I think so too.

I find that once a company uses the product, they never stop. The customer base is very sticky.

I have also found that I bounce a lot of companies that don't "get it". They don't understand that it's about making things better for candidates and so all they see is Hackerrank with less features.

My challenge for growth is finding better ways to explain the ethos and the benefits to those companies.

Why miss it, come on back, the water's still warm and the dev is still as fast as ever in Rails. Honestly, the JS stacks all seem vastly more annoying on so many levels.

It seems like the JS ecosystem changes so fast because it knows better is possible, so it just tries to reinvent itself over and over.

The JavaScript world starts with this weird prototype based language with a syntax that looks like it might be something more class based. From there it goes to dependency bundling hell, callback hell and Christmas tree code indenting, no standard implementation, and a library required for everything under the sun (Left-pad!) And somehow this is what the cool kids are into? I never liked Rails because it was "cool" I liked it because I love getting stuff done, fast.

JS is not my first choice for many things but I still have to work with it often enough to know that most of your complaints about the language haven’t been a problem for years. It’s improved a great deal and is much better to work with lately—more so if you don’t install a library for everything under the sun (because you really don’t have to in order to be productive).

There are valid complaints to levy against the ecosystem, but the ones you listed are non-issues if you take time to learn the language and VMs/environments themselves. To be fair, I mean.

> complaints about the language haven’t been a problem for years.

If we're being fair, what you say is true only if you are starting a greenfield project.

You could be right about that.

I don't use scaffolding [if I can help it]—unless it's some I've set up and maintain myself (if I know I'm going to do a run of similar projects).

Normally I only do greenfield projects as their architecture and maintainability are highest priority due to the need for longevity. Plus I often find those systems rather heavy-and not just in JS.

Oddly I never considered starting a new project with it, but now I'm questioning why that is. I guess I just don't see many new projects started in Rails, and nowhere I've worked the past few years uses it. I stopped using it after Rails 3, but I'll give it a try again in the next side-project I work on and see how it goes.

> why that is

We as a profession seem to be perennial victims of availability bias.

We're naturally going to think of the stuff we've been reading about lately on the Internet first. Which is just never going to be the established and stable stuff that'll let you get your job done without producing any blog-worthy experiences in the process. "Went home after 8 hours without producing any fodder for war stories" doesn't make for an interesting tweet, let alone post on Medium.

Server side rendered is still fantastic for the vast bulk of web apps. Turbolinks and a bit of care around performance and all you users know is you have a fast site. Not many apps really need the super rich SPA type experience.

This. And it takes a LOT of work to emulate everything browsers give you for free on server side pages (caching, back button, reload to continue on connection loss ...)

And you can take this approach to the next level with Phoenix LiveView that’s in its testing phase right now. Server rendering is so fast in Phoenix that it had a lot of people clamoring for a turbolinks-like solution to the problem.

It’s not perfect yet, but as a first version is remarkably capable already.

I heard someone on the ruby rouges podcast say they got turbolinks to work on Phoenix pretty easily.

Honestly I have stopped trusting 'the herd' as a metric as it seems we programmers are more enticed by shiny things than practicality or excellence in engineering

Rails is used heavily even for new projects under the GOV.UK umbrella. The emphasis on accessibility and usability of government sites/applications weigh in favour of more-traditional stacks.

Also Bern.ch/be uses quite a few rails apps. (but also django and PHP)

> It seems like the JS ecosystem changes so fast

Does it tho? React, Webpack, Babel and TypeScript have been around for a while now, and I can't think about anything else more recent that had a similar impact on the JS ecosystem.

Almost half of my job is just updating these JS libraries because they reinvent everything or get replaced by other libraries constantly.

Awhile back I converted a React app to pure JS after noticing that most of the commits for the last year had been updating as the slew of libraries it used had incompatible releases. The code size went down, performance went up, and you no longer needed a 300+MB toolchain just to load it.

Vue? Yarn? Angular 2?

Angular 2 has been around since 2015.

According to wikipedia, the final version of Angular 2 was released on September 14, 2016. It required a complete rewrite and was not backward compatible with Angular 1. The current release of Angular seems to be version 7.

Yeah, but I am quiet sure at least 12 new frontend frameworks were pushed to Github in the last 24 hours, plus 143+ NPM packages probably broke with the last Babel update

If JavaScript is weird I have no idea what Ruby is. Callback hell and Christmas tree indenting have not been a part of JavaScript for many years since the wide adoption of promises, and now async/await.

What makes it order of magnitudes more performant than Ruby is that it's non-blocking, and now comes with a very pleasant syntax to accommodate.

> What makes it order of magnitudes more performant than Ruby

Source for the "orders of magnitude" anywhere in the last year or so? Ruby with EventMachine outperformed Node significantly when I tested websocket chat servers.

Though now you're in Event Machine world and can't use the rest of the ecosystem.

One of the frequently overlooked properties of Javascript/Node is that it's async-everything.

I'd be curious to hear more about this benchmark.

This might come as a surprise, but async everything is not a feature for a lot of people. It’s a bug.

Yes, of course. Everything is a trade-off. Why the condescension?

But there are almost zero async-everything options in the space. And being confined to a second-class async subworld inside a synchronous ecosystem is a classic error-prone challenge whether you're using Twisted, Event Machine, Tokio, or Netty.

It's a pretty big downside of using Event Machine which even created its own networking primitives instead of using those in the Ruby stdlib.

Sorry, I guess on a second reading you were specifically talking about situations in which you want to do things async. In that case, I can see that everything being async from the start is preferred.

I was talking about the general case of everything being async in JS. That's frequently touted as a benefit of JS, but it's utterly maddening to workaday web developers. You want your requests to be served async (which should just be handled by whatever framework you're using), but inside of a single request you mostly just want to write synchronous code, even when you're dealing with IO. It's a lot easier to reason about.

I'd assert that inside routes you actually don't want to be sync, yet async/await lets you write async code with the simplicity of writing sync code.

Consider the simple example of just running two unrelated database/network queries at the same time which is basically a ubiquitous desire when writing a web service:

    const [user, stats] = await Promise.all([
And now consider a case where you want to issue four database queries, but you don't want the route to take four connections out of the pool at once, instead ensuring that it only uses two:

    // This fn is built into Bluebird and trivial to find 8-line impl for.
    // getA..getD are just functions that return promises so they can be
    // created lazily.
    const [a,b,c,d] = await Promise.map([getA, getB, getC, getD],
      (fn) => fn(),
      { concurrency: 2 }
What I would simply assert is that these sorts of things are really nice to have in your toolbox when writing I/O code like a networked program, and I don't think there exists a simpler async abstraction for it than Node. And I certainly would not have said this until Node had promises and async/await.

99% of the endpoints I write are two steps: load some data from the database, then use that to render HTML, JSON, CSV, etc. I really do not want to encounter any of the myriad of bugs that asynchronous execution makes possible. And the best way for that to happen is if nothing is async.

Or just use gevent and monkey patch the synchronous world to make it asynchronous :)

We had huge performance issues with ActionCable that basically made it unusable for more than 100 concurrent users. We considered EventMachine however ended up going with AnyCable in conjunction with AnyCable-Go which got us up to 1000 concurrency users without any performance impact.

Sources? Seriously, I'd really like to check this EventMachine out.

I ran my own benchmark to decide between the two things a while ago, so I don't have a source in the sense of a published benchmark. YMMV


coming from the django-world, i had the same complain with rails. It was a little too fast for a me.

I just updated a rails app through about 3 years worth of versions and it was minimal effort. Not sure what you mean by this. Rails seems to be very stable at this point.

Rails is definitely way more stable over the past 3 years than it was the 3 years before that. It's settled down. For better or worse.

The last few versions added a bunch of really nice features but it seems the existing features are considered still good and not in need of change.

Would you mind expanding on this? I went from Django to Rails and loved it so I'm always genuinely curious about the experiences of people who didn't have the same fun as me.

It was 4 years ago. I could never work rbenv and bundler to play nicely when cloning the project on the second machine. But I am willing to give it another go.

I’ll say this: I came to Rails from Node (and before that .NET but with a way smaller scope of responsibility), and I am thoroughly convinced the author is correct. I couldn’t estimate for shit in my first few months at this job (once I had ramped) because Rails makes things that would’ve taken at least twice as long easy to do, even without gems. Plus, I have seen not even a third of the compatibility issues between our version of the framework (bit old) and up-to-date games as I saw when I was writing Node full time. Rails is the first non-“enterprise” framework I’ve felt let’s me focus on the correct level of concern for my current needs.

I believe Shopify is built on Rails and is (or was) a Rails monolith. It's worked well for them.

Shopify, Github, Gitlab are all built on rails. Even Twitter was on rails in its early days.

Airbnb, Kickstarter, Twitch, GoodReads, Bloomberg, there is quite a list of companies who still run a significant amount of their site through Rails. Over time I imagine that particular bottlenecks and performance critical pieces have been pulled out into other languages and services as necessary, but I certainly wouldn't feel bad about it if I was developing or maintaing a Rails site today. It's significantly better than PHP, and a hell of a lot of sites are still run on that. The reality is that if you really need to scale, your primary bottleneck will probably be the datastore, not the frontend.

GitLab rewrote some parts in Go, because Ruby was too slow on a big scale.

So “use rails until you raise a C round?” heh

I'd say it's more use Rails for all of your standard CRUD operations and then use Go as a module in Rails using Quartz/FFI if you have any algorithms that need to be high performance. Of course you could always go down the microservice route and spin up a Python/Go service for your more intensive data processing modules.

Exactly, we use Rails for most of the functionality and Go for the functionality that gets used most.

Start with Rails and optimize in Go for the services that get expensive to run in Rails, like https://gitlab.com/gitlab-org/gitaly

I don't have any serious comment, but love "gitaly" as a project name.

if that was a pun on the C language, then I officially groan

Twitter is more of a counterexample I think

Twitter using Rails to grow to the point where Rails became the problem was actually Rails's selling point. If you ever grow to the point where Rails is your problem, then you have money to solve that problem. But if Twitter hasn't used Rails, they might not event get to the point where their product is out the door.

It's absolutely correct to say Twitter blamed their issues on Rails. It's less likely to be correct that they wouldn't need a similar major change if they had started with anything else and grew from an MVP to one of the busiest sites in the world. I personally find it doubtful that they couldn't have done it with Rails.

Stripe too

Here are two of the most popular books on Rails on Amazon, along with their page counts:

"The Rails 5 Way" (1088 pages)

"Ruby on Rails Tutorial: Learn Web Development with Rail" (816 pages)

Rails is enterprise.

What does this enterprise slur even mean? Is it like saying a band sold out when they had a hit record?

Do we only use undiscovered indie frameworks now?

When I started, Java and Spring were (still are..) enterprise (Ruby and Rails existed but were not popular in my area and network) and the major criticism in my mind was the difficulty faced as a beginner.

Spring was humongous and had so many modules that I just couldn't grasp the purpose of each (I still don't) plus there was a lot of overlapping functionality. Senior devs would come to college and ramble out stuff which made less and less sense as time passed by.

Writing a simple app became tedious without a reference by side. So that was enterprise in my mind - tedious, complicated and completely incoherent at times - what and why were completely skipped, at times, in favour of how.

At that time I discovered JS and the simplicity of assembling a decent sized app won me over. The startup ecosystem was also picking up pace in my country and speed of iteration mattered more than anything else. Granted JS can become a nightmare (which I learned later) but that speedy feedback compared to Java was enough to make node my "homestack."

There were other things which worked strongly against Java in my education - 1. Being forced to use eclipse without training (what are these buttons, what does everything do, how do i do this, I was fighting more against the IDE than anything else)

2. Being forced to use the Oracle database which was (for some xyz reason) given to us in a virtual machine and took ages to run a simple join in a small table of 100-500 records.

3. Programmers with experience can be completely oblivious to the mental model of a beginner.

All of this just soured me on "enterprise."

"what and why were completely skipped, at times, in favour of how."

This is a great summary of much of the frustration of using Spring.

My personal guess on this enterprise would be things like Spring or .Net where everything has an interface instead of just do things like Rails.

Long time rails developer turned "enterprise". Spring-cloud now requires much less boilerplate and is easy to develop with using kotlin's syntactic sugar shortening code and making it more concise.

Orm is kind of a failure and requires us to write some queries by hand into string literals, but at least it has it's own sql syntax to avoid engine dependence.

Much less? I haven't use spring cloud for quite a while but last time I did it there's quite some grunt work to make config server / eureka / ribbon / hystrix and friends to work. Let alone the the deployment process.

But I think the key difference is Rails is more opinionated so you don't have to worry about which circuit breaker to use. Or just don't use any.

You are typing about activating the service discovery modules of spring cloud (which rails doesn't have), I am typing about the autoconfiguration goodness. Sure, I could have said spring boot instead of cloud, but cloud is kind of a superset and comes with feign integration so I use that.

Spring Boot is so amazing. I don't feel like any of it is boiler plate at all.

I used to think SpringBoot was amazing until I tried Rails. Then I really felt another level of holy shit.

I have lots of love for both. They're different tools. Ultimately I dropped Rails because being without static typing just isn't for me, but certain parts of the experience were positively magical.

I sort of feel the same way about Boot. That auto configuration mechanism is next level. The breadth and depth of what's available in the Spring ecosystem is great too.

They're really kind of optimized for different things though. Like Rails has some gems you just drop in and it blows you away what you get for stunningly little effort. But then it's not that customizable and you find yourself fighting with it. Spring has all kinds of battle tested enterprise grade bits and bobs that take a lot longer to operationalize but they'll last you forever.

I'm currently trying out aspnetboilerplate as a middle ground between the two. Specifically the aspnetzero version. It's like that "holy shit I get all this out of the box?" with Rails but the "I can understand this, work with it, customize it if I need to and it's going to last the distance". Im finding there is a slight learning curve to it and I wouldn't necessarily make all the same choices the framework does, but so far I can see this becoming a happy medium once I've found my groove with it.

And yet I regularly see "fluent programming" levels of verbosity in the Spring-everything Java services and batch process code at my company. variableNamesThatLookLikeThis and tests.givenSome(data).thatLook(likeThis) seems to be something I only ever see in Java code bases. There's a love of unnecessary verbosity in that ecosystem.

It means it's everything but the kitchen sink: heavyweight, difficult to learn and use, and full of features you don't need.

It has nothing to do with popularity being bad. In general that's good a thing, because support is better (and rails does have terrific support), but it does exert a feature-accretion force.

I didn’t mean it as a slur! When I wrote .NET, the applications I was working in were massively large and complex, and so mostly what I was working on was optimizing small bits and pieces, and they allowed me to focus ON optimizing those small bits and pieces, because they were what mattered in that context. Rails let’s me focus on the big picture, because that’s what matters in my current context. Express had me working on stuff that I didn’t REALLY care about/want to know about in the context I was in.

Have you ever used rails? It's not heavy or difficult to learn. Many commonly used things are actually separate gems, not included in the core framework.

Confirmed, Chicago has multiple billion and hundred-million-dollar businesses built on Ruby on Rails. A lot of it stems from Basecamp being based here, so Chicago had a lot of early adopters. But those early adopters have spawned new companies using the latest versions of Rails decades later.

That may have been intended as hyperbole, but Rails is only 15 years old...


Yes, slight hyperbole in that it was >10 years off the top of my head. Your statement is correct.

I still write Rails applications regularly, some applications I've maintained since 3.0 to 5.x.

What's amazing, is I booted up a 4 year old project in minutes the other day at work. A co-worker was interested in using the project, it took 15 minutes to setup clean.

Overall, I find Rails is easily more maintainable and definitely enjoy it more than the Django and Flask apps I write regularly. Javascript (Node + React/Angular) breaks all the time when upgrading, so maintaining it is not super fun either...

Here's a project I wrote in Rails and deployed late last year:


Works like a charm!

I even recommend Rails to new people starting out because I think it sets best practices.

That’s a fascinating tool! Now I realize I need to use more enjoyable words when discussing TypeScript :)

I'll take a mildly unpopular opinion and say that I really despise code-gen-style web frameworks, like Rails or ASP.NET MVC or Django, and would rather reinvent the wheel than use them.

I definitely see the appeal of these frameworks, but I feel that a side effect of having them is that there's a metric ton of code generated and you really have no idea how it works. I remember spending almost 30 minutes digging through the C# object being used to parse JSON, generated by ASP.NET, to see why a field mapping was being done incorrectly, simply because I had traverse through four different files to see the logic.

Granted, part of the problem there is intrinsic to how C#/Java are structured, and the massive number of files needed by them, but I still feel that the code generation made it worse.

Even if the code weren't generated, the amount of ceremony to add an endpoint, add a new type to be parsed, and perform updates just does my head in. That aforementioned C# app was about ~1000 LOC, across a few dozen files. I rewrote the system, from scratch, using Clojure and http-kit in around 100 LOC, without losing any features.

I'm probably just old now, but I suppose I really dislike magic in my codebase, which is why I tend to prefer the lower-level things.

(Also, just a note, I'm a total hypocrite, since I actually wrote an MVC-ish framework in Node.js 5 years ago, then ported it over to Erlang).

I feel like as a collective set of industries across development and security we have been telling people for years not to reinvent the wheel because it's easier to stand on the shoulders of giants. Despite this, there seems to be an increasing push (from, for example, Go programmers) to go back to DIY. Is this not tearing away all the work we've done to stop people building their own auth, their own crypto, their own file read/write mechanisms and use ones that are battle-tested and safe?

I should backtrack a tiny bit before I'm downvoted to oblivion.

I'm not opposed to libraries to handle a lot of stuff (like auth, crypto, and file I/O). I think it's typically irresponsible to reinvent these things for any reason other than "it's a fun personal project".

What I dislike about a lot of the frameworks is how locked-in I feel. There's (often) only one way to do things, and I don't always feel it's the best way, like my aforementioned parsing logic.

Sure, the framework's way might not always be the best way of doing things but I prefer to just accept it and move on. It saves spending time debating, deciding, experimenting with different ways of structuring code, when it probably doesn't really make that big of a difference in the end anyway. Most web applications are really not that different from each other.

On top of that it prevents really bad coders from rolling their own in a really bad way. Remember when everybody was coding their own MVC framework in PHP?

As for C# not parsing JSON correctly, that seems more like a problem with a language or library not anything to do with frameworks?

I overly simplified, but basically the issue came with having to figure out how the route was binding, then finding the class that was handling that binding, then finding the class the handled the parsing, etc.

It's not intrinsic to all frameworks I'm sure, but imposed structure like that does inherently lead to bureaucracy, which can make figuring stuff out difficult.

Its only an issue when it doesn't work, and for rails it basically always works. In 4 years using rails the only time I have ever had to read the source was to find an undocumented feature in Active Storage which had only just came out.

You're completely right. Clojure enables an incredible amount of productivity. It lets an engineer compose just the things they need, quickly and powerfully, to ship something complete and functioning rapidly.

With that said, might it also be possible that there could be some drawbacks? Having worked in and with Clojure, I found the ecosystem incredibly immature. It's somewhere beyond arrogant - reckless comes to mind - for most engineers to do all their own plumbing for a web service. The odds that they'll manage to design someone easily long-term maintainable are slim. The chances of authorization, authentication, potential SQL injection, and a thousand other security things being handled well is effectively none - the Clojure ecosystem seems wildly ignorant of such things. The core philosophy of just composing the libraries you need into Ring means that anything you don't actively think of will be entirely neglected. This is a dangerous and unprofessional way to ship code that will be facing the real internet.

This stands in stark contrast to the level of consideration around maintenance and security that has gone into a modern, mature framework. Or a modern language where SAST is an option.

Again, you're completely correct. Doing low-level stuff feels absolutely amazing! The sense of control, of having your hands in the guts and the ability to do what you need without wasting time on bullshit magic, is heady and glorious. It's just perhaps worth considering that that magic can sometimes be incredibly valuable, well worth the tradeoff against the feeling of freedom.

I threw Clojure in as an example, but my point is that if I avoid the ceremony, and stick to a few slightly-lower-level libraries, I end up with a lot less code that I feel was overall, easier to write and maintain.

Again, you're completely right. You will get something easier to fit into your head.

Is it perhaps possible that there might be some room to question if the goal of something that fits neatly it one person's head is really the best one? For professional applications, some might opine that there could be other considerations. Certainly most of my comments about Clojure apply to any tools that work from the same mindset.

But perhaps I merely misunderstand an elegantly made point of yours - can you help me?

Sure, it's possible that my mentality is totally wrong, and that having a large amount of cruft is necessary for a lot of big projects. I even built my own framework to experiment with these ideas [1][2] (forewarned that I think I swore a lot in the codebase and READMEs if that's a problem).

I can see that there's probably a case to be made for "forced-best-practices", which a lot of frameworks kind of entail, and I think that if you don't trust yourself (or coworkers) to write quality code, then having the guardrails for that Rails and ASP.NET MVC give you probably feel nice.

However, I think a case can be made that these same guardrails can feel restrictive and noisy to more experienced developers (or people with large-enough egos like me). I have no desire to ever touch J2EE ever again in my life, no matter how much I could get paid doing it, because it felt like getting anything done was about as much fun as filing my taxes.

Rails is certainly not as terrible as J2EE, so I'm not trying to draw a direct equivalence, and maybe a balance can be struck...Personally, I find that the "give me a server and I'll set up some middleware on top" approach like Express (for Node), and the aforementioned Ring/HTTP-Kit for Clojure give me the best balance.

Clearly there's a middle-ground -- I certainly wouldn't suggest that most people go and reimplement TCP and HTTP from scratch for a project, unless they're severely masochistic, or they just want to learn more about TCP or HTTP.

[1] https://gitlab.com/tombert/frameworkeyPromiseEdition [2] https://gitlab.com/tombert/Frameworkey-Erlang

I've personally watched experienced, mature, and very senior developers build sophisticated systems with Clojure, Ring, and http-kit. And blink at me owlishly when I ask them how they sanitize their inputs to guard against SQL injection. They'd been intensely focused on the core logic, architecture, system design, and business functions. Everything else received cursury consideration.

My takeaway from that is that it's unreasonable to expect even the best of developers to remember every detail every time. Even the best forget or make mistakes. If our tools don't take this into account and protect us from ourselves, we're going to get burned.

I don't disagree with what you're saying; as I've stated, I'm not opposed to having some good libraries to handle dangerous stuff. I personally try not to do SQL with direct string-concatenation, and instead opt for something to sanitize stuff before I actually run anything (at least anything that has the chance of ever touching outside my basement :) )

I just don't like having the libraries forced as part of the full structure, and instead would (typically) prefer them to be functions (or if you're in a Lisp, possibly macros).

I totally agree. I don't like the feeling that comes from being babysat by code that tells me how I need to do everything.

But I don't know a better way to guard against all the things I might not think of. I've seen entirely too many cases of people doing something wildly unsafe and reckless because it seemed the easiest to them at the time and their tools didn't handle things for them. Use serialized objects to communicate between systems? Why not? We have Avro schemas, those will keep us safe as we deserialize random data from the network, right?

As much as I don't like being treated like a child by a bucket of bits, I also recognize that Clojurian minimalism requires me to think of literally everything. I have to know everything that's dangerous, how it's dangerous, and how to guard against it. That feels like even more load on my brain than being babysat - and I'm a security specialist!

That's fair enough, I'm not really a specialist in anything since I'm (officially) unqualified for everything...I will concede that you might have a point security-wise....but I don't have to like it!

Rails auto generates very little these days unless you ask for it.

To note: been working on Rails for 6+ years.

I was reading the parent comment and some of the other comments about the mental model of a beginner. I suppose if you're first exposed to Rails and start using 'scaffold' it can generate a ton of code you'll need to grok. But once you understand the nuances of writing Rails its much faster and cleaner to just create files and go about your business. There is only 1 thing I ask Rails to generate for me and its database migrations; it handles adding the timestamp and placing it as the end of the folder, thats not something I care to think about myself.

I very much appreciate the code generation. I hate having to make repetitive changes in 4 places to add a new file because nothing is wired up automatically.

But why should there be 4 places to change things to begin with? Why not use libraries to minimize the amount of surface-area entirely?

I can't speak for the others but Django doesn't do any code generation. Are you talking about the templating system?

I threw Django in there, but I might have a false memory of it. My bad if that's the case.

I don’t think I’m that old... but I’m very much in the same boat as you.

Then again not everything I work on has to do with web or API’s so maybe that colours things a bit for me.

I think I know exactly what you’re saying and I agree. Also no less the hypocrite here, but like WW said “I am large, I contain multitudes”!

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact