21 ms·

I Miss Rails

• verdverm 8y ago
  Check out https://apollokit.org/ https://apollokit.org/ for something similar using full-stack JS Sysgears has some other projects that is moving towards the ability to import functional modules from npm
  • jamestimmins 8y ago
    This is pretty interesting, (not to mention it's a very aesthetically pleasing page). It seems like we're possibly seeing the rise "meta-frameworks", which simply provide a higher level of abstraction by combining multiple disparate tools. I work primarily on the backend, so this could be incorrect. But I'm curious if anyone else has been aware of this trend, or if I'm identifying something that isn't really there.
• readittwice 8y ago
  Ember? It's supposed to be a Rails-like JS framework.
• ericb 8y ago
  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.
  • chanind 8y ago
    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.
    • jacobsenscott 8y ago
      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.
      • tomaskafka 8y ago
        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 ...)
      • brightball 8y ago
        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.
        • jacobsenscott 8y ago
          I heard someone on the ruby rouges podcast say they got turbolinks to work on Phoenix pretty easily.
    • petepete 8y ago
      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.
• agar 8y ago
  I look forward to a comment section filled with passionate developers rejecting the author's premise, and pitching their favorite framework(s) as proof... Thereby validating the author's premise that "the majority of the problem is just a result of fragmentation in the modern ecosystem."
• BillFranklin 8y ago
  > 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://loopback.io/ https://loopback.io/
  • 0xADEADBEE 8y ago
    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 something done quickly.
    • debuggerpk 8y ago
      for websockets, django has django-channels https://channels.readthedocs.io/en/latest/ https://channels.readthedocs.io/en/latest/ . But I do agree, django has been a little late to this party.
      • 0xADEADBEE 8y ago
        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.
        • uranusjr 8y ago
          Andrew Godwin (the main hand behind the push) burnt out and halted all development until he can find someone someone is willing to help.
          • 8y ago
• inapis 8y ago
  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.
  • jacobsenscott 8y ago
    Nothing at all. But you lose a lot of the productivity benefits of building the whole stack in rails.
    • inapis 8y ago
      True. You’ll loose some productivity but not as much as jumping ship to a complete JS stack. And I’m saying that as a full time JS Dev. The author is completely tearing out rails for JS without giving a solid reason or context for it.
  • splap 8y ago
    That's what we do. Rails mostly just a json api, with a React front end. Devise handles auth. Useful gems in models and services, sidekiq doing its thing... Happy with the setup.
    • eddieh 8y ago
      Why not Sinatra + ORM in that case?
      • DevKoala 8y ago
        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.
        • hombre_fatal 8y ago
          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-started 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
• digb 8y ago
  I’ll say this: I came to Rails from 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.
  • jonahx 8y ago
    Here are two of the most popular books on Rails on Amazon, along with their page counts: "The Rails 5 Way" (1088 pages) "Ruby on Rails Tutorial: Learn Web Development with Rail" (816 pages) Rails is enterprise.
    • ericb 8y ago
      What does this enterprise slur even mean? Is it like saying a band sold out when they had a hit record? Do we only use undiscovered indie frameworks now?
      • jonahx 8y ago
        It means it's everything but the kitchen sink: heavyweight, difficult to learn and use, and full of features you don't need. It has nothing to do with popularity being bad. In general that's good a thing, because support is better (and rails does have terrific support), but it does exert a feature-accretion force.
        • deleted 8y ago
          [deleted]
        • digb 8y ago
          I didn’t mean it as a slur! When I wrote .NET, the applications I was working in were massively large and complex, and so mostly what I was working on was optimizing small bits and pieces, and they allowed me to focus ON optimizing those small bits and pieces, because they were what mattered in that context. Rails let’s me focus on the big picture, because that’s what matters in my current context. Express had me working on stuff that I didn’t REALLY care about/want to know about in the context I was in.
• president 8y ago
  There is a universe where there exists only 1 programming language and only a single web framework. That would be cool to experience.
  • rch 8y ago
    Particularly if it's the universe where literate programming took off.
  • jacobsenscott 8y ago
    Rails and Opal (does anybody use opal?) or clojurescript and clojure might be close.
    • deleted 8y ago
      [deleted]
  • andrenth 8y ago
    In that universe, developers think the universe with multiple languages and frameworks is the cool one.
  • tormeh 8y ago
    There are many languages that work on both client and server. Most obviously JavaScript/Typescript, but also Scala and Clojure. If webassembly really takes off you can add Rust to this list. I'm not sure how a combined framework for server and client side would work.
    • scns 8y ago
      Ocaml with Ocsigen or Bucklescript/ReasonML
    • mvanduyn 8y ago
      Checkout https://hyperstack.org https://hyperstack.org Single framework client and server. Programming in Ruby both sides.
  • quickthrower2 8y ago
