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.