> if the modern equivalent of Rails already exists, please let me know!<p>You're in luck. Rails 5.2.3 was released 20 hours ago.<p>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.<p>EDIT: If you're talking about missing a JS equivalent of rails, do you know about Loopback? <a href="https://loopback.io/" rel="nofollow">https://loopback.io/</a>
I actually have gone back to writing server-rendered apps like it's 2012 and it's been wonderful.<p>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 loads up all its libraries and state.<p>A little game I sometimes play is asking fellow developers to try and guess the frontend framework used on one of my apps. They click around for a little while wondering "Angular or React" before I tell them it's actually just some Go templates rendered on the server. It often opens their eyes that the loads were so fast they couldn't actually tell they were happening.<p>SPAs have their place and I've written a lot of them. It's amazing how far you can take server rendering in 2019, though.
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.<p>It seems like the JS ecosystem changes so fast because it <i>knows</i> better is possible, so it just tries to reinvent itself over and over.<p>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.
I’ll say this: I came to Rails <i>from</i> Node (and before that .NET but with a way smaller scope of responsibility), and I am thoroughly convinced the author is correct. I couldn’t estimate for shit in my first few months at this job (once I had ramped) because Rails makes things that would’ve taken at least twice as long easy to do, even without gems. Plus, I have seen not even a third of the compatibility issues between our version of the framework (bit old) and up-to-date games as I saw when I was writing Node full time. Rails is the first non-“enterprise” framework I’ve felt let’s me focus on the correct level of concern for my current needs.
I still write Rails applications regularly, some applications I've maintained since 3.0 to 5.x.<p>What's amazing, is I booted up a 4 year old project in minutes the other day at work. A co-worker was interested in using the project, it took 15 minutes to setup clean.<p>Overall, I find Rails is easily more maintainable and definitely enjoy it more than the Django and Flask apps I write regularly. Javascript (Node + React/Angular) breaks all the time when upgrading, so maintaining it is not super fun either...<p>Here's a project I wrote in Rails and deployed late last year:<p><a href="https://hnprofile.com/" rel="nofollow">https://hnprofile.com/</a><p>Works like a charm!<p>I even recommend Rails to new people starting out because I think it sets best practices.
I'll take a mildly unpopular opinion and say that I really despise code-gen-style web frameworks, like Rails or ASP.NET MVC or Django, and would rather reinvent the wheel than use them.<p>I definitely see the appeal of these frameworks, but I feel that a side effect of having them is that there's a metric ton of code generated and you really have no idea how it works. I remember spending almost 30 minutes digging through the C# object being used to parse JSON, generated by ASP.NET, to see why a field mapping was being done incorrectly, simply because I had traverse through four different files to see the logic.<p>Granted, part of the problem there is intrinsic to how C#/Java are structured, and the massive number of files needed by them, but I still feel that the code generation made it worse.<p>Even if the code weren't generated, the amount of ceremony to add an endpoint, add a new type to be parsed, and perform updates just does my head in. That aforementioned C# app was about ~1000 LOC, across a few dozen files. I rewrote the system, from scratch, using Clojure and http-kit in around 100 LOC, without losing any features.<p>I'm probably just old now, but I suppose I really dislike magic in my codebase, which is why I tend to prefer the lower-level things.<p>(Also, just a note, I'm a total hypocrite, since I actually wrote an MVC-ish framework in Node.js 5 years ago, then ported it over to Erlang).
I still develop using server-rendered like it's 2012. Since I'm pretty much an indie dev, I just don't think it's worth my time to initally start a project off REST API (i.e. using react) because it's literally 1 more layer to take care off. I.e. if a REST end-point name changes, then I'd have to modify both frontend and backend code. In addition to that, initially, getting a software specs is a much harder problem than to implement. Having to create REST endpoints for every single data that needs to be passed around is not nice when the structure and specs are still very likely to change.<p>Moreover, finding developer experienced in react is much harder and more expensive than those who do traditional HTML-CSS combo. Finding a freelancer to slice out PSD design into HTML-CSS is also much harder to go wrong. I wouldn't be comfortable outsourcing a react project to freelancer I barely know, but I'd do it for HTML-CSS.<p>I'm not against react or other SPA frameworks by any means. I think they're great technology that makes certain use cases convenient and can make a good user experience. That being said, there are also costs for those, and I just feel like there are so many websites out there that don't actually need to be implemented using SPA. Traditional server-side rendering would have saved them so much time, resources, and headache.<p>I personally would only rewrite a particular project into an SPA when there's a real need for it. For example, when the user base is large enough that a nice-to-have user experience becomes a big enough deal, if there are real needs for "reactiveness", or if mobile apps counterparts that would also require REST API is needed.
Elixir and Phoenix are excellent, and you'll recognize many of the same concepts in these. The communities are excellent as well, and welcoming to newcomers.
"Move fast and break things" very accurately reflects the state of Javascript development in 2019. Libraries and frameworks, and node/npm themselves move so quickly that APIs, versions, ways of doing things -- all break so quickly as to be ludicrous.<p>This post rings true.<p>I gave nextjs a try recently to build a simple dashboard that could connect to our oauth provider. Forget external libraries, even simple ways to do state management, user login, screens, HOCs to guard routes - all of this is poorly documented, managed, and there are 100s of github gists that aren't versioned, demonstrate old APIs that have been deprecated and aren't really usable unless someone who knows that they're doing goes in, and cobbles together an example.
I've been using Django since I started 10 years ago. I argue that it was a great choice back then and it's _still_ the right choice even with the advent of the modern everything. If you are writing a website for a business, I see nearly no actual business case for using Node+SPA for nearly any kind of website you'd want to build. Especially in a business context, unless you are building a super ultra real time thing (and then use Elixir not Node), Django will do just fine and be several times faster to develop and easier to pull off. And you can get pretty far into the dynamicness camp before it becomes untenable. s/Django/Rails.
I personally don't missed Rails mostly because boilerplate doesn't really bother me. I'm more afraid of using the wrong abstraction.<p>Rails (v4 was my last experience) was hard for me and I think my reasoning is as follow:<p>- I like to dig deep into the framework I work with but Rails have so much meta programming (a.k.a magic) that I struggle real hard figuring out stuff. You often have to go into runtime, hit method and see where it lead you to and after a while, I realise that I'm not going to see the bottom.<p>- If you are someone who like to dig deep, the documentation wasn't helpful for me at all.<p>- ActiveRecord for a while discourage using foreign key. When I move away from Rails, I tried SQLAlchemy and love that its unopinionated. Then I move to node and agree its ORM are less powerful but I learnt to love SQL. ActiveRecord for me shouldn't be any more than just convenience ORM and shouldn't replace SQL, that goes against Rails' ActiveRecord philosophy which claim these constraints should be at the model side rather than DB side. <a href="https://guides.rubyonrails.org/active_record_migrations.html#active-record-and-referential-integrity" rel="nofollow">https://guides.rubyonrails.org/active_record_migrations.html...</a><p>- Lastly, I firmly believe MVC is a leaky abstraction. Any variations of MVC is just shifting the complexity around, not reducing it. I worked on Rails, worked on iOS (which uses M-V-VC). The pattern I see is that almost every year, someone will get bitten by vanilla MVC, tried some variants unsuccessfully and conjure a new variant; the cycle goes on. MVC is a 20 year old pattern, it have amazing insight into how we should build application, but its implementation always fall short after so many years.<p>Ultimately, I don't think Rails was optimised for someone like me. I think there's just fundamental differences in philosophy between me and Rails.
I 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.<p>Is it that we need to offer offline clients to meet user expectations?<p>Better raw performance on the front end?<p>Cheaper server costs or easier to deploy serverlessly?<p>For the progressive enhancement of your resume?
Seriously, do people <i>like</i> writing boilerplate or something? Whenever I write a non Rails backend, I keep on thinking about how easy, how fast this would be done in Rails. Like I'm writing a backend right now in Rust, and while Rust is an excellent language with lots of ergonomic features, it's not a tenth as fast or fun as Rails. It's quite depressing to be writing a bunch of Rust code only to remember that this would be done in a few minutes with Rails (albeit with half the safety).<p>For instance, let's take writing a simple RESTful API. With Rust and Rocket, I need to build up the file structure, start writing controllers to fetch the different resources using diesel, figure out connection pools and how they link with Rocket fairings, then find I need rocket_contrib in order to automatically serialize to Json, then write out all the same routes (/ GET/POST, /:id GET/DELETE/UPDATE, etc.). Meanwhile in Rails I type `rails generate scaffold article title:string content:string`. Boom. Done.<p>Several times I've found myself thinking about ways of making my development experience better in Rust. Maybe I could write some macros that fix my problems. But then I'd just be reinventing Rails' metaprogramming. Ah well. I guess sometimes we need to reinvent the wheel.
What’s the harm in using rails purely as an API? You’ll still get a lot of functionality out of the box and maybe have to write just a little bit more glue code for the JS-backed front end than what rails provides out of the box.
> I’m not suggesting that we give up React and es7 and go back to writing server-templated web-apps like it’s 2012 again.<p>My team is still building server-templated web apps with Django, RoR, Laravel. It's just that most software we make is some sort of CRUD application and React/Redux feels like overengineering, and still a mess when it comes to SEO. Clients are happy and ultimately don't care. Should I be worried?
Ember was rails on the frontend. Still chugging along I guess, but honest to god I haven't seen a soul use it in the past three years. Anywhere I worked, anywhere I asked.<p>I'm using Phoenix and Elixir these days instead of Rails. But I've also been circling back to C# after 9 years of not using it for anything. C# has become to so incredibly open that you can write C# code and build static binaries for Linux, Mac and Windows, with single commands. Definitely check it out if you want something like that under your toolbelt.<p>The fact is, the javascript ecosystem is a house of cards. Most definitely the worst ecosystem I've ever used to write software. I sometimes wish a competitor to NPM launched with better organization and rules. NPM is insane, in all the worst ways. Google the left-pad incident. We need JS so we're stuck with NPM I guess.<p>Maybe with Phoenix LiveView we can get away with _less_ JS - maybe...
I actually dislike RoR but I'm at the same conclusion as OP. There is just something about Ruby that makes me want to keep going back to it. It is difficult choice when given the fact that JS is (and probably always will be) the de-facto language for the web so it's really hard to dismiss Node. But if that wasn't the case, I'd stick with Ruby all day.
I've known rails for years but haven't yet used it seriously. I felt it's good because setting up is easy and the velocity is high.<p>Until now I use it every day and I found it's really great and better than my previous impression:<p>1. Compared to JS there's always a specific way of doing things - how to validate, how to dispatch async Job, how to send emails and real-time notification etc.<p>2. Compared to Spring there's only a recommended default way you can easily start with. You don't struggle with SpringWeb vs WebFlux, different JMS implementations, Hibernate or query builders, etc.
> Do you need user accounts with signup / login / forgot password emails / email confirmation? Install devise and you’re done.<p>I don't understand why these types of features are so sorely lacking on other frameworks. I was looking for a simple user management dashboard for MVC and maybe my google fu was lacking but I just could not find anything easier to implement than spending a day writing my own stupid dashboard...
Rails is just very high level. The comment on meteor makes it clear why a Rails didn't exist in JS-land. Because the fundamentals are so dynamic and so in flux it becomes hard for a high level framework to gain traction when it can become outdated so quickly (though meteor was a particularly incompetent try at it and that's not the only reason for its failure). Once the community grows a stable low level stack then a Rails-like will inexorably emerge imo, but I have a feeling that React is not at that stage yet.
I love Rails vision about how to do full stack web development. It is a really good abstraction, that hides unnecessary technical complexity and lets you focus on solving business problems.<p>A lot of people here complains about Rails performance, and that is one of the reasons why I use the Grails - Java framework. It is not as polished as Rails, and has a few sharp edges, and it has a much smaller community which is still super-friendly and awesome. Grails however can still take the advantage of the enormous Java ecosystem. You have a library for about <i>everything</i>. And many of them is of really high quality too.<p>I have for the last five years built three successful startups with Grails, where the last one now employs 100 people. Grails has been really helpful here, as it has made it possible to move fast and add,fix,improve,break changes quickly. For my last startup Rails would most likely have struggled with the amount of data we are dealing with, while Java is hardly sweating. It is not something Grails specific, but still a part of the Grails application, that is why I mentioned Java.<p>My last startup, which now employs over 100 people didn't use React nor Angular either in the beginning, just vanilla Javascript. More speed, less complexity, less errors and so on. We use React today, but that is because new employees really really wants to work with. And developer happiness is really important.
Having just deployed Discourse and Diaspora its obvious Ruby and Rails was not designed for end user use. There is complete and total dependency hell and a hard requirement for a build environment for basic app deployment.<p>This kind of engineering directly leads to endless wasted hours troubleshooting errors, routine build fails and apps that think nothing of pulling in hundreds of dependencies that in turn have their own dependencies that can fail at any time.<p>This is plainly wasting millions of man hours of end users time if its not a SAAS app. Compared to that Go is an ode to simplicity, PHP just works, Python is relatively painless and even Java causes little stress. Its node and ruby that seem to be designed by people who revel in complexity and have zero concern for deployment and end users.
I don't use rails, but I agree with sentiment in general. I first learnt front-end stuff with desktop UI libraries and I hated it. Creating UIs with programming languages sucks. The first time I used the web environment, I really enjoyed it and it was the reason I decided to focus on programming for the web. I was using PHP and server-side rendering, with some javascript to do some interactive things. I liked that the design aspect (html and css) was completely separate from the programming, and that there were no compile steps.<p>Then eventually the requirement for more application-like experiences led me to adopting client-side frameworks because server-side just wasn't able to do those things very well. I like the idea of a json-based api talking to a client application, but the client-side libraries have bought back all the things I hated about desktop UI programming.<p>I think html is great and should be left on its own, not combined with the programming language. That is the reason I don't like React. I can't read all of that jsx/pseudo-javascript together. It looks like a mess. Vue is better, but it is just a big hack of stuffing things into html attributes. Both of them also require a compile step if you want to use them to their full potential. So now all the things I hate are back, and I don't like web programming anymore.
People always forget Ember.js, like it's some relic of the past, despite it having very active development and a toolchain for a consistent Rails-like experience on the frontend. There's no reason why you can't use React or Vue components inside an Ember.js application if that's what you prefer.<p>As much as I've grown to despise the Ruby community for relying too heavily on metaprogramming and inheritance, leading to abstraction hell, I think Rails is still a great framework for serving web pages. Just because it's not the shiny new thing doesn't mean it can't do most of the things we want from it(not every company is FAANG scale), and there is still an abundance of Rails jobs in 2019.
First of all, you should use the right tool for the job. Having said that, Rails kept giving me the icky feeling. What you gain in speed of development, you lose in performance and server costs and all sorts of crazy gem meta-magic.<p>My current middle-ground stack is Golang API (I use go-chi) + (LitElement front-end (web components) + Redux). I'm kinda happy, though my gripe is with Go sometimes, not the stack.<p>To the far right where people are complaining on: React + GraphQL, etc. Well, I think you went into the deep end, so rightfully you think about veering back left again. But hey, there's a middle ground that is more "standard's based".
The current javascript landscape reminds me of PHP circa 2003 + isomorphic single page madness + functional philosophical purism + dreams of type safety + <new fad here every six month><p>Yuck.
Is there a modern Railscasts?<p>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.
Rails is still very much alive and popular, this is kind of a weird take. Server rendering is also very much still a thing.<p><i>But</i> I do agree that it seems the JS ecosystem is missing a real Rails equivalent. Specifically an ORM that is as robust as ActiveRecord. I've often thought about building this myself, and then I remember I have a family and full time job.
I think that Buffalo is actually the most credible replacement for Rails that I've seen:<p><a href="https://gobuffalo.io/" rel="nofollow">https://gobuffalo.io/</a><p>The lead developer is a ex-Rails developer with a very keen sense of what made Rails successful. One of the reasons that it's still pre-1.0 is that it won't ship until the plugin architecture is good, which speaks to the point of the article.<p>You don't need advanced syntax in the server code to write Rails <i>applications</i>, so Go may be a good fit for a Rails replacement.
>> I’m not suggesting that we give up React and es7 and go back to writing server-templated web-apps like it’s 2012 again<p>Actually I have gone back to server-template development using Django for selected projects, after many years working with React, which I still love.<p>Server side templated development with Django can be extremely fast in terms of development time, very direct and effective.<p>There no need to use React for all the things.<p>Sometimes React is the right tool, sometimes server side templated is the right tool.
Rails 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.
Every single example the OP laid out is solved by an official laravel package. People love to hate on PHP but I can spin up a laravel app with all of those features in a matter of hours.<p>I can build a traditional server side rendered app or I can use the front end scaffolding to build an API driven SPA based on vue or react.
We need a framework that makes it easier to build server-rendered, multi-page web apps with Node. Preferably something "batteries included," with support for recent innovations in web tech.
I keep looking at C# and Blazor myself<p>If you want an SPA type Rails way of doing things, you can use Turbolinks. This talk at RailsConf 2016 is really an eye opener.<p><a href="https://www.youtube.com/watch?v=SWEts0rlezA" rel="nofollow">https://www.youtube.com/watch?v=SWEts0rlezA</a>
I recently started working with Django after not using it for almost 10 years. It's really wonderful how nice it is to get projects up and running so fast, and the Python community is stronger than ever. There are many integrations with modern tools like Cognito and Stripe, and it automatically turns my model definitions into an admin interface and REST API (with django-rest-framework). I think I'll be sticking with it for a while.
Whether you use Rails today or moved on, many of the concepts introduced and/or popularized by Rails can be seen in the current generation of popular server-side frameworks across many platforms.
I take modern to mean: Using latest state of the art techniques to increase programmer productivity and happiness.<p>Rails is still the number 1 backend framework, and the RoR ecosystem is so powerful that the <a href="https://hyperstack.org" rel="nofollow">https://hyperstack.org</a> gem lets you code in Ruby on the client, and fully access your AR models directly in your client code (again all written in Ruby.)<p>You get all the maturity of rails, including be able to use Rspec to test your server and client code in an integrated fashion.<p>Here is a blog post that shows how simply adding a 2 line AR model declaration adds data persistence, and push synchronization to a "client-only" app: <a href="https://medium.com/@mitch_23203/the-exact-same-app-in-hyperstack-part-ii-5b062074ec20" rel="nofollow">https://medium.com/@mitch_23203/the-exact-same-app-in-hypers...</a><p>If that is not "modern" I don't know what is.<p>Meanwhile the rest of the world is writing tons of boiler plate, creating reducers, transformers, co-axial independent state repeaters, I don't know what all, but the bottom line is you have to write a ton of code to get anything done.
The arrogance and ignorance of this post is massive. There is nothing wrong with rails or django or symfony or any other server side rendered web framework, whether it's 2012 or 2019. The author seems to think that somehow react SPAs are the only modern apps. The case against SPAs is still huge and for most use cases, they are the wrong tool for the job. This type of cargo cult, fashionable trend thinking undermines his entire argument and questions his qualifications as an engineer. There's no logical explanation for not using rails or something like it. He's complaining about a problem with literally dozens of proven solutions, including rails, that he's even aware of, and yet refuses. What ever happened to use the best tool for the job rather than what's fashionable and popular in 2019? I would not want such an engineer anywhere near my company, that's for sure. I can't think of a worse trait than knowing the right solution to a problem and deciding to use something else just because "everyone else is doing it." Absolutely bonkers.
If I understand the situation correctly:<p>Rails applications benefit from batteries included boilerplate because Rails "owns" the whole stack.<p>"Modern" (contemporary?) JS applications benefit from separation of concerns, and flexibility because each layer is interchangeable.<p>So how do we make this better? We can't reasonably split Rails up to match the benefits of JS. The obvious (naive?) solution is to provide a protocol that JS layers can follow. Specific packages/layers can decide to provide the protocol which makes them interoperable. The developer may then pick and choose, knowing that if they choose packages that comply with the protocol, they can use the "batteries included" features.<p>It would be fairly trivial to identify the major features that most apps reimplement. Getting it all to play well together would not be as easy.<p>As the OP described, I think Meteor was a great platform, but had some fatal flaws. If "Meteor-the-company" was "Meteor-the-protocol" I think we would have been in a much better position.
Elixir/Phoenix is the spiritual successor and includes a potential means of minimizing the need for client-side JS with Live Views.<p>Check out: <a href="https://twitter.com/joerichsen/status/1109122286139965441?s=21" rel="nofollow">https://twitter.com/joerichsen/status/1109122286139965441?s=...</a>
No one here is talking about clients. One of the great benefits of using Rails, Django etc. is that they are stable, very well documented, well supported frameworks with a large ecosystem of libraries and developers. If you are making an app for a client these will generally be much easier to maintain than a bespoke Javascript stack.
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).<p>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.
Anyone know of a BetterErrors equivalent in Node.js with an actual REPL (live shell) like in <a href="https://github.com/BetterErrors/better_errors" rel="nofollow">https://github.com/BetterErrors/better_errors</a>?<p>Or even a pry-remote equivalent?
Check out <a href="https://apollokit.org/" rel="nofollow">https://apollokit.org/</a> for something similar using full-stack JS<p>Sysgears has some other projects that is moving towards the ability to import functional modules from npm
I read your blog and I think that's why we still need Rails to keep other frameworks on their toe.<p>Feature/Improvements introduced in Rails are constantly being picked up by other frameworks but for some reason, people are ignorant about the progress made by Rails in the last couple of years.<p>I use Rails every day at work and trust me when I say this, It is so easy to get back to the code written last week or even last month(Of course Ruby plays a big role in that). It is a big advantage when you do not have to break your head every time you wanna review your code which is written some time back.
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.
It took me a long time to learn rails, it's very magical and makes many decisions for you. If you constantly find yourself disagreeing or fighting these decisions, rails will never be fun. Maybe this is why so many people are against it, but I loved having a framework teach me about why it made these decisions. To me, nothing comes close to vanilla rails app, after you learn where and when to apply certain patterns it's extremely productive and fun to use. You can get so much farther than you probably think if you haven't used it in a while.
I’ve been really happy splitting the difference between rails style server side rendering and full client side JS apps using Django. I can easily build REST or GraphQL endpoints for client side web apps to consume, but I have the ability to easily render out server side templates for more lightweight pages. Add to that that the python ecosystem is great for data science / data engineering tasks so it’s easy for developers with different backgrounds to cross over / reuse data model code between projects/tasks.
I believe we are at a turning point for the future of web apps and servers. After using Firebase and serverless (I hate this term) technologies in the last few, I didn't miss doing all what's said in the blog at all.<p>Need authentication? Just turn the feature on in Firebase and use it. Need storage? Need analytics? Just do the same. The future is bright and we are heading in the right direction. With this, we can get started on our apps with zero configuration and just focus on features.
I could never get into Rails because of all the magic. “It just works” doesn’t cut it for me, if I as an engineer, can’t understand exactly what’s going on under the hood.
Here's how i replace Rails with the "modern stack":<p>- Compile Graphql schema into Typescript typings + Fragments for "Active Record"<p>- React Hooks as controllers action.<p>- React Suspense for HTML rendering.<p>- Apollo for graphql caching<p>- ExpressJS for middlewares.<p>- @reach/router for routing.<p>- @loadable/component for code splitting.<p>- Serverless for API.<p>I missed Rails, too. But i found that the "modern stack" is not bad at all. It just needs more time to investigate to find out the best way to reuse features.
> There’s no longer a standardized way to get user accounts with a login/signup, [...] so instead we need to spend days rewriting this functionality anew on each project<p>I don't think that ever existed "THE standard way" to build web applications. At the same time Rails was trend, for a lot of people the "standard way" to build web systems was write it from scratch in PHP.
I think one big mistake rails did was to tightly couple view side with server side. This made sure tight coupling. If rails had a layer in between controller and html (with a dumber html templating), with this middle layer either spitting html or json apis, we would not need to get rid of rails<p>I too find react etc too complicated for a simple crud kind of app. Rails was much faster to achieve the same.
> The world of tech moves fast, and there’s always new frameworks and paradigms popping up that make developers’ lives easier and allow us to build more and more powerful applications.<p>I wish people didn't start their posts with such proclamations. Why can't one just go ahead and criticize something without first giving it a compulsory doze of praise.
> I’m not suggesting that we give up React and es7 and go back to writing server-templated web-apps like it’s 2012 again<p>Why? What is wrong with that exactly?<p>Has the Internet fundamentally changed over the past seven years? I’d argue it hasn’t fundamentally changed in the past <i>20</i> years.<p>A single-page app isn’t a panacea, and in most cases is a bad choice for a business.
I look forward to a comment section filled with passionate developers rejecting the author's premise, and pitching their favorite framework(s) as proof...<p>Thereby validating the author's premise that "the majority of the problem is just a result of fragmentation in the modern ecosystem."
I don't miss rails. It's there and it's awesome. Can't wait till crystal is far enough so there's better type checking, or for ruby to implement that.<p>And I can't wait for activerecord to be replaced by something like objectmapper.. It makes a lot more sense.
>nodejs / typescript graphql backend and React / Apollo on the frontend.<p>So uh... I run a Rails / graphql backend and React / Apollo frontend. It's not perfect, but I still think it's easier than running a complex node backend by an order of magnitude.
sure, you will miss rails if you are still working on monolith development model (which is still valid in many cases) or if you want to have your Ruby developers who can also do frontend work.<p>These days, frontend has advanced so much that either you are a minority who is truly full stack and can do both backend and frontend work in good competence otherwise, frontend has become a separate profession altogether and for good reason -- it not only requires artistic capabilities, but it requires good amount of coding now with plethora of frameworks/modules.<p>Rails is a great framework no doubt but advent of React/Angular along with rise of microservice-oriented architecture has limited the footprint of rails in job market.
Rails is awesome! We’re hiring Rails devs in 2019 for our startup in Seattle. We found a good balance of React and Rails. <a href="https://www.sharegrid.com/careers" rel="nofollow">https://www.sharegrid.com/careers</a>
Ruby 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?
Not sure why everybody nowadays rule out Rails (or Django) like frameworks. Not every web app need to be an SPA only! There are multiple kind of web apps which I would still start with Django today!
8 years in to my programming career, I still LOVE Rails. No other framework I've come across lets me do as much quality work in a short space of time as Rails does.
So what is the modern front-end equivalent to Rails or Laravel?<p>With clear outstanding options for authentication, image processing, and all the other bits that are commonly needed?
from TFA:<p>> <i>"Now, I know Rails isn’t universally beloved by developers, and I’m not suggesting that we give up React and es7 and go back to writing server-templated web-apps like it’s 2012 again."</i><p>Why not, exactly? It worked well then and it works well now. Not everything needs to be some 10MiB javascript bundle delivered to a late-model version of Chrome served from a static bucket.
There is opportunity for a rails like framework in Typescript and React Hooks which is server-side first.
A lot of the js/react frameworks are rich, client side ..which need a little more conceptual thinking than a server side rendered framework like rails (because you get into unnecessary complexities of API,graphql,her,etc).<p>The other thing that's missing is db migrations - typeorm has decent migrations, so that can be leveraged.
I believe Firebase + React is actually that. Yes, it's buying into a proprietary system, but it is so productive working in that. Database is taken care of, file uploads, authentication etc. are all taken care of.<p>It's not comparable to Rails in that we can't have plugins to install new things that work with the entire stack, but whatever we have initially is really good and I feel makes me very productive
There are tons of JS stacks that exist right now - Sails, Adonis, etc. - but I feel they all miss having a hugely profitable business using them in production. Rails had 37signals use it for all their products - along with having DHH too.<p>Right now you have FRAMEWORKS being used in production at big companies, so if you use React, Angular, etc. you know that you're in good company. I think it would be super interesting having a large company roll out a full stack JS framework that they themselves use.
This reminds me of the Rich Hickey keynote talk[1] at Rails Con 2012. Which boils down to: just out of sheer convenience you no longer own your code and, don't make the easy choice, take your time and make the simple choice.<p>[1]: <a href="https://www.youtube.com/watch?v=rI8tNMsozo0" rel="nofollow">https://www.youtube.com/watch?v=rI8tNMsozo0</a>
As a front-end developer I hated Rails, every day was a struggle working with the project, it was so slow. It was around 4 years ago and I was using top of the line Macbook Pro.<p>Our project wasn't badly written, it was just that slow. Is it better today?<p>I somehow ended up working with PHP-based back-ends but for smaller projects and I sometimes miss Rails, because Docker for Mac...
Oh gawd, not another one of these articles. I appreciate what the author is trying to say, but the premise is just all wrong.<p>Repeat after me: Rails Is A Modern Web Stack. Seriously. You can do everything you might imagine needing to do for a modern web app:<p>Need an easy way to create server-side rendered (SSR) pages that still behave in a performant, snappy manner like all the cool kids? ERB + Turbolinks 5 is a powerful combo.<p>Need to ratchet it up a bit with dynamic interactivity? Slap some Stimulus on that SSR puppy!<p>Still not "modern" enough for you? Use React! Or Vue! Keep Rails operating just as a JSON-flavored REST API.<p>Need to push commands from the server to multiple clients at once? ActionCable to the rescue.<p>Need to offload long-running tasks to background jobs? ActiveJob + Sidekiq is the bee's knees.<p>At any rate, plenty of us are developing "modern" web apps and sites using Rails, Webpack, and other cool frontend tools, and it's going quite well. I don't feel in the least like I'm missing out on something amazing or obvious by sticking with tried-and-true, stable tools that have been my bread and butter for 11 years and counting. DHH's philosophy of web programming may not appeal to everyone, but for many of us, he continues to a voice of reason in an insane world.
It's still small but a "Rails for JavaScript" is exactly what we're trying to build with Vulcan.js: <a href="http://vulcanjs.org" rel="nofollow">http://vulcanjs.org</a><p>Built with Meteor, React, and GraphQL.
This: <a href="http://paulgraham.com/avg.html" rel="nofollow">http://paulgraham.com/avg.html</a> seems somehow relevant to this discussion.
I never liked Rails even when it was hip. Way too much bloat and magic behind the scenes, and also poor performance because of that.<p>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.<p>I cannot say that a Node stack is better though. Both Rails and Node are fairly awful, but for entirely different reasons.
I learnt to program for the Web in the late 90s. I used perl and later php. I stopped in the early 00s because I found supporting IE6 was soul destroying. Much more recently I got into it again and saw things like Rails and Django and was amazed. It was like stepping in a time machine and seeing what I always thought web development should have been. But the whole node, react etc. model is nothing like that. It's a regression as far as I can tell. It just makes everything more complicated for little benefit.