181–190 of 264 posts
Earlier quoted context omitted.
I agree with a lot of what you've described, but 7 years of working in Rails and you never figured out how to turn off lazy loading in ActiveRecord?
I know how to preload associations, but I don't know how to globally disable lazy loading of associations. Do you know a way?
I spent a couple of years dreaming of getting paid to work in Ruby and Rails and about 7 years doing so. There are many things I loved about Ruby, and Rails brought a ton of good ideas to web development, as this post describes (though I don't agree with all the highlights). I've since moved to using Elixir and Phoenix, and then even more recently, done some consulting on a Rails project. So the contrasts are on my m…
Hey, I am so glad to hear this. My sentiments are somewhat similar. My Elixir project didn't get traction so I am back to Rails and some other tech, but definitely Elixir is the future. Now as far as Rails go, this can be my super power. I see a lot of Nodejs project struggle and reinvent things that people in Rails community take for granted. Like Nuxt.js for example.
If you don't have to write code to deal with the computer pausing your unix process to run a different one, and you don't have to write code to deal with the VM pausing your code to run garbage collection, why would you have to explicitly write code to deal with a pause for IO?
I think Rails is fine. It gets you up and running super fast. GitHub, Heroku, Basecamp etc. run on Rails and they are doing great. It's popular because it's relatively 'low-code' than other language/frameworks. Ruby is quite simple to get started with and Rails' convention over configuration philosophy gives a lot out of the box. Having said this, it's not all rosy. Rails does buckle under scale, hence LinkedIn and T…
It also becomes difficult to refactor if you don't have a very good test suite. From personal experience, refactoring an Elm application is way way easier and more error-free than refactoring a Rails app.
Earlier quoted context omitted.
Having worked with many different languages and frameworks over the years, I have to disagree: when creating web applications, starting from scratch or from a minimal base is massively slower, more error prone and less safe than starting from a well developed and maintained framework, where so many of the things you're going to need have already been solved and battle tested.
A summary of my experience would be: libraries are good, frameworks are bad. (Indeed possibly the best "framework" I ever used was TurboGears which is very deliberately just a collection of dedicated libraries, all of which you can replace piecemeal as and when you need to). Rails raised the bar for how little custom configuration should be necessary to do a simple, straightforward thing. But it turns out being a fra…
Especially in the JS world, I could really feel a "library fatigue" when I had to evaluate so many different alternatives.
But for me these days, there's very little difference between stacks as to "what's better". For me it's mainly "best tool for the job and who are are your carpenters?"
But these days, NodeJS seems to be the right choice for many of these jobs and it's hard to sit here and knock it. Why?
Unfortunately, Rails suffers from what a lot of other Web stacks suffer from -- the browser requires some level of JavaScript marshalling that all the other stacks have transform to. When you can code on the server and on the client in terms of the same language. It just makes the process cleaner and far more manageable. When an object on the server is the same as the one on the client. Your life just becomes a little less stressful.
And I love other stacks. I'm a Python fan.
But It's really hard to not embrace NodeJS when you've got developers who work on the frontend (Maybe in React, Vue, etc.) and server developers who are on NodeJS and they can speak together, moreover, work within each others codebase and not kill each other.
That doesn't mean Ruby is a bad stack, it just means like all the other stacks, you have to move data between the backend and browser and it's "Oh, I need this change on the server, I'll have to wait for..." -- no, you can do that, if you've got the ability to code in JS, and you're a fullstacker, you can do both.
I think for what it is - for its paradigm if you will - ruby on rails is an extremely well-designed platform. But I think things have moved on and what was back then seen as the right way (or just fresh new way) is now seen differently. For example - is it really "better" to say 7.even? rather than isEven(7)? (Strict OO vs multi-paradigm/functional programming). Or is the article's example of a data model migration r…
Not every app needs to be or should be a SPA. IMHO, unless you're creating an actual web application like Pivotal Tracker or Google Docs or etc, then maybe you should go with meat and potatoes server-side rendered html and javascript.
Recently I went the other way and built something with Flask because I felt I only needed something tiny (plus python and ruby are both friendly to read) and kept hearing the negatives about monoliths. It started out refreshing because I only added in what I needed but eventually this started to get a bit annoying as it grew, I felt I was rewriting the wheel often, and I missed the organization and forced convention of Rails. Not to mention gems seemed to have more support and often were more recently updated compared to flask imports. I now want to convert this over to a Rails application.
I think a lot goes into picking what to use, size of team, size of users being served, verasility, and development productivity. It's not always only performance at massive scale (you may never need to handle the traffic Twitter does and if you do I think you're doing pretty well and can weather that storm).
Earlier quoted context omitted.
Having worked with many different languages and frameworks over the years, I have to disagree: when creating web applications, starting from scratch or from a minimal base is massively slower, more error prone and less safe than starting from a well developed and maintained framework, where so many of the things you're going to need have already been solved and battle tested.
> starting from scratch or from a minimal base is massively slower This isn't the better alternative to frameworks. The better alternative is using libraries and optionally a bootstrap code generator, which is not at all "starting from scratch". The major difference is that you tell the libraries how to work together, rather than the framework telling you how to work. Some frameworks become like a terrible DSL that y…
I was specifically answering to the remark from the what was at the time the top comment, saying that starting from Rack is the best approach.
Earlier quoted context omitted.
better than postgresql? and what would that be?
Depends what you were trying to achieve with it; for the various things I've seen it used for a mix of protobuf-in-flat-files, Cassandra, and Spark.