Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Miss Rails

chanind.github.io

Post reply on HN
Print view View original

431–440 of 522 posts

Re: I Miss Rails

#431

Post by excid3 »

digitaltrees wrote: post #263
rajangdavis wrote: post #147

Is there a modern Railscasts? I feel like the Rails community owes a lot to Ryan Bates for pushing out high quality content and keeping up to date with Rails for as long as he did.

gorails.com and driftingruby.com

Thanks for the recommendation of GoRails! I started screencasting a few years back because I missed Railscasts and learned just about everything from Ryan Bates. Wish he was still around in the community.

If anyone ever has suggestions on Ruby / Rails topics to cover, let me know!

Re: I Miss Rails

#432

Post by andrethegiant »

tomc1985 wrote: post #236
strken wrote: post #136

Earlier quoted context omitted.

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.

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

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

Re: I Miss Rails

#433

Post by ethagnawl »

m23khan wrote: post #409
vbsteven wrote: post #307

Earlier quoted context omitted.

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

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

Re: I Miss Rails

#434

Post by nnq »

0xADEADBEE wrote: post #28
BillFranklin wrote: post #6

> 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:/…

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

Re: I Miss Rails

#435

Post by hezag »

b212 wrote: post #70
hezag wrote: post #66

Earlier quoted context omitted.

Sails.js [1] is a good JS equivalent of rails. https://sailsjs.com/

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

Re: I Miss Rails

#436

Post by jimbokun »

davidbanham wrote: post #333
xz0r wrote: post #317

Earlier quoted context omitted.

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

Yeah, sure thing! https://takehome.io https://clubman.app

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

Re: I Miss Rails

#437

Post by xutopia »

I think Rails is amazing. My only gripes with it are that tests run slow and you need plenty of tooling to make things work (redis, sidekiq, anycable).

I have been particularly interested with Phoenix as of late as it fixes all the gripes I have with Rails and Liveview is an amazing pattern that I think would simplify a lot of things.

Re: I Miss Rails

#438

Post by jimbokun »

sytse wrote: post #220
rohan404 wrote: post #196

Earlier quoted context omitted.

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.

Re: I Miss Rails

#439

Post by gambler »

chasd00 wrote: post #425
gambler wrote: post #398

Earlier quoted context omitted.

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

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", ev…

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

Re: I Miss Rails

#440

Post by koolba »

gambler wrote: post #418
koolba wrote: post #54

Earlier quoted context omitted.

With TypeScript you can define a single set of interfaces shared by both your client side and server code. If you change an interface to return a different value or rename a member, you immediately know where it’s used and can update it in tandem. Static type checking let’s you know everywhere that something is used without a battery of tests running through your app. This takes 99% of the fear out of refactoring and…

>With TypeScript you can define a single set of interfaces shared by both your client side and server code. If you don't have page-specific (or any, if you can) code on the client side, this stops being a problem in the first place. It's funny how SPA fans here claim both good separation of concerns via web services and code/type sharing as features while in practice those things are mutually exclusive.

> If you don't have page-specific (or any, if you can) code on the client side, this stops being a problem in the first place.

Sure and that's a valid use case for server rendering. Though even in that situation having a typed mechanism for going from a model and view to HTML wins out over untyped templates that operate primarily on string replacement. You have the same problem server side when "first_name" in your model is renamed to "display_name".

Unless you have tests that lead to rendering every possible if/else branch in your rendering logic, you're not going to realize that you forgot to update your view template until that situation happens in production. The more complicated your views, the more likely you'll run into this situation.

> It's funny how SPA fans here claim both good separation of concerns via web services and code/type sharing as features while in practice those things are mutually exclusive.

I'm not sold on SPA either but for any application that involves an active client that makes it's own requests and maintains state, you end up needing some form of documentation for those interactions. It's not a panacea but well defined interfaces shared between the server and client solve a big part of that.

Post reply on HN