• KaoruAoiShiho 8y ago
  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.
  • tim333 8y ago
    It's kind of interesting looking back on "Why Meteor will kill Ruby on Rails"(2013) https://news.ycombinator.com/item?id=6642893 https://news.ycombinator.com/item?id=6642893 article cache: https://webcache.googleusercontent.com/search?q=cache:DnlIzCttYw0J:https://differential.com/insights/meteor-killin-rails/+&cd=1&hl=en&ct=clnk&gl=uk https://webcache.googleusercontent.com/search?q=cache:DnlIzC...
  • cutler 8y ago
    I don't think a Rails equivalent will ever appear on Node.js simply because JS doesn't have a standard library. Rails stands on the shoulders of Ruby's excellent standard library. The two languages are also poles apart in terms of the quality of design. That is always going to impact any JS framework.
• k__ 8y ago
  AWS Amplify is becoming the "Rails" of serverless. It already has impressive code generators for GraphQL.
  • garren 8y ago
    I was just playing with Amplify the other day. I was super impressed with the graphql codegen. I think the Rails comparison makes sense with the exception of the vendor lock-in. I haven’t looked at the Serverless framework very closely, but I know it’s not tied to AWS. I wonder if that’s a better comparison to Rails?
    • k__ 8y ago
      I think the Serverless framework is more backend centric. Amplify has a pluggable interface for different cloud providers, but I guess until Amplify reaches critical market share, nobody will implement the Azure and Google Cloud parts...
    • mooreds 8y ago
      Serverless is more aimed at abstracting infrastructure, with small services written in lambda/cloud functions/etc. So not really a rails replacement.
  • sergiotapia 8y ago
    How do you deal with vendor lock-in? Isn't this just as bad as using Oracle DB?
    • k__ 8y ago
      It's always a quesion of risk. Maybe you go multi-cloud and your AWS only competitors crush you, because you spend money and time on the wrong thing and their one-provider-setup just integrated so well and saved so much time and money. Maybe AWS goes bad quick and you can jump ship with your multi-cloud setup and save your butt while your competitors go down with it. I just don't know :)
• jph 8y ago
  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.
  • 0xADEADBEE 8y ago
    They're fantastic and I hope the future is bright for them but I've had to pick Rails for a few projects over the last few months because the library support is so much more established. The more I get to use Phoenix, the more I am convinced it is the most well designed web framework there is, so I hope to use it a lot going forward.
    • burlesona 8y ago
      Not a coincidence, Phoenix / Elixir originated with Jose Valim, a former Rails Core dev.
    • chessturk 8y ago
      Elixir/Erlang's emphasis on uptime/fault-tolerance/scalability/concurrency (admittedly at the cost of performance and the abstraction of a VM) is perfectly suited to web/mobile use-cases. On paper, Pheonix should be the default choice for large and small web/mobile MVC applications. I think the question of if that becomes the case is directly tied to adoption of Elixir.
      • Jedi72 8y ago
        The performance comparison matters if you start comparing nginx, and maybe even the Go/Rust frameworks, but it absolutely blows Rails out of the water for performance without sacrificing any of the high-level abstraction goodness that makes Rails appealing. No reason not to move to Elixir unless you cant hack functional programming IMO
    • zorbash 8y ago
      Especially now, with the beta release of https://github.com/phoenixframework/phoenix_live_view https://github.com/phoenixframework/phoenix_live_view one can be productive writing interactive applications right off the bat. Rails developers should check this out. I'm stoked about the potential of live view and I'm curating a list of demos of things built with it: https://tefter.io/zorbash/lists/phoenix-liveview-examples https://tefter.io/zorbash/lists/phoenix-liveview-examples It took me a couple of hours to build my first demo with it, have a look: https://youtu.be/tTPH4DyUaUk https://youtu.be/tTPH4DyUaUk and I didn't have to write any JavaScript for it.
• stonewhite 8y ago
  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. [1]: https://www.youtube.com/watch?v=rI8tNMsozo0 https://www.youtube.com/watch?v=rI8tNMsozo0
• matchbok 8y ago
  Couldn't agree more.
