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)

to

    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 :).

Ta.

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).

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.

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.

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:

https://github.com/ChangJoo-Park/amber-realworld-example-app...

(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.

https://sorbet.run/

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.