Live data from Hacker News

I Miss Rails

chanind.github.io

461–470 of 522 posts

Re: I Miss Rails

#461
post #434

Earlier quoted context omitted.

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 some…

> 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 wou…

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

Re: I Miss Rails

#462

Earlier quoted context omitted.

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.

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.

Re: I Miss Rails

#463

Earlier quoted context omitted.

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:

https://groups.google.com/d/msg/django-developers/mLlWYEC8_G...

Re: I Miss Rails

#464

Earlier quoted context omitted.

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, moder…

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.

Re: I Miss Rails

#465
post #381

Earlier quoted context omitted.

What does that actually mean, though? And "there's no reason you can't, if you wanted" is a far cry from "sure, the work is already done." For example, something as simple as having a server-side rendered forum built with your favorite back-end language and now you want to build a client for it (web, iOS, Android). That basically means massive duplication as you create a json interface boundary. Yeah, you were alread…

It sounds like you're assuming the SSR is not well architected and then using that assumption to prove your point. It's pretty easy to have an API layer interal to your application -- have your view templates consume that API. No reason you have to have your view templates across the network, written in another language.

No, what I would say instead is that 90%+ of SSR apps aren't architected like that, so I would accuse you of the same thing: that you're using "well architected" to describe what's actually an exotic configuration that nobody refers to when they talk about SSR, basically creating microservices on localhost that hit your own network stack which is a premature abstraction for most cases that I thought you just got done lambasting in your OP.

Re: I Miss Rails

#466
post #88
post #37

Earlier quoted context omitted.

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

Twitter is more of a counterexample I think

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.

Re: I Miss Rails

#467
post #460

Earlier quoted context omitted.

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 ful…

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 com…

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!

Re: I Miss Rails

#468

Earlier quoted context omitted.

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…

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…

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.

Re: I Miss Rails

#469
What would be cool is a full stack framework that was built around GraphQL and a SPA but that had essential packages for a broad array of features. Sort of like when rails added REST but within and around the framework. The problem with configuration would be solved if vue or ember or angular had an opinionated server/api stack that was maintained and integrated more tightly. Some people like configuration, that’s fine, lots of options out there. Others like conventions and a unified end to end platform, lots of options for MVC, literally none for SPA/API.

Re: I Miss Rails

#470
post #46

Earlier quoted context omitted.

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 some…

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.

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.
Post reply on HN