• ajsharp 8y ago
  Yep, 100%. In the process of converting a node/typescript API to rails. I'll never make this mistake again.
  • ericb 8y ago
    I'm de-Embering here and going to pure Rails. I'm gonna party like it's 2009!
    • rohan404 8y ago
      To quote the ever popular HTTParty Ruby library: "When you HTTParty, you must party hard!".
  • koolba 8y ago
    You’re going from TypeScript to Ruby? Having tasted the joys of static type checks combined with a unified front/back data model, IMHO, that’s unthinkable.
    • mostlysimilar 8y ago
      > joys of static type checks combined with a unified front/back data model Would you mind elaborating on the specific benefits?
      • Aeolun 8y ago
        100% accurate autocomplete everywhere? As long as you don’t use ‘any’ anyway.
      • koolba 8y ago
        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 expanding APIs which leads to incredible agility in adding features to an existing code base.
• andrewstuart 8y ago
  >> 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 Actually I have gone back to server-template development using Django for selected projects, after many years working with React, which I still love. Server side templated development with Django can be extremely fast in terms of development time, very direct and effective. There no need to use React for all the things. Sometimes React is the right tool, sometimes server side templated is the right tool.
• cordite 8y ago
  For those in the JVM world, is grails good to look into?
  • debug-desperado 8y ago
    Groovy and Grails are still around but probably not as big a push anymore. I would highly recommend JHipster to bootstrap a new Spring Boot app. It does monoliths or microservices and gives you a great scaffold to build on top of.
    • jacques_chester 8y ago
      Spring Boot + Kotlin is a pretty sweet experience.
      • debug-desperado 8y ago
        I bet. After doing the Kotlin Koans I'm itching to get away from Java. There is a JHipster Kotlin blueprint that generates the backend code with Kotlin instead of Java. Can't wait to use it.
    • vips7L 8y ago
      Iirc grails is built on top of Spring.
  • chessturk 8y ago
    I maintain a legacy Grails app, it's memory hungry and brittle. A bug one place brings down all parts of it. I hate it but I'm no Java expert.
  • zmmmmm 8y ago
    The more modern take on it is micronaut [1]. It's a good fit if you are building a SPA + REST API style app, but want the plugin / addon style ecosystem of grails / rails. [1] http://micronaut.io http://micronaut.io
  • joemccall86 8y ago
• lettergram 8y ago
  I still write Rails applications regularly, some applications I've maintained since 3.0 to 5.x. 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. 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... Here's a project I wrote in Rails and deployed late last year: https://hnprofile.com/ https://hnprofile.com/ Works like a charm! I even recommend Rails to new people starting out because I think it sets best practices.
  • styfle 8y ago
    That’s a fascinating tool! Now I realize I need to use more enjoyable words when discussing TypeScript :)
• lxcid 8y ago
  I personally don't missed Rails mostly because boilerplate doesn't really bother me. I'm more afraid of using the wrong abstraction. Rails (v4 was my last experience) was hard for me and I think my reasoning is as follow: - 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. - If you are someone who like to dig deep, the documentation wasn't helpful for me at all. - 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. https://guides.rubyonrails.org/active_record_migrations.html#active-record-and-referential-integrity https://guides.rubyonrails.org/active_record_migrations.html... - 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. 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.
  • kbp 8y ago
    > MVC is a 20 year old pattern More like 40; it's from late 70s Smalltalk.
    • gilbetron 8y ago
      Can confirm, I worked at a Smalltalk firm in 1995 and was taught MVC then, and was explained to how it was an old pattern.
    • e12e 8y ago
      Indeed. The original paper is still well worth a read: http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
• westoque 8y ago
  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. 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.
  • jaequery 8y ago
    it depends on the app as Firebase can be quite slow. could still work for rather simple apps though.
  • burlesona 8y ago
    This is also very expensive very quickly compared to the mileage you can get running an application on AWS. And if you pick a neat tech provider and it goes belly up (like Parse!) you’re in some real pain.
• tombert 8y ago
  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. 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. 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. 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. 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. (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).
  • zrail 8y ago
    Rails auto generates very little these days unless you ask for it.
    • jeremy_k 8y ago
      To note: been working on Rails for 6+ years. I was reading the parent comment and some of the other comments about the mental model of a beginner. I suppose if you're first exposed to Rails and start using 'scaffold' it can generate a ton of code you'll need to grok. But once you understand the nuances of writing Rails its much faster and cleaner to just create files and go about your business. There is only 1 thing I ask Rails to generate for me and its database migrations; it handles adding the timestamp and placing it as the end of the folder, thats not something I care to think about myself.
    • ndnxhs 8y ago
