Hacker News Reader

Comment by ericb | Hacker News Reader

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.

View on HN

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.

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.

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)

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

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

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

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

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.

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.

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.

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

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([
      db.getUser(42), 
      cache.fetchStats()
    ])

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.

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

https://github.com/eventmachine/eventmachine

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.

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

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

Reply on news.ycombinator.com