So what is the modern front-end equivalent to Rails or Laravel?
With clear outstanding options for authentication, image processing, and all the other bits that are commonly needed?
I Miss Rails
221–230 of 522 posts
Re: I Miss Rails
#222I really have no horse in this race, but I would like to know what the argument FOR React+Redux+GraphQL is for developing apps in 2019. Is it that we need to offer offline clients to meet user expectations? Better raw performance on the front end? Cheaper server costs or easier to deploy serverlessly? For the progressive enhancement of your resume?
It’s really good at highly dynamic/interactive apps, such as browser versions of asana or slack, or other things where user actions are small but frequent. If you aren’t doing full page reloads and have a lot of changes, it’s much simpler than managing each individual state change in vanilla javascript. I personally think React’s component model is much nicer than any templating system I’ve used as it supports compos…
> React’s component model is much nicer than any templating system
This is my feeling too. Composition and JSX beat logic in templates.
Though I've seen some pretty hairy React, I still prefer it to badly implemented template files.
Re: I Miss Rails
#223I actually have gone back to writing server-rendered apps like it's 2012 and it's been wonderful. Server-rendered used to mean slow and clunky but I've found that using Go my page loads are super fast. The inter-page transitions can sting a little on really really slow connections, it's true. But users are much more willing to deal with them if they haven't first been subjected to a minutes-long spinner while the SPA…
How many "quality of life" features does your website have that require some JavaScript that you end up writing as one off functions/endpoints/etc? (various kinds of autocompletion, live search, notifications, messaging, etc.) I'm all for server side rendering - I maintained several vanilla PHP/HTML/CSS websites in the 2000s, and only used jQuery sparingly when things grew in complexity. I later used Django for many…
Just because you have some interactivity doesn't mean you have to jump to an SPA, vue/knockout work well in the hybrid scenario and then you only have the complexity where it makes sense as well.
Re: I Miss Rails
#224Ruby on Rails out of the box gets a lot of bad rep for being slow and non-performant. Has anyone replaced MRI with JRuby or TruffleRuby to mitigate that? Were there any significant "gotchas" with integrating it?
I did a POC getting a monorail running on JRuby (probably 6?) years ago. It wasn't for performance reasons (though we did have some GC issues, which JRuby might have helped). It was because we had to integrate with some services which only vended APIs via JARs.
The biggest dealbreaker was that (like most Rails apps) we had a ton of gems, some of which had native extensions. JRuby doesn't support C native extensions.
In the end, it was way easier (and a much less risky change) to spin up our own Java REST APIs in front of those JARs, and let our MRI Rails app integrate with them by talking to those REST endpoints.
Just for fun, I also tried using dRuby so an MRI Rails app and a small JRuby (non-Rails) process could communicate idiomatically. It was cool, but I'm pretty sure dRuby was eventually deprecated.
Re: I Miss Rails
#225I never liked Rails even when it was hip. Way too much bloat and magic behind the scenes, and also poor performance because of that. I always preferred Flask, because it gave you a minimal framework, allowing you to cherry pick modules as needed. Sinatra looks similar if your preference is Ruby. I cannot say that a Node stack is better though. Both Rails and Node are fairly awful, but for entirely different reasons.
When I first started with Rails/Ruby things felt magical. There is still definitely a little magic, but with time I've found it to be less so.
Usually all it takes is to lookup the source (which is well commented/documented) to see where the magic is coming from, the code is fairly easy to understand. If it works well use it, or take what you like/want and write your own methods, classes etc.
Re: I Miss Rails
#226Earlier 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…
You get all of that for free with Java, plus you don't have to use javascript
You also get nullable types with Java, which severely cripples the confidence static typing is supposed to give you.
Re: I Miss Rails
#227Rails with Webpacker is the best of both worlds IMO. Ruby is a pleasure to write and Rails saves a ton of time. There are just so many things that Rails does that you forget about until you start putting together a Node app.
Re: I Miss Rails
#228Here's how i replace Rails with the "modern stack": - Compile Graphql schema into Typescript typings + Fragments for "Active Record" - React Hooks as controllers action. - React Suspense for HTML rendering. - Apollo for graphql caching - ExpressJS for middlewares. - @reach/router for routing. - @loadable/component for code splitting. - Serverless for API. I missed Rails, too. But i found that the "modern stack" is no…
This strikes me as being more archaic than modern.
Re: I Miss Rails
#229Earlier quoted context omitted.
Why not Sinatra + ORM in that case?
I have seen this many times. You start with ActiveRecord, and before you know it, you are with a working with a Frankenstein of gems that resembles Rails, except it isn't done well.
I've come to a different conclusion over the years.
For example, let's compare 5 legacy Rails apps (each at a different version since this is the real world) to 5 bespoke Express/Sinatra apps.
One upside of the Express apps is that all of their glue code is right there in plain sight. You can go into each code base with a blank slate and read the code to understand what it's doing with zero dependent knowledge.
Having worked on Rails apps as part of my 7 years as a contractor, you don't get that benefit in a super framework. You need so much knowledge about Rails to follow the trail through an application. And it gets hard to keep things straight once you're jumping around old versions. Even stuff like "wait, where did this variable/method come from again?" and being able to quickly ID it as something Rails itself provides vs something else (application code or gem).
Or how about figuring out how authentication works in each of your 5 Rails apps that use Devise? If you're a veteran, you know to look for some magic options in config.rb/devise.rb and you know what they translate into. Otherwise it feels like credentializing in a black box.
I think that things like React and Express are toppling the old guard idea of Ember and Rails that large applications somehow save you from work. When Rails was hitting the front page of HN every day 9 years ago, the meme of the day was how much you could do with so little code. DHH showed you how to make a blog with almost nothing but `$ rails generate`. Want a user-avatar system that uploads to S3? Just drop a few lines here and there: https://github.com/carrierwaveuploader/carrierwave#getting-s... -- this was the spice of Rails.
The benefits are almost undeniable upfront, and the down sides of the trade-offs they make usually take a long time to fruit, so they're hard to quantify. But they're there.
But I can't tell you how many times I've deep dived on a client's old Rails app with pencil and paper into the wee hours of the morning wishing it was indeed just a "microframework that half-implemented Rails" if that would mean I could follow actual code from A to B.
Don't get me wrong, there are always trade-offs and there is never a best. This isn't to lambast all Rails apps across the globe. But I see the "you're going to either use Rails or reinvent Rails" meme a lot to discourage smaller frameworks more often than I see someone point out the other side of that trade-off.
Now, which
Re: I Miss Rails
#230Earlier quoted context omitted.
My personal guess on this enterprise would be things like Spring or .Net where everything has an interface instead of just do things like Rails.
Long time rails developer turned "enterprise". Spring-cloud now requires much less boilerplate and is easy to develop with using kotlin's syntactic sugar shortening code and making it more concise. Orm is kind of a failure and requires us to write some queries by hand into string literals, but at least it has it's own sql syntax to avoid engine dependence.
Spring Boot is so amazing. I don't feel like any of it is boiler plate at all.