• sergiotapia 8y ago
  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. 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. 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. Maybe with Phoenix LiveView we can get away with _less_ JS - maybe...
  • chusk3 8y ago
    Promise liveview is such a cool concept. I'm keeping an eye on the repo to try to translate the concepts to my languages Pheonix-clone, Saturn.
• meow_mix 8y ago
  The ecosystem around rails was incredible. Really wish we could get something equivalent with a static language
  • burlesona 8y ago
    It’s still alive and well just FWIW.
  • SkyPuncher 8y ago
    Static is my hope too. We started with a Rails project two years ago. It's a bit slow, but dear god we get so much done with it. That being said, having Typescript on the frontend makes it so utterly clear how much better Rails would be with static typing.
• reustle 8y ago
  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.
• reilly3000 8y ago
  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. 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?
  • wefarrell 8y ago
    Agnostic of stack, SPAs provide a clear separation of concerns. The api layer is responsible for transforming data between the client and controlling access. The client is responsible for presenting the data structures provided by the api to the user, and turning user inputs into data structures that the api can consume.
    • enraged_camel 8y ago
      Don’t forget interactivity and real-time feedback for user actions. SSR simply can’t provide that without lots of javascript thrown inside each template, and we all know what that leads to...
      • lytedev 8y ago
        Also check out the newly released Phoenix LiveView!
      • peteforde 8y ago
        I urge/beg you to check out the Turbolinks 5 + StimulusJS libraries, which are by the same (Rails team) people, which is no coincidence. https://youtu.be/SWEts0rlezA?t=203 https://youtu.be/SWEts0rlezA?t=203
        • frou_dh 8y ago
          There's a great podcast interview about the what/why of Stimulus: https://changelog.com/podcast/286 https://changelog.com/podcast/286
• b212 8y ago
  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. Our project wasn't badly written, it was just that slow. Is it better today? I somehow ended up working with PHP-based back-ends but for smaller projects and I sometimes miss Rails, because Docker for Mac...
  • jaequery 8y ago
    have you tried Dinghy? Docker for Mac is exceptionally slow on OSX. i advise everyone to stay away from Docker for Mac and install Dinghy w/ xhyve instead.
  • scruple 8y ago
    You'd have to start by defining some things. Are we talking about AJAX request/response cycles being slow? Are we talking about SSR request/response cycles being slow? What was the app doing, CRUD? Something more interesting? For reference, the Rails app that I am working on, almost literally right now, is responding to HTTP API requests, performing authentication and resource authorization, creating a background job (or 2 or 3), and posting an event to kafka, in 2-3 ms. This is on my work-issued dev laptop from 2016. If I start hitting the SSR portions of this same app, I'm getting response times in the 70-80ms range pretty consistently across the 6 or so pages that I just hit to get a quick baseline. No front-end frameworks here. Just turbolinks, ERb, HTML, CSS, and sprinkles of ES6 (served via webpack(er)).
  • loktarogar 8y ago
    Here's the thing about performance: even "well written" code can be unperformant. It could be a query that isn't optimised with an index in the db, it could be best practice code that doesn't work well in the context of your app, any number of things. At my last job we had a page that looked to be very well written, but it was taking 30+ seconds to render the page. Turns out to be a method we were calling 10x too many, because someone had benchmarked it in isolation and it didn't have any performance impact. However in conjunction with some of the data that occasionally passed through that method, those 10x calls ended up being a couple of seconds each. That's an extreme example but there's little things you can do everywhere on a rails app if you know what you're looking for, and I would expect this to be the case in any web framework.
• revskill 8y ago
  Here'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 not bad at all. It just needs more time to investigate to find out the best way to reuse features.
  • rsanheim 8y ago
    Your post is a perfect example of why the "modern stack" is a horrible developer experience (and lets be honest, probably crummy user experience) compared to Rails.
    • revskill 8y ago
      You're absolutely correct at current moment. I hope the DX will get better soon. But this stack beats rails on scalability, universality, user experience, and many more. It's a trade-off that i found worth the effort.
  • wzy 8y ago
    ... you had me up until "Serverless".
    • revskill 8y ago
      Actually, this stack is deployed as a serverless function ! "Serverless for API" means i could use any language to develop API. Serverless provides better scalability in my opinion.
      • cagmz 8y ago
        Do you have any code samples for this? Sounds interesting.
        • 8y ago
• hezag 8y ago
  > 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 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.
• ashelmire 8y ago
  >nodejs / typescript graphql backend and React / Apollo on the frontend. 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.
• jaequery 8y ago
  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.
  • burlesona 8y ago
    If you really like Ruby but don’t love the “magic” side of Rails, you should try Roda and Sequel. The whole ecosystem built by Jeremy Evans is a joy to work with.
    • jaequery 8y ago
      I actually like working with plain Sinatra and Sequel. I've created something similar to RoR using it (github.com/jaequery/jasis). As for Roda, idk why but it just doesn't click with me.
  • chessturk 8y ago
    Why is it hard to dismiss Node? Do you mean business environment-wise?
    • jaequery 8y ago
      I am just concerned about the Ruby/RoR talent pool shrinking year by year.
      • Nextgrid 8y ago
        Python is going strong, so if Ruby talent is an issue Django can be an alternative.
• neovive 8y ago
  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.
• jaequery 8y ago
  Anyone know of a BetterErrors equivalent in Node.js with an actual REPL (live shell) like in https://github.com/BetterErrors/better_errors https://github.com/BetterErrors/better_errors? Or even a pry-remote equivalent?
• vmware513 8y ago
  Actually, Ember.js gives you the same experience for frontend development than Rails for backend. So you can stay happy and productive. ;)
• endlessvoid94 8y ago
  Every time I dip my toe into the node.js waters I recoil in horror at the complexity of the defaults.
  • wzy 8y ago
    I can fondly remember me trying out a Node-based framework back in the day and deciding it wasn't for me because I couldn't decipher an error that was halting the application. Then, I decided to delete the folder. I remember watching Windows building the list of about 1GB+ of files to delete. Only to have it try but couldn't complete the deletion process because some file names were too long because of the recursive nature of folders and dependencies in `node_module`. Good times!
• sixothree 8y ago
  > Do you need user accounts with signup / login / forgot password emails / email confirmation? Install devise and you’re done. 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...
• viksit 8y ago
  "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. This post rings true. 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.
  • pault 8y ago
    I'll bite. One, I'm not sure next.js is the right tool for a simple dashboard. Seems a bit overkill. I think some simple MVC pages with vue dropped in where necessary would be a better fit. Also, your last sentence sounds like you're saying that it's not usable unless you know how to use it.
    • viksit 8y ago
      For completeness - the goal was to create a dashboard that could actually utilize SSR as we scale it up to larger amounts of traffic. The last sentence was written to mean that unless you go in and spend a LOT of time reverse engineering code from a myriad examples, it's almost impossible to get a working implementation.
• rubyfan 8y ago
  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> Yuck.
  • chessturk 8y ago
    The similarity of Hack and TypeScript support your argument.
• namelosw 8y ago
  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. Until now I use it every day and I found it's really great and better than my previous impression: 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. 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.
  • baroffoos 8y ago
    >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. This is so important. When doing something on rails you always get instructions on the exact things you have to do where as JS always seems to either give you 500 different versions of the instructions or just expects you to work out how to set it up based on everything else in your project.
    • mikewhy 8y ago
      I mean, we're comparing languages to frameworks here. Of course there's going to be multiple different solutions for a language while a framework will have fewer.
• sgdesign 8y ago
  It's still small but a "Rails for JavaScript" is exactly what we're trying to build with Vulcan.js: http://vulcanjs.org http://vulcanjs.org Built with Meteor, React, and GraphQL.
• davidbanham 8y ago
  I 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 loads up all its libraries and state. 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. 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.
  • GuiA 8y ago
    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 years similarly, and when react/ember/angular/etc. started blowing up is when I started feeling like performance was something we had to worry more about. That being said, server side rendering shows its limits when you build an application with lots of actions your users can perform on the data shown in their window, and reloading the page every time would significantly slow them down. That's when you're tempted to start going the SPA route, but those frameworks tend to be pretty opinionated about how you should structure your code and data, a slippery slope that leads to the stereotypical bloated, unresponsive JavaScript mess some websites have become famous for. There is certainly a balance to be found, but it's a tricky one.
    • davidbanham 8y ago
      It depends on the application of course, but some of them do end up sprouting a bunch of little "quality of life" JS functions. Writing these is happily a much simpler experience than it was in 2012! The most complex app I run also has the deepest browser support requirements, back to IE11. That said, I still have document.querySelector in all my target browsers so I find I don't even need jQuery. For autocompletion, datepickers, etc I use drop-in components. These tend to be jQuery based but it's not the end of the world. When I do have a particular view or flow that outgrows the "bits and pieces of JS" phase it's actually pretty straightforward to use a modern UI library like React or Elm on that view alone. Reducing the scope of the area you're using the framework in rather than writing the entire app in it simplifies things pretty dramatically. The JS doesn't need to worry about routing, pushState, etc etc etc. It just deals with its own little patch of DOM and state.
• ravenstine 8y ago
  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. 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.
• asattarmd 8y ago
  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. 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
• rajangdavis 8y ago
  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.
  • digitaltrees 8y ago
    gorails.com and driftingruby.com
    • thrownaway954 8y ago
      Can't recommend driftingruby enough... that site is AMAZING
    • excid3 8y ago
      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!
• kristianp 8y ago
  Looking for the Rails of the modern web stack? Try asp.net core api + AngularJS! /sarcasm. Sigh.
  • james_s_tayler 8y ago
    Close. https://aspnetzero.com/ https://aspnetzero.com/
• ernsheong 8y ago
  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. 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. 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".
  • hombre_fatal 8y ago
    I tend to describe my issues with Rails in a nutshell: it felt like everything was optimized for day 0 instead of day 30 or 300. Devise was the ultimate example of this. `rails generate devise:install`. Instant authentication system with almost zero changes to your code base. Yet now something as central and important as authentication is implemented outside of your application in some highly abstracted software. To do something as simple as figure out the name of the cookie it sets, you have to either dive into its internals or look at the actual cookie it sets instead of just reading code that should've existed in your code base. Rails was the first "language" I learned so I was its best case subject. It was able to indoctrinate me in the beauty of metaprogramming and things like that. Yet that still wasn't enough to keep the light from shining through the veneer when working on a real world projects where you just want to know how something works by reading application or glue code, not daisy chaining through a bunch of library code or hoping you cache-hit the library's FAQ so you don't have to deep dive. There seems to be a lot of "why is there no Rails in {JS,Go,Rust,Clojure,...}" lately and it's no surprise to me why there isn't. The same reason Ember and Meteor never took off to the degree that React did. There was some sort of "glue code just isn't that bad" renaissance.
    • JohnBooty 8y ago
      > Rails was the first "language" I learned so I was its best case subject. It was able to indoctrinate me in the beauty of metaprogramming and things like that. Yet that still wasn't enough to keep the light from shining through the veneer when working on a real world projects where you just want to know how something works by reading application or glue code I think the hidden magic is the worst part, but after a while I got pretty good at simply diving into various gems to see where the magic's happening (or failing to happen) and I don't mind that aspect now. pry is an awesome tool. Put a `binding.pry` breakpoint in your code, do a `show-source Foo.borked_method` and explore from there. Also, popular Rails-related gems tend to have good tests. I learned that those tests often demonstrate things that the docs don't.
• draw_down 8y ago
  I don’t understand why you would directly compare two things like React and Rails. They solve different problems. You could use both, if you wanted.
• haney 8y ago
  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.
• blacksoil 8y ago
  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. 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. 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. 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.
  • RyanShook 8y ago
    As a beginner, Rails seems much easier to get from zero to something. So much of the tutorials I’ve seen on react are about dependencies and environment setup. I know React has some big advantages but on smaller teams/projects it’s hard to see the benefit.
• lgregg 8y ago
  I'm currently building an app using Webpacker and Rails 6 edge, it's been great.
• jasonhansel 8y ago
  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.
  • jasonhansel 8y ago
    Especially with the ability to build apps that require minimal client side JS (e.g. Intercooler.js).
  • AgentME 8y ago
    Next.js is pretty good, but could still be better.
    • jasonhansel 8y ago
      I'd like something focused on pure server-side rendering, so that users can have at least some interactivity (via <form> elements) without JS.
      • AgentME 8y ago
        Next.js pages do work for people without javascript too, and it's often paired with something like Express that can handle form post submissions. The Next.js+Express integration could be made smoother though.
  • mvanduyn 8y ago
    https://hyperstack.org https://hyperstack.org
• codesushi42 8y ago
  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. 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.
  • bushido 8y ago
    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.
  • mvanduyn 8y ago
    Why do people not like Magic??? Any modern language is pretty magic. Think about what is going on with Javascript JIT, or even Ruby. Its pretty crazy magic. And its not actually magic, its just abstracting out details.
• vincentmarle 8y ago
  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.
  • JohnBooty 8y ago
    After Rails' memory usage, I would say that the "magic" is the worst part of Rails. Wish I could have Rails, except a bit more explicit. That said, with pry, it's pretty easy to dig down into the "magic" and see wtf's going wrong when something is borked. Despite that minor grumbling, I'd say that Rails is still darn good! It's very mature framework (or perhaps more accurately, collection of frameworks) at this point. You can get stuff done quickly. Most things really don't need to be SPA, and many (most?) don't need to serve up more than a few hundred or a few thousand responses per core per second.
• mnm1 8y ago
  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.
• rebhdm 8y ago
  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. 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. 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.
• rohan404 8y ago
  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?
  • favorited 8y ago
    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.
  • jeremy_k 8y ago
    Been following TruffleRuby, I did recently just spin up a super dummy app where I swapped out mysql to postgresql, made a migration to create a table and generated some fake data. Opened a console and ActiveRecord was able to query. Thats a big step forward as they had said the ActiveRecord connections were some of the biggest hurdles. Does this story answer your question about performance? Not really, but if I wanted to dive deeper (which I do at some point!) I think TruffleRuby is a real option.
• throw2016 8y ago
  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. 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. 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.
• codyeatworld 8y ago
  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.
  • herbst 8y ago
    When I first looked into Rails I ended up learning Ruby because it was so fun but Rails was overwhelming. After I got Ruby I found sinatra and my fascination to use Ruby for the Web was finally born. After that I discovered Padrino. Essentially sinatra packed with a ORM and backend. When I then looked into Rails again (years later) everything felt so natural and right suddenly. However beginner documentation also got a lot better so this was surely part of it.
• davidscolgan 8y ago
  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.
  • joelbluminator 8y ago
    Rails developer here. I did Django for 6 months and nothing bad happened, it's a sane, mature, solid framework. Ruby/Rails feels nicer to me but Django is super solid. Also, a senior Rails developer can become very productive in Django in a matter of months (and probably vice versa) so it's not as if it's two worlds apart.
• novon 8y ago
  Rails is awesome! We’re hiring Rails devs in 2019 for our startup in Seattle. We found a good balance of React and Rails. https://www.sharegrid.com/careers https://www.sharegrid.com/careers
• fouc 8y ago
  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?
• brentm 8y ago
  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.
• hardwaregeek 8y ago
  Seriously, do people like 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). 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. 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.
• sandGorgon 8y ago
  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). The other thing that's missing is db migrations - typeorm has decent migrations, so that can be leveraged.
• laurentdc 8y ago
  > 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. 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?
  • epse 8y ago
    No. Your solution works and makes people happy. That's fine
• randomacct3847 8y ago
  You can use rails just as a backend. React, GraphQL, and Rails works fine from my experience
• rco8786 8y ago
  Rails is still very much alive and popular, this is kind of a weird take. Server rendering is also very much still a thing. But 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.
• dpods 8y ago
  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. 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.
  • aosaigh 8y ago
    I think you're missing the point. Rails == Lavarel == Django in the context of the discussion.
• monksy 8y ago
  I miss Grails.
• piyushpr134 8y ago
  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 I too find react etc too complicated for a simple crud kind of app. Rails was much faster to achieve the same.
• jaredcwhite 8y ago
  Oh gawd, not another one of these articles. I appreciate what the author is trying to say, but the premise is just all wrong. 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: 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. Need to ratchet it up a bit with dynamic interactivity? Slap some Stimulus on that SSR puppy! Still not "modern" enough for you? Use React! Or Vue! Keep Rails operating just as a JSON-flavored REST API. Need to push commands from the server to multiple clients at once? ActionCable to the rescue. Need to offload long-running tasks to background jobs? ActiveJob + Sidekiq is the bee's knees. 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.
• joduplessis 8y ago
  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. 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.
  • yakshaving_jgt 8y ago
    This is an example of the Appeal to Authority logical fallacy. Just because Google wrote Angular, doesn’t mean it’s good.
    • joduplessis 8y ago
      That's not at all what I'm saying.
  • joduplessis 8y ago
    Wanted to correct this to FRONTEND FRAMEWORKS.
• groundCode 8y ago
  I think Rails is a good framework. What absolutely sells it to me is Ruby. I was a miserable C# developer. Now I’m a happy Ruby developer.
• yakshaving_jgt 8y ago
  > 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 Why? What is wrong with that exactly? Has the Internet fundamentally changed over the past seven years? I’d argue it hasn’t fundamentally changed in the past 20 years. A single-page app isn’t a panacea, and in most cases is a bad choice for a business.
• perfunctory 8y ago
  > 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. 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.
• ai_ia 8y ago
  I have been dabbling with Elixir + Elm. This can be the next big thing, once live view gets wider adoption.
• jbverschoor 8y ago
  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. And I can't wait for activerecord to be replaced by something like objectmapper.. It makes a lot more sense.
• sjellis 8y ago
  I think that Buffalo is actually the most credible replacement for Rails that I've seen: https://gobuffalo.io/ https://gobuffalo.io/ 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. You don't need advanced syntax in the server code to write Rails applications, so Go may be a good fit for a Rails replacement.
• thrownaway954 8y ago
  I keep looking at C# and Blazor myself 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. https://www.youtube.com/watch?v=SWEts0rlezA https://www.youtube.com/watch?v=SWEts0rlezA
• aosaigh 8y ago
  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.
• vasilakisfil 8y ago
  EmberJS with its addons is very similar to Rails productivity. React has some pretty good drop-in components as well, but mostly are related to UI.
• maxehmookau 8y ago
  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.
• Aks21 8y ago
  I read your blog and I think that's why we still need Rails to keep other frameworks on their toe. 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. 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.
• sneak 8y ago
  from TFA: > "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." 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.
• olavgg 8y ago
  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. 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 everything. And many of them is of really high quality too. 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. 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.
  • lame88 8y ago
    You may gave gotten into Grails at a better time. I more recently attempted a project in Grails and it was a disaster. In fact it was my worst framework experience ever. Mainly because completely inadequate sources of information. Grails 3 had been released but the documentation was terribly incomplete so we had to spend a lot of time searching and about every bit of info we tried to look up returned results strictly for version 2. So some really basic things we just never figured out how to do. I’ll never touch it again.
    • olavgg 8y ago
      I have used Grails since version 0.42 and I am a bit surprised to hear that the documentation has been incomplete. I have always found it very detailed, though sometimes lacking clarity as any framework documentation would have. Since the early days, the way you build Grails application has been almost identical to how you write and structure your code with the upcoming 4.0 release. Of course if you have used some plugins that has been unmaintained, that could have caused issues with upgrading. But otherwise I have had a great experience through Grails lifetime. And if you really needed to get "out of Grails", there has never been an issue using the Spring MVC api or Spring Boot with Grails 3+
• almostarockstar 8y ago
  If I understand the situation correctly: Rails applications benefit from batteries included boilerplate because Rails "owns" the whole stack. "Modern" (contemporary?) JS applications benefit from separation of concerns, and flexibility because each layer is interchangeable. 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. 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. 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.
  • mvanduyn 8y ago
    I'm sorry but I am saying this all over the place on this thread. https://hyperstack.org https://hyperstack.org is a logical successor to meteor but it uses Ruby (instead of JS) and Rails on the backend. However its a complete integrated isomorphic stack.
    • grzm 8y ago
      > "I'm sorry but I am saying this all over the place on this thread." Please stop. At this point you're spamming. It's great to be excited about a project, but you're gone beyond that now.
      • mvanduyn 8y ago
        I'm trying to delete these but I don't see how. Sorry
• nuskin9091 8y ago
  ok
• rglover 8y ago
  https://phoenixframework.org/ https://phoenixframework.org/ + https://elixir-lang.org/ https://elixir-lang.org/
• ckluis 8y ago
  Elixir/Phoenix is the spiritual successor and includes a potential means of minimizing the need for client-side JS with Live Views. Check out: https://twitter.com/joerichsen/status/1109122286139965441?s=21 https://twitter.com/joerichsen/status/1109122286139965441?s=...
• djaouen 8y ago
  This: http://paulgraham.com/avg.html http://paulgraham.com/avg.html seems somehow relevant to this discussion.
• jbverschoor 8y ago
  I guess the number of comments show how much love rails is still getting
• bobblywobbles 8y ago
  I agree.
• 0_gravitas 8y ago
  I haven't used rails myself, but I often hear that Phoenix is effectively Elixir's version of Rails.
• JakeWesorick 8y ago
  We use Rails with the GraphQL gem and React/Apollo on the front end. Works great!
• black-tea 8y ago
  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.
• m23khan 8y ago
  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. 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. 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.
• kissgyorgy 8y ago
  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!
• xutopia 8y ago
  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.
• digitaltrees 8y ago
  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.
• mvanduyn 8y ago
  I take modern to mean: Using latest state of the art techniques to increase programmer productivity and happiness. Rails is still the number 1 backend framework, and the RoR ecosystem is so powerful that the https://hyperstack.org https://hyperstack.org 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.) You get all the maturity of rails, including be able to use Rspec to test your server and client code in an integrated fashion. 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: https://medium.com/@mitch_23203/the-exact-same-app-in-hyperstack-part-ii-5b062074ec20 https://medium.com/@mitch_23203/the-exact-same-app-in-hypers... If that is not "modern" I don't know what is. 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.
• deleted 8y ago
  [deleted]
  • deleted 8y ago
    [deleted]
• pythonwutang 8y ago
  Try Django Rest Framework with React