My time with Rails is up - <AUTHOR> <comment><USER5> > Now, this line of code is not simple, it's easy to write it, but the code is > extremely complicated under the hood because:

Every time I hear someone complain about Rails, I ask myself if this person is really just complaining about how complex web dev is. I've never seen a complaint that passed this smell test.

Yes, Rails abstracts over a veritable shit-ton of complicated domains. The problem is, that complexity isn't going to go away if you decide not to use those abstractions. Every single one of that laundry-list of things that ActiveRecord::Base.create does will have to be implemented again, by you, badly, if you choose to roll your own.

It boggles my mind why developers don't take the web seriously as a domain, like it's not real coding or something. It's the worst instance of bike- shedding I've ever seen.

Rails isn't perfect, by any means. But Rails is not a black box, it's all free software. You are more than free to re-implement anything Rails does yourself and release it as a gem. Modularity and flexibility are built right in. It seems incredibly odd to leave Rails over this. For what, Java? Unbelievable.

<comment><USER6> Try setting up rails dev on a windows environment and get back to me.

<comment><USER7> I think the majority of webdev tools are pretty tedious to set up on Windows without cygwin etc.

<comment><USER8> Flask is no problem, Django is child's play to setup.

<comment><USER9> I feel like that's because someone put a lot of time and effort into making Python's core library play nice on Windows, and Pythonistas tend to interact with the OS/network only through core library functions.

To contrast, Elixir runs on Windows. However, it may be hard to get all your projects up and running due to various baked in concerns where they were written to support Unix-like systems only.

</comment></comment></comment></comment></comment><comment><USER10> If any of the frameworks glorified on HN were subject to the same scrutiny as Rails, Github would need a suicide hotline.

I've recently had the pleasure of working on a new, medium-sized node/react project. Now I was new to a lot of the technology, but I've learned a few and would think I have some experience.

It probably took me a week to get webpack running the way I wanted. The documentation is an atrocious mix of stuff that is outdated (older than 6 months) and stuff that's too new (webpack 2.0) without any indication as to the validity. There're six different ways to get hot reloading/replacement to work, with similar problems. The configuration's syntax is heavily influenced by brainfuck with a /\w/[{\\[]/s thrown in for good measure. As a soothing measure, webpack doesn't complain about anything but parse errors with the configuration. The version I was using came with 12 different options to render source maps, none of which worked in chrome (since fixed).

And that's just the linker. I actually had presets to search for, i. e. ["express.js" from:<date-of-last-stable-release> to:<date-of-following- alpha/beta-release>]. node_modules once managed to consume 4TB of hd space (someone managed to create a circular dependency) and even in regular use gets to the point where I'm looking for the elasticsearch plugin for ls *<x>. If you have checkouts of several versions or projects, each one will have it's own version of left_pad & friends at around 230MB (just checked with a clean install of mxstbr/react-boilerplate) with no way of deduplication.

I enjoy playing with new technology (currently elm & swift) but I know that it's time "joyfully wasted" right now and don't try to justify it. There's no amount of type-safety bugs that could cost as much time as a new framework's kinks.

<comment><USER11> The most used frameworks are always the most complained about.

It's an easy mistake to think that means they're the worst.

<comment><USER12> While that's true, why don't we see this sort of stuff with Django or Flask?

Of course we see people complain about these tools, but my impression is that people who end up leaving those communities are rarely because of community issues (more like "I'm going to do some Go instead"-style things)

Surely something is different. It's not like Django is unused...

<comment><USER13> Rails is at least an order of magnitude more widespread than Django/Laravel/any of its imitators. If you take a swing at any of the follow- ons, its proponents will invariably say it's just doing what Rails does. Try to imagine a "Why Django sucks" flamepost garnering anywhere near the attention that the same does for Rails... yeah, won't happen.

<comment><USER14> Rails is several percentage points more widespread than Django, but far from any order of magnitude.

</comment></comment></comment></comment></comment><comment><USER15> I used Rails mostly for small or medium sized projects, one or two developers teams, all of us freelancers. It's the perfect tool for this kind of work. We can deliver quickly, send invoices, move on to something else or come back later to add features.

Do projects get complicated? Yes, some of then. Mainly because most customers pay for features and not for refactoring or design, which they don't understand (remember, no in house technical staff). Try to sell them a new page with attached the price of a major refactoring... good luck with that. So sometimes features get kludged together because of budget constraints. I have projects with suboptimal UX (understatement) because they rationally decide to make tradeoffs between usability and costs. It's their privilege. I bet this would happen with any language or framework. Your customers could be more long sighted than mines, I hope they are.

So, would I move away from Ruby and from Rails? Yes, when customers won't like starting a project with Rails anymore. This means that other tools don't have to cost them more. Do I care about Rails architectural shortcomings? A little, but I appreciate its shortcuts more. They work well in my projects.

<comment><USER16> This is my takeaway from Rails. Good default for your 1.0. Frankly, I would probably use Rails even if I was starting a startup. It's easy to hire, easy to talk about. Heck you will often find graphic designers who have played with Rails.

Choosing Rails will definitely lead to problems in the long run, but at least they are well understood problems. You're going to do an in-flight replacement of your 1.0 eventually anyway. You just need one grayhair on the team to steer the younglings away from the worst abuses and you'll have a stable, if clunky, platform to build on. It's the definition of mitigating risk.

Java and C# are of course equally boring, but I think the fact that Rails is culturally open source provides a huge benefit over them.

JavaScript, Go, Haskell, etc are arguably better if you really understand them, but they're research projects. Lots of great pieces of code, but the story of how to use them together is still being written. I would use one of them if my intention was to hire slow and keep my dev team fewer than ~30 people in the long term.

<comment><USER17> What you're missing (at least with Node.js/Javascript) is that Node does not aim to be Rails. Node doesn't aim to have one correct way of doing one thing as Rails often does. Yes, there are best practices, but Node aims to give the developer the freedom to do things as they need to.

The result of this is that, yes, development of your standard CRUD app is probably not as fast as it would be with Rails. Also, moving from project to project is not as easy as it would be with Rails. But the advantage is that, if you have good developers who are good at architecting (a big if), you architecture will better reflect the problem at hand.

<comment><USER18> > The result of this is that, yes, development of your standard CRUD app is > probably not as fast as it would be with Rails. Also, moving from project to > project is not as easy as it would be with Rails. But the advantage is that, > if you have good developers who are good at architecting (a big if), you > architecture will better reflect the problem at hand.

And if you just want something to work quickly, Rails wins. JS encourages developers to spend days and weeks on picking each part of a framework for an MVP that may go nowhere. Rails is no longer the new shiny and it has moved into the 'get shit done' category of developer tools.

</comment></comment></comment></comment><comment><USER19> I can't take his opinions too seriously because his 3 central gripes, which he wrote extensively about, boil down to:

1) Too much complexity is hidden by simple interfaces

Those simple interfaces make programming enjoyable and don't break, so...

2) Your app logic is going to be too tightly coupled to core Rails features like AR, helpers, controllers ("your app is Rails")

Yes, you are in fact using the features of Rails when you use Rails. Is this actually a problem?

3) ActiveSupport. "No actual solutions, no solid abstractions, just nasty workarounds"

ActiveSupport has saved me bajillions of hours and never broke anything for clients. I wasn't aware it was such a flawed library, if it is?

Rails is maximized for developer happiness by, among other things, making things simple (yes, which to a large extent means hiding complexity), giving you a bunch of Omikase core features that you can in fact use, and gives you a lot of sugary methods for handling things that are tedious. I understand people wanting to try other things and leave Rails, no problem with that, but his stated reasons reveal a lot more about him than about Rails.

<comment><USER20> > Those simple interfaces make programming enjoyable and don't break, so...

If they don't break for you, then use Rails. I find that they break _all the time_.

Hint: What does "validates: :unique" actually do?

<comment><USER21> There an info box calling this out in the Rails Guide for Validations.

<comment><USER20> I don't see an info box for the issue I'm thinking of. Are you thinking of the case sensitivity issue?

[http://guides.rubyonrails.org/active_record_validations.html...](http://guides.rubyonrails.org/active_record_validations.html#uniqueness)

The expectation is that "validates :field, uniqueness: true" would validate that the value of the indicated field is unique among all rows in the table. However, this abstraction breaks spectacularly. Any web application, even a Rails app, is usually run over multiple processes, often on multiple different hosts. Uniqueness validation does a non-atomic check and set, which is a known race condition in this kind of environment. The guide does say:

> ...it may happen that two different database connections create two records > with the same value for a column that you intend to be unique. To avoid > that, you must create a unique index on both columns in your database.

But what actually happens when we do this? The race condition where you would otherwise get non-unique values inserted into a column of unique values is instead a race condition where a database adapter throws a generic exception for "the DB complained" with an error message about a failed constraint, and your site throws a 500. Your only recourse is to capture an overly generic class of exception that's thrown by e.g. the MySQL adapter, pattern-match the exception text for a magic string like "uniqueness constraint failed" depending upon which DB you're using, and write your own custom code to recover from that.

That's right: Rails has adapters for MySQL, PostgreSQL, etc, but "adapting" different SQL variants to ActiveRecord doesn't go as far as turning constraint failures, lock wait timeouts, etc. into generic, application-intelligible exception classes. The entire point of ActiveRecord is that your application code should be portable between SQL variants--hell, it shouldn't even have to _know_ what SQL variant it runs on!--but between having to write your own SQL for any use case other than "let's deal with a result set as an array of ActiveRecord objects" and this nonsense, no real-world Rails application achieves this.

In other words, something that Rails pretends happens in one line of code does not actually happen at all, and to make it actually happen, you have to write a whole bunch of code that has to resort to string-matching a bucket exception class for "the DB complained" for the specific exception text that your particular DB engine throws. This is probably the worst example, but it's illustrative. Rails provides the illusion of simple interfaces and enjoyable programming. After working in Rails for just a few years, though, the illusion has vanished for me and I spend far too much time asking questions like "how the fuck did THAT get set to nil?" and "what does does it take to turn this multiline string of raw SQL into objects I can actually use?".

Honestly, I don't want to come across as too harsh. The sad truth is that nothing is perfect, and if you focus on the imperfections, all software pretty much just sucks. But Rails actually tries to convince you that it doesn't suck, that it abstracts away the complexity for you, and that you don't have to worry about it yourself, leaving you ill-prepared for the reality that it's still there and you do have to worry about it.

<comment><USER22> So given your rant, does any ORM cater for this condition better?

Does any web framework manage these? Given two almost identical requests that cause a race condition most frameworks fall down in my experience.

<comment><USER20> There are some ORM's where you define the schema in the application code and it alters the DB schema on the fly, but that seems dangerous, too.

What I would do, given Rails' existing framework of "programmatically discover the table schema and magically generate logic from it", is set it up so that it observes uniqueness constraints and programmatically adds the validation when found. Also, the adapters should interpret server error messages, throw a custom exception class for "uniqueness constraint failed", and ActiveRecord should catch this exception class and turn it into a failed validation when you attempt to save a record.

If that's too much work, just be fucking honest, remove the uniqueness validation (because it's completely useless), and be upfront with us that we have to roll our own solution for it.

</comment></comment></comment></comment></comment></comment><comment><USER23> _This is how Rails works, classic example:_

        User.create(params[:user])

_You see a simple line of code, and you can immediately say (assuming you know User is an AR model) what it's doing. The problem here is that people confuse simplicity with convenience. It's convenient (aka "easy") to write this in your controller and get the job done, right?_

 _Now, this line of code is not simple, it's easy to write it, but the code is extremely complicated under the hood because:_

 _\- params must often go through db-specific coercions_

 _\- params must be validated_

 _\- params might be changed through callbacks, including external systems causing side-effects_

 _\- invalid state results in setting error messages, which depends on external system (i.e. I18n)_

 _\- valid params must be set as object's state, potentially setting up associated objects too_

 _\- a single object or an entire object graph must be stored in the database_

 _This lacks basic separation of concerns, which is always damaging for any complex project. It increases coupling and makes it harder to change and extend code._

This feels like the core of the argument of the whole post. It does not seem correct. In isolation, the call to User#create seems magical. But there's not enough context here to criticize it. We don't know enough to say whether there's inadequate separation of concerns.

No matter how we handle "users", we are going to need to do all 6 things in the list the author presented. No matter how we structure those 6 things, there is going to be a single entrypoint function that kicks them off --- _end users_ won't be pushing 6 different buttons to drive them. So: what's the better design here?

<comment><USER24> Just to point out that all those objections could be made about Django as well.

<comment><USER25> In Django, the validation & type coercion would typically happen in a Form object (or, if you're using Django REST Framework, a Serializer). That step at least is outside of the ORM and seems much more explicit to me.

Also, in Django models are explicitly defined. There's no ActiveRecord magic of reading the database to define the model. Which is not to say that AR's approach is bad or wrong, but it is pretty significantly different from Django.

<comment><USER26> "Explicit is better than implicit"

</comment></comment></comment></comment><comment><USER10> I can't grasp the hostile attitude towards rails at HN. Even agreeing with (some) of the criticism, I'm deeply thankful to Rails, DHH and everyone else involved.

Because before rails 1.0, I worked in php.

Many people may actually be too young to remember, but the jump from php and anything else that was state-of-the-art at the time to rails was without doubt the biggest leap web development ever took.

The most meaningful advances actually weren't just technical but social. It would've been possible to write an excellent webapp before rails, but just about nobody ever did. The opinionated nature of Rails many are complaining about today was a revolution because it taught everyone using it good architecture. You can nitpick about any one of those opinions, sure. But back then it was common to join a project with >100kloc with directories containing password.php, passwprds.php, pass.v3-old.inc, large_image.head.2002-v1.jpg & employees.xls. The quality of almost any rails project I have seen is, in comparison, excellent. It'd say a new team member on a rails project was productive in less than a third of the time it took in non-rails projects at the time.

So, to anyone complaining: I'm pretty sure that looking into any of your strongest held believes on web dev, you'll discover that rails had significant influence in creating them in the first place. To do something like that, pretty much as just one guy on the beginning, should afford someone a certain amount of respect.

<comment><USER27> Same, but coming from the hell of Java web applications. They had the opposite problem, too much architecture.

<comment><USER28> Which is funny, because that's what exactly what the OP wants from Rails.

<comment><USER27> I see it more as he wants Data Mapper to be as easy as Active Record. Just from a pure patterns perspective, it never will be, because Data Mapper has one additional level of complexity.

</comment></comment></comment></comment><comment><USER29> I think rails has plateaud in terms of improvements. The article is pointing out the tight coupling of activerecord with business logic which is the consequence of a belief that I strongly disagree with in the rails community. 'fat models, skinny controllers' has caused a lot of mayhem as minor database updates (or update intention) triggers a cascade of actions.

This behaviour is counter to the model2 MVC implementation that rails is using as controllers should really be in charge of coordinating (helped by specialized classes if need be).

The author correctly points out that the way rails deals with views is painful however rails views are not tied to the model at all, they are tied to controllers and this can be modified if need be.

I personally maintain an approach of tying dedicated ruby classes to view files (e.g. SidebarComponent) and compose the view in the controller using a chain of these classes. This approach is much more object-oriented and avoids the weird pass-along view-hierarchies that many rails projects have.

There are much things to improve about rails but the project doesn't seem to absorb more object-oriented approaches over time and is tilted heavily towards DSL's for everything and doesn't value creating a more specialized class hierarchy to encapsulate more complexity.

I don't see a need to move away from Rails yet though as you can easily work inside the framework in a more Object-oriented approach. I guess you can characterize my approach as skinny models, skinny controllers, fat business logic objects and every partial is powered by a view object.

<comment><USER30> Improvements are a strong word, I thought they were still playing whack a mole on the numerous Rails RCE security issues.

</comment></comment><comment><USER31> I too have stopped using Rails. To other Rails refugees, I highly recommend the up-and-coming Phoenix Framework for the Elixir language: [http://www.phoenixframework.org/](http://www.phoenixframework.org/).

Simple as in simple, fast, productive, beautiful Ruby-like syntax. Favors a functional and immutable workflow over object-oriented and mutable spaghetti code.

<comment><USER32> How's the community and library ecosystem looking in Elixir/Phoenix?

It sounds great in principle. I'd love to move from Rails toward something more functionally-inspired, but I worry that lack of libraries and google results is going to be a net productivity killer over the Rails + evolving into micro-services approach.

<comment><USER33> [https://github.com/h4cc/awesome-elixir](https://github.com/h4cc/awesome- elixir)

<comment><USER32> Thanks! Great list.

</comment></comment></comment></comment><comment><USER34> Nostalgia warning: I also grew frustrated with Rails / ActiveRecord and jumped to Merb / DataMapper with excitement. Perhaps it will sound like a small thing, but I remember feeling especially frustrated that every ActiveRecord model became such via inheritance. This drove me crazy:

        class User < ActiveRecord::Base

Why should my `User` extend from `ActiveRecord::Base`? Is a User of my app also an ActiveRecord::Base? What is an ActiveRecord::Base anyway?

So, when DataMapper came along and favored composition over inheritance I was sold.

However, my experience with DataMapper was that it didn't have the stability of ActiveRecord, nor did it reach feature parity.

And, then Rails killed Merb. At the time I thought it was a tragedy. The competition Merb provided _did_ improve Rails, it would have been nice if that competition had been longer term, though. On the flipside, I wonder if there would have been enough community to support two large Ruby web frameworks.

In the end I made peace with Rails and ActiveRecord (and, believe it or not, even ActiveSupport!). I don't have great love for Rails, but it is a powerful tool, so I accept it for what it is.

That said, I think the author's criticisms are well stated and hopefully there will be some influence on the future direction of Rails, etc, and the way devs approach Rails.

<comment><USER35> Having used many different ORMs that let you think that your business models could just gain persistence with a little sprinking of automagic, I far prefer the non-object-orientation of ActiveRecord.

Databases aren't object-oriented. Thinking of them with an is-a, LSP etc. mindset is a recipe for pain down the road. Databases are containers for facts: a means of storing, finding, synthesizing and manipulating facts. Your User class isn't a user of your application; IMO it's wrong to think of it as an object, because it could just be a slice of the User's facts (e.g. a subset of the columns).

I'm not a big fan of object orientation any more, and I like my databases to be stores of facts. The data in the database is primary; code in the application is secondary. Persistence isn't something I add to my benighted objects to let them be reanimated by query; persistence is what lets me briefly get a handy representation of a tuple locally.

To my mind, ActiveRecord models are little more than hashes with a nicer syntax. I don't need them to be much more; I don't want them to be much more. You can try and add methods and make them smaller, but coordinating the manipulation of facts is problematic in a transactional world, and the responsibilities aren't clear either. Object orientation is predicated on the idea of message sends and hidden state; tables have explicit state and no behaviour. Not a good match.

<comment><USER36> Honestly, I feel like OO has been a net harm to the practice. It is a useful code reuse pattern but I feel like it has gotten far too much play.

</comment></comment></comment><comment> jon-wood I'm somewhat split on the author's opinion here. I also picked up Rails back in the day (I think the first version I installed was 0.8), and I have a bit of a love/hate relationship with it.

As a framework for building comventional HTML templated database backed websites I still think it's near unbeatable, especially with the addition of a few common gems. However it so often gets shoehorned into other places - <USER2> backends, rich client apps, and massive systems. Places where the Rails conventions rapidly go from everything falling into place to getting in the way and needing to be worked around, or heavily tuned.

I completely agree that ActiveRecord is the core of why big Rails applications are complex to work with and often exhibit disproportionally poor performance. It doesn't lend itself well to composition, and results in data persistence being intertwined with business logic. That's fine for early prototypes, and in all honesty will get you to market quickly, but it makes extracting the concepts you discover during development into a coherant API much more complex than I'd like.

These days I still use Rails for the aforementioned HTML generating web applications, but it's often acting as an API client to systems built on top of a Grape based backend, with an API built around service objects and a simple data access later.

<comment><USER37> Interesting you bring up the point about API backends. I'm the author of Nodal [1], with the goal of bringing the best design patterns and practices from Rails and Django to the world of Node, _focused completely on building a decoupled API layer_. There is no view / template logic at all.

The project is very lightweight right now (benefits of being a young project with a sole full-time contributor), but I'd be interested to hear your feedback as to what you think is or isn't necessary for continued development. :)

[1] [http://github.com/keithwhor/nodal](http://github.com/keithwhor/nodal)

<comment> jon-wood Interesting, I think I came across Nodal while evaluating options for a side project a while back. Having just taken another look the big thing that seemed to be missing was something to serialize objects to JSON, although that may be because serializing objects is so trivial on JavaScript anyway. There also didn't seem to be much documentation about the operational side of things, most glaring was nothing being said about how the scheduler actually schedules jobs and ensures they get run.

<comment><USER37> Scheduler is actually still a WIP. I've changed the core around significantly in the last few releases, which has changed how the scheduler operates. That's why there's not much around it. ;)

We serialize models to JSON automatically in the response layer, and all models have a `.toObject()` method that takes an optional interface (which keys to actually serialize).

There is full API documentation but I still have a _lot_ of work to do creating more fleshed-out tutorials. :)

<comment> jon-wood The issue I have with just having a toObject or to_json method is that context is everything when serialising. Different access levels, different client types, and just different parts of an API call for different ways of sending data to end users.

<comment><USER37> Which is why you very clearly specify the _interface_ whenever .toObject is called (which fields are exposed). By default, everything is included, but you have complete granular control. It's what allows us to do things like have full GraphQL support. :)

[http://graphql.nodaljs.com/](http://graphql.nodaljs.com/)

</comment></comment></comment></comment></comment></comment><comment><USER38> I read this with a lot of head-nodding but also a great sense of sadness.

I agree with pretty much every brickbat hurled at Rails in this article, except for one thing:

> Both projects were ultimately killed by Rails as Merb was "merged" into > Rails, what turned out to be a major Rails refactor for its 3.0 version. > DataMapper lost its community attention and without much support, it never > evolved as it could if Merb was not "merged" into Rails.

DataMapper wasn't killed by Rails absorbing Merb. DataMapper was killed by "Things You Should Never Do, Part I":

> "They did it by making the single worst strategic mistake that any software > company can make: They decided to rewrite the code from scratch."

([http://www.joelonsoftware.com/articles/fog0000000069.html](http://www.joelonsoftware.com/articles/fog0000000069.html))

DataMapper 2 was insanely ambitious, and true enough, it was never finished. A core subset was salvaged as ROM (Ruby Object Mapper), which has a certain artisan purity but is a long way from hitting the readable/understandable sweet spot that DataMapper originally had. But DataMapper 1 was abandoned by its developers. Pull requests languished and there weren't even any maintenance releases. I idled in the DataMapper IRC channel for a while and pretty much every query was answered with "don't bother, wait for DM 2". Unsurprisingly, people switched to ActiveRecord instead.

I still use DataMapper. I use it in my own framework, which is plaintively simple compared to Rails and no doubt makes a load of mistakes, but they're the mistakes I've chosen to make (which, as per DHH, is "opinionated" software). I would love DataMapper to be, if not revived, at least slightly maintained. There is life outside Rails, but you have to want it.

<comment><USER39> You nailed it. HABTM just never worked, and there was little interest in making it work. Since I handed out commit-access like candy, the majority of contributions were to endlessly refactor. Or do things like letting you treat a CSV file as a database. And HABTM still didn't work.

I didn't know how to put the genie back in the bottle. I didn't have the same problems that prompted me to create DM in the first place anymore (and by that point, I wasn't sure that porting a large Java Pattern to Ruby was even a good idea considering what I'd learned in the process about method dispatch performance in Ruby) and I was burned out on maintenance. So I handed over the keys and the rest is history.

I messed up. :-)

Today I'm happily writing apps with akka-http and think O/R Mappers are a fundamentally flawed idea. It's like trying to build a truck to move a few yards of dirt 100 feet. It'll never pay off. And I think even "users" would probably find that the hours they put into learning and using the tool will never get ahead of the performance, simplicity and linear scaling of effort they'd have had with a simpler solution.

So these days I'm much more likely to write this in Scala:

      val limit = 10.0

      sql"SELECT name FROM coffees WHERE price < $limit".as[String]

Than anything else. You will never find an O/RM that's faster, simpler or easier to write and maintain than that.

Plus Contextual Validations in the O/RM is just a bad idea. Even if they do appear in the PoEAA. First-class-Form objects and deserialization/validation at the app boundaries may not be a new idea, but it's the right one. (IMO)

<comment><USER40> Hey Sam, great to see you commenting on this :) I started contributing to DM when Dan was already in charge but I was a DM user when you were still working on it.

Anyhow, you made really good points here. I've worked on ORMs for a couple of years before I concluded the same - NOT WORTH THE EFFORT.

My approach with rom-rb is functional, as in this project works more like persistence libs in functional languages, rather than an O/R mapper. I removed the whole idea of mutable objects and managing their state using UoW etc. This simplified the stack a lot, and despite a complete lack of any performance- related tweaks rom-rb is already faster than ActiveRecord.

I also agree with your opinion re validations. I removed this concept from rom-rb as well and built a standalone validation library instead. This works very well.

Cheers!

<comment><USER39> I think I'd blocked out the pain of dealing with mutable strings. :-)

We were a pretty enthusiastic bunch back in the day. Glad to hear you're still pushing things forward.

</comment></comment></comment></comment><comment><USER33> The thing that has blown my mind about Elixir and Phoenix is how it gets everything right. It's the clear migration path from Rails.

<comment><USER15> Phoenix is very Rails like in the way it makes developers work and very un- Erlang. I mean: Phoenix apps are monoliths and not loose collectives of processes with an explicit http process.

Check "Phoenix is not Your Application" at [http://www.elixirconf.eu/](http://www.elixirconf.eu/)

It starts with the right claim but it ends with workers inside Phoenix. Instead the router and the http server should be at the same level of the other workers. Actually, they shoul be much less important, an implementation detail.

<comment><USER41> A new phoenix application is not a monolith. The `phoenix.new` generator generates a regular _Elixir_ application for you that sets up a default Endpoint worker in your supervision tree, as well as a web directory to put phoenix related files (routers, controllers, etc). wrt to collective process, we add `worker(MyApp.Endpoint, [])` into your supervision tree, so we do exactly what you are wanting. Building a Phoenix application is building an Elixir application, not the other way around. Your phoenix dependency and related workers are just one component to your larger Elixir/OTP infrastructure. Note: Lance Halvorsen, who gave the "Phoenix is not your App" talk, is on the Phoenix core team. We have been pushing these ideas since the beginning and as Lance I and laid out in our ElixirConfEU talks, we're taking a stronger stance on isolation with upcoming changes to guides and phoenix resource generators.

<comment><USER15> Understood but to make me clear: I'd like to see Phoenix as part of an umbrella application and not it starting other applications as its workers. It should be a peer among peers and not the boss. However, as Rails demonstrated, the current approach is very convenient so I can hardly criticize it too much at this stage of Phoenix adoption. I think it helps the onboarding to the platform.

<comment><USER41> Phoenix v1.3 is adding an `--umbrella` flag to the `phoenix.new` generator for first-class umbrella support out of the box. In the Phoenix book we also have the reader breakout their application in an umbrella for the domain bits and a web app for the phoenix bits. Umbrellas have been a little underserved in the community so far, but stay tuned for future improvements around this.

<comment><USER15> Great news, thanks!

</comment></comment></comment></comment></comment></comment><comment><USER42> I have 2 main concerns going forward with any Rails alternative (ie. Trailblazer and the like): community support and jobs.

I have no idea how big the community behind each library/framework is and honestly I don't have the time to properly test-drive multiple and research the health of their respective ecosystems. With Rails I can rely on 10-15 gems that can help me with 80% of my projects. Perhaps I overestimate my reliance on 3rd party code, but that leaves me with my second issue.

Ruby jobs are de facto Rails jobs. I have weekly email newsletters set up for Ruby jobs and in the last 3+ years only a handful were Sinatra/Rack based. It would be interesting to see a reliable source of non-Rails Ruby jobs out there.

<comment><USER43> At some point you'll be in a position to decide which tech stack a company should use. I suspect you'll find there's a bit of a chicken and egg problem here - you'll want access to the largest pool of good candidates possible so you will also be disincentived from straying from the well worn path.

Even if you grant that good programmers can pick up new languages or frameworks easily (which I'm not entirely convinced of - there is a wide gulf between "can follow the tutorial" and "successfully used in anger"), you'll incur a penalty in velocity while all your new hires learn Framework X.

Anecdotal example of the perils of going off the beaten path: I often see a job advert on StackO for a company looking for Python/Django guys. When you click through to the job description, they are actually using Perl/Dancer. Not that there's anything wrong with that, but for me personally that's a deal breaker. I have no interest in investing the time to become proficient on that particular stack.

<comment><USER44> > Even if you grant that good programmers can pick up new languages or > frameworks easily (which I'm not entirely convinced of - there is a wide > gulf between "can follow the tutorial" and "successfully used in anger"), > you'll incur a penalty in velocity while all your new hires learn Framework > X.

I think the question is more "Does what we're doing require good programmers, or can we get by with shitty ones?" More often than not, you're not doing anything special, and you want to pick a platform that the cheapest, most common programmers out there can add features in a non-disastrous amount of time (different depending on industry + your competition), and not generate enough technical debt to collapse everything before the next rewrite/upgrade cycle.

</comment></comment></comment><comment><USER45> I'm a full-time Rails developer, and I've run into the exact pains that he's talking about. By and large, I've fought with ridiculous things as projects grew, and run into extremely 'magical' bugs. It's frustrating as hell. But I've found the way through them is actually to lean into ActiveRecord, not away from it.

When it really boils down to it, ActiveRecord is a perfect pattern to deal with the "submit a form, validate it, run some logic, return the results" round-trip that's the core experience of web applications. Do you have validated data you need to do really complex logic on? Sweet. Send it on over to some PORO's. Have a complex query that isn't easy to cache? Nice! ActiveRecord will get out of your way. What's really hard is figuring out how to frame the problem in a way that makes Rails a great solution for it. This part is really really hard, I think in a lot of ways akin to art (and by 'art' I don't mean some deeper honor or aesthetic - just that there's no guidance), since the principles and patterns actually come from your domain and not somewhere else. And the developers I know who really hate the way Rails does something, especially ActiveRecord, are huge on applying patterns.

When I've taken the time to think through how to structure, really deeply, the applications are a pleasure to change and modify even when I come back much later. And for me, the proof is in the pudding: those aforementioned other developers who hate ActiveRecord don't complain! They'll see it, give a small 'huh,' then go do what they need to do just fine. But when I don't, they turn into the twisted spaghetti nightmares. I see a massive sub-current of dissatisfaction with Rails, and I think the reason for this is just a subtle but markedly different priority of thought. I can't articulate it yet, I just know what it looks like when I see it.

Anyway, I love Rails as it is now. Soon I hope I can deploy a single application across web and mobile platforms natively, along with supporting them all, as one guy. That's insane. Really like this blog post because I've got some things I'd like to be able to do with the ActiveRecord API, but I'm not really sure how. I don't know why the thought never occurred to me to just ask!

</comment><comment><USER46> I'm not surprised by this development. I'm familiar with Piotr's code and it's hard to miss the fact that he's writing Ruby as if it was a functional language. Sharing inspiration between languages and paradigms is an awesome thing but if you're going to try hard writing Ruby like if you wrote Haskell you'd probably be much better off writing Haskell in the first place. Back to the original article I think it says more about Piotr's personal path as a developer than Rails and Ruby community at large.

<comment><USER40> That's not true, although there's a lot I took from FP. Like avoiding mutable state, and functional composition for data transformations.

This doesn't change the fact my code is OO - I use objects, composition, decoration, delegation and many other OO techniques, and in general try to avoid heavy inheritance-based patterns.

I can understand how people may think I'm trying to use ruby in an awkward way, but this is really not the case.

<comment><USER46> I find your Ruby code super awkward. Like you're trying to turn it into a language that it is not. At least it is not in my book but then again I'm just some random dude on the internet, a sample of one ;)

</comment></comment></comment><comment><USER47> Reminds me of Zed Shaw's critique of Rails[0] which explains many of the short comings of Rails. Zed wrote the mongrel server for rails. Assume this article is massively politically incorrect & vulgar as hell, just as a heads up. Really good read though, and does explain some of the interior politics of rails and how it evolved.

[0][http://harmful.cat-v.org/software/ruby/rails/is-a- ghetto](http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto)

<comment><USER48> This article is nothing like "Rails is a Ghetto". Zed's rant is 90% personal feuds, drama that is practically completely irrelevant today. The article being discussed is 90% technical critique.

<comment><USER47> > This article is nothing like "Rails is a Ghetto". Zed's rant is 90% personal > feuds, drama that is practically completely irrelevant today. The article > being discussed is 90% technical critique.

True. And yet, it reminded _me_ of that article Zed wrote, which I summarized as a vulgar critique of the internal politics of the rails community.

</comment></comment></comment><comment><USER49> Having little experience with Rails, it's the tone of that "Crazy, Heretical" article [1] that really strikes me. That tone where you're laboring to describe something that really truly does make sense when you're in the company of a bunch of people that just don't want to hear it.

There's too much purism in those kinds of arguments, arguments that really are more about spectrums. It sounds like Rails is really great for learning the shallowest 40% of a wide variety of programming concerns, and a lot of web solutions for small clients aren't ever going to dip below that 40%. And as soon as you get beyond that 40%, asking questions like "but what if it doesn't make sense to do it that way?" and "what is that weird runtime bug that doesn't happen in my development environment?" and "why can't I refactor without being scared I'll introduce a weird regression bug?" then it's totally fine to be attracted to the idea of static typing, compilation, and libraries/frameworks that are more explicit.

[1] [http://jamesgolick.com/2010/3/14/crazy-heretical-and- awesome...](http://jamesgolick.com/2010/3/14/crazy-heretical-and-awesome-the- way-i-write-rails-apps.html)

</comment><comment><USER50> I was quite happy to walk away from the Ruby on Rails world 4 or 5 years ago. I basically escaped before the onslaught of Rails 3.0 and what came next. I think somewhere around the adoption of coffee script I got pretty concerned.

While at Google I became aware of Go and what that looked like at scale. I would highly recommend trying out Go. I think the simplicity will be a refreshing change but there will also be some familiarity coming from the Ruby/C world, can't quite pinpoint why but just feels that way.

And if you're looking for frameworks, shameless plug, I'm working on this [https://github.com/micro/micro](https://github.com/micro/micro).

</comment><comment><USER51> I usually find "I am stop using XXX" type articles to be a bit negative. That said, I stopped using Rails years ago myself, so the linked article resonates with me. My goto web frameworks are Ruby+Sintra and Clojure+ring+compojure. Sometimes I also use meteor.js but it is more like Rails in that it is a complete package of everything you are likely to need, pre-configured.

</comment><comment><USER52> Now I never use dynamic languages and never thought Rails was a good idea. But I'm glad I read as through as the "Convenience-Oriented Design" and the simple vs easy quote. I've seen many designs which have sacrificed consistency or orthogonality to make the common case as tiny as possible, and struggled to articulate what was wrong when I was counter with "how simple the tool is to use". Hopefully this will give me some better language.

<comment><USER52> I feel like the very world "simple" is part of the problem. Orthogonality/Consistency is much more important. Also don't treat odd use- cases as gratuitous features to be someday supports. No, a use-case is not a feature, but that hacks that will be added to accommodate those are. And features are bad: "[things] should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary."

</comment></comment><comment><USER53>
      Secondly, avoiding mutable state is a general, good advice,
      which you can apply in your Ruby code. Ditching global state
      and isolating it when you can't avoid is also a really good
      general advice.

As an Erlang programmer I agree with the general sentiment here, but wouldn't doing this in Ruby really lean hard on one of the pathologically nasty Ruby runtime issues? Which is that it doesn't release memory back to the system?

When every new operation on a data-structure starts by producing a copy of the previous version it seems like you'd really want a runtime which is efficient and intelligent about how it manages memory?

Unless that idiosyncrasy of Ruby has changed since I last used it several years ago. In which case. Nevermind. :-)

<comment><USER54> Ruby's MRI never returns RAM to the kernel, yes. But if you use immutable data structures and release them relatively quickly, the GC will have much easier time releasing their memory back to the pool that MRI is using for allocating new ones. So the inevitable RAM bloat that MRI accumulates over time is still there, but is slowed down.

As far as my not-so-big experience with them goes, the immutability programming techniques in Ruby actually help a lot with its sticky RAM problem. Complex object hierarchies of mutable objects and references to them are a nightmare for the GC. Having structures/objects that are used and [quickly] thrown away without (or rarely) being attached to complex object graphs is making the GC work more reliably, and faster.

</comment></comment><comment><USER55> I like rails. A lot. The syntax is amazing. Period. If you can get a gem or get what you need from rails. It is simply close to amazing.

But dare you. You just go down one simple level. (first level is what you get with rails and for example extending active record.) it becomes a horrible mess of dependencies and magic / structures.

I never found a framework so hard to modify. ( for example writing your own multi category / multi tag gem)

That's when i stopped web dev. It was just mind boggling. This is several years ago. I think around version 3 or even 2? And every version broke the active record stuff...

I really thought rails would catch on in germany. But if you look on indeed there are literally like five jobs in Germany... Maybe I'm not alone with that problem...

</comment><comment><USER56> Rails is great. And of course it isn't and will never be perfect. Obviously the author would love some alternative frameworks, mainly so he can use some more and some less exotic code patterns. Maybe after almost a decade of writing CRUD apps in Rails he is a bit bored? I can't blame him and seeing the Ruby community so focused on basically one framework is a tiny bit sad.

So I definitely see where he is coming from with all this, but truth be told it was never Rails' indent to be a precision instrument. It has been a reliable framework that makes a lot of Developers very happy. A great reliable car for the masses so to speak. But not a Ferrari.

</comment><comment><USER57> Although I may not agree with your perspective entirely, but I respect it.

I think everyone has different needs, and you have your personal needs which Rails no longer satisfies, so you are moving on.

Rails still solves a lot of problems for a lot of people I believe. I work as a consultant for a few companies and in some cases I see people losing time and money on what would be resolved immediately if they had just made the right call by using Rails.

Good luck on your journey, and remember the rails community will always have its door open for you :). Your projects on github look exciting, I will take a look at them. Very cool stuff!

</comment><comment><USER58> I've also seen the writing on the wall for leaving Rails/Ruby. I think a lot is down to Ruby the language simply not being well-suited for an increasingly multi-core/concurrent future. That said, a more reasonable approach is to begin transitioning a few projects at a time, and make sure you've solidified on your new tools of choice before chucking the old ones.

I remember a few years ago I teased with ditching ruby for node.js. I'm glad I dipped my toes in the water and waited for Elixir.

</comment><comment><USER59> Things aren't always the best fit for a person and they have to decide to move on.

Solnic has contributed a lot to the Ruby community and I'm not surprised to see him leave.

Within the the web domain of Ruby there has very much been a Highlander attitude of "there can be only one". That one has always been Rails. For someone that wants to create better pieces or have more choices other languages are more accepting.

On much of what he said in the article he is on point. Personally I've never been a big DataMapper fan (sorry dude, I just prefer Sequel), but I do agree ActiveRecord isn't great.

I've considered leaving the Ruby eco-system, but I look around and don't like the alternatives I see either. One of the great things about learning Ruby on Rails is job skill relevance. If you want to make a move and you know Rails then pretty much all job search matches are a green light. If you know Java and you are working with Play then nobody wants you because they want experience with Stripes, Spark, or god forbid Struts; now you have to relearn the whole framework and rinse repeat each time.

Personally I stick mostly to Ruby on Rails (and JavaScript) for my professional work, and then on personal projects I work in various obscure technologies that I just enjoy because I enjoy and I don't need to worry about if it will help bring in the bacon.

</comment><comment><USER60> Sounds like he wants Arachne. Which isn't written yet. He even mentions learning Clojure. Linked article stops just short of mentioning it, but there are some themes that are common between the linked article and the story of what Arachne should fix.

[http://arachne-framework.org/](http://arachne-framework.org/)

The concept of the zeitgeist is interesting. A lot of general dislike of Rails is in the air and the only question seems to be what the replacement will be, not if there will be a replacement. Naturally the ruby guy thinks it'll be a new OO ruby framework which has always done the impossible before and the Clojure people think it'll be the usual immutable functional magic which has always done the impossible before. Best plan for the future is wish them all luck and wait and see. I don't see any other useful strategy at this instant?

My money is quite literally on the Clojure guys, I was one of the backers of the Arachne kickstarter, but best of luck to Hanami and rom.rb and all the new wave ruby stuff. One of you revolutionaries had better succeed, or else...

Some of it may be the natural result of success and age. A near decade of continually having to revamp my rails code "because the guys at hulu really need it" or "this is very helpful for github" is inevitably going to eventually make me say (if you'll excuse the profanity) F them I'm sick of rails and authoritarian monoculture in general and hulu is very nice but it can just go help itself, I have work to do that isn't "I have to chase latest fad that someone else needs". It may be a natural state for the lifespan of a framework to enter a stage where staying on the bus is more expensive than hopping off, maybe even hopping off anywhere. I tried some Play framework projects and I felt the sirens pull of static typing, but, after a few years, unless you keep up with changes, the technical debt just accumulates each framework revision until I'm sick of seeing releases instead of pumped.

I'm talking about projects that last many years not a semester or so. I'm not sure the chronological nut has been cracked of heres a magic solution for long lived projects. Assuming there is a magic solution. Perl CGI I suppose (only slightly tongue in cheek kidding)

</comment><comment><USER61> Is it uncommon to use other patterns within rails like service objects? I like using Draper, Pundit, and other gems which provide decorator and policy objects.

I prefer to not use Helpers and AR callbacks (generally Concerns too) as I don't think they encourage good OO even though they are officially part of rails.

Ultimately it comes down to what your goal is. Is it to deliver some business value fast to end users? Build a new product with a small team? Then I think rails is a great tool to achieve that.

</comment><comment><USER62> Scrolling in Firefox (OSX) is very slow.

<comment><USER63> I noticed that too. But it renders and scrolls perfectly on Chrome. I wonder what's the difference? Firefox is typically a lot slower than Chrome, but the performance difference this time is amazingly large.

<comment><USER62> It seems to be a bug. See here: [https://news.ycombinator.com/item?id=11749503](https://news.ycombinator.com/item?id=11749503)

</comment></comment></comment><comment><USER64> What I don't understand is why people feel the need to proclaim that they're leaving xyz? Why not just focus on the positive and focus your energy on the new stuff you'll be doing. It sounds like someone who just broke up and keeps claiming they're totally over it but just can't stop talking about what a bitch their ex is. If you're planning to do haskell, elixir, clojure and scala, write about that.

<comment><USER65> There's a small bit of irony here in that there was a rash of "Why I'm leaving X for Rails" posts between 2008 and 2012 or so.

<comment><USER66> Oh yes. I remember it well.

</comment></comment></comment><comment><USER67> my two cents on Rails (as someone who's worked with Rails/Ruby, Node, Scala, Golang in some depth)

\- ORM is bad at any sort of scale/complexity.

\- Net IO that looks like property access makes it too easy for devs to do bad things, N+1 queries etc.

\- ORM abstraction is not helpful when you know the exact efficient query you want.

\- ActiveRecord Models + the Ruby module system encourage OO bloat.

\- ActiveRecord database drivers are too numerous and not well implemented. Default schema generation includes many SQL anti-patterns.

\- ActiveRecord has too many public interfaces, too much meta-programming. Hard to understand scope, Hard to analyze and improve performance.

\- ActiveSupport monkey patches too much of Ruby. Need an very deep understanding of language to understand what's going on at a non-superficial level.

\- Rails/Ruby community places too much emphasis on "clever" DSLs / APIs

\- If your stack/framework choices limited to dynamic languages, Rails is a lot less efficient than Node and for web apps you need JS developers anyway.

<comment><USER68> > \- ORM is bad at any sort of scale/complexity.

ORM is good, as long as you use only SQL in your backend.

</comment></comment><comment><USER69> I'm not going to argue.

However if you've run into the same problem where you feel like you need to either make fat model or fat controller in Rails, here's a simple solution:

[https://github.com/collectiveidea/interactor](https://github.com/collectiveidea/interactor)

</comment><comment><USER70> A simple formula to take a lot of AR's bloat away is to use it mainly as a read library (AR's great for generating complex queries in a simple & readable manner).

For write operations (aka user interaction) I use a combination of solnic gem (Virtus) with ActiveModel that way I remove a s __*t load of responsibilities from AR and the controller : \- params management (and strong params) \- validations \- nested associations \- callbacks \- And all the context management (like user vs admin...)

That way I only mildly part from the rails way and yet have a good separation of concern. Actually ActiveModel is used by ActiveRecord so having a form object relying on it is still very much rails compliant. The refactoring is minor (no hexagonal stuff) and the level of indirection very low.

</comment><comment><USER71> This should come at no surprise, although I don't see anyone criticizing Rails anywhere.

I've never written a line of Ruby, but trying to read Rails code evokes me all this: it seems like a framework created with the sole purpose of hiding everything possible from the programmer.

<comment><USER72> It's not hiding anything, other than the conventions. Django's spammy boilerplate is just default behavior.

<comment><USER73> Conventions is something I try to avoid at all costs. Conventions are usually things that are hard to find in documentation. Conventions are things that every experienced user says that "oh, this is common knowledge" and conventions are the reason why things seem to work magically.

Obviously if you follow a framework from day 0 you don't even notice it. For newcomers, it's a source of frustration.

<comment><USER74> That's not really what convention refers to here. Rails' motto "convention over configuration" simply means that boilerplate should be avoided, and that code should use sensible defaults whenever there isn't information.

For example, ActiveRecord class names map to table names through a simple pluralizer (UserProfile -> user_profiles). That's a convention, no configuration needed. Just write a class and off you go. You can override this behaviour, but you can also write huge apps that just follow the convention. Other frameworks would typically make this mapping explicit.

You do need to read the documentation to see what the conventional behaviour is, but it's not very deep knowledge. It's not much worse than other frameworks, where you need to find how things are configured.

<comment><USER75> My experience is that programmers migrating to Rails are thoroughly confused by these conventions like "UserProfile -> user_profiles". Although it's only the second-biggest source of confusion after ActiveSupport, e.g. "10.hours.ago" even though the integer class does not have an hours method according to the Ruby documentation.

<comment><USER73> Integers have methods? ಠ_ಠ

<comment><USER74> Yes, why not?

        42.times { puts "foo" }

        1.upto(9) { |n| puts n }

        puts 1.year + 7.months - 1.day

<comment><USER76> one of the issues I see with rails precisely is that most people won't ever know that 1.year is not a plain ruby method

<comment><USER77> It's definitely _a_ issue, but I think it's far from the biggest issue. If you're going to use ruby, you're going to have to come grips with the culture, which for better or worse involves more "magic" and meta-programming than, say, Python where the same power exists but is avoided on principle.

It takes a little getting used to, but once you are, then the tooling is there to help you make sense of these things:

1.method(:year).source_location

The bigger issues with Rails I see are the monoculture issue raised in the article, plus the intractable issues with ruby around performance, memory bloat, concurrency, and last but not least, the multi-paradigm nature giving you functional features, but without any of the usual immutability guarantees (unless you follow a constrained and unconventional coding style which no one does in the ruby community).

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER78> I personally can't wait for Rails to be a distant past. So many start-ups got burnt badly by using Rails -- easy to start, hard to scale, maintain, and extend. Rails is too opinionated and if your use-cases don't fit into "Rails way" your screwed.

<comment><USER15> But at least it got them started and they could understand if there is a market for their product. My bet: if twitter started with Java Struts (it was 2006) they would have had to spend so much money and have needed so much time to launch that we would be using something else now. Not necessarily a system bootstrapped with Ruby, but you got the idea.

> if your use-cases don't fit into "Rails way" your screwed

Of course.

If a startup service doesn't fit Rails, they should have picked something else. I'm not using Rails for everything.

<comment><USER78> Startups usually try on a bunch of use-cases (features, ideas, workflows) before they gain traction or die. Your saying that startups should know all the use-cases they plan on building before they even start -- that simply impossible. Maybe your point is that startups shouldn't use Rails and its more suited for dev projects with a clear spec.

<comment><USER32> Not really. Rails is good for quickly hacking things together across a very wide range of the domains that startups usually play in, which makes it as good as anything out there when upfront productivity is the priority and you have rapidly evolving specs.

The only really common startup use case it's decidedly bad at is realtime/sockets/streaming data, where Node takes its place as the hack-it- together tool of choice--at a significant productivity penalty compared to Rails.

It's also, of course, pretty bad at all kinds of tasks unrelated to web development or REST apis. You wouldn't want to write machine learning algorithms or do statistical analysis in Rails, just like you wouldn't want to do 3d game development in Rails. And while you do occasionally see startups who have bolted some heavy data processing or pseudo-ML monstrosity onto their Rails apps, I've never seen anyone in the Rails community claim that was a good idea. The vanilla recommendation there is to keep your main server stack in Rails and then write services in something more appropriate for those needs.

</comment></comment></comment></comment><comment><USER79> The things that suck in rails are the views, the asset pipeline and the stupid helper methods for routes that are so complicated for nested routes it's a joke. The database part is actually the good part if you do it right.

</comment><comment><USER80> Another point that was subtly made, but needs highlighting.

If you are programming in ruby you are ONLY doing a front facing webapp. There are lots of servers out there that run headless. The ruby ecosystem is completely dominated and controlled by rails. As a result, ORM mappings and gems are completely focused on a web-response centric world.

As monolithic ruby apps are broken into microservices, ruby as a language will also be abandoned for those microservice back-ends - simply because the ruby ecosystem has only one way of viewing the world.

</comment><comment><USER81> I have seen posts like this time after time of experienced developer eventually hating (opinionated and/or coupling) framework.

I too eventually came to a similar conclusion albeit on different platforms. Frameworks get you started quickly but you will eventually hate them. And I do mean framework and not library (there is a subtle but massive difference... yes the oxymoron was intentional).

Its even worse in Javascript land. You could rewrite this post and just insert one of the many Javascript frameworks like Angular.

</comment><comment><USER82> I'm not going to pretend it's better than Rails, but I implement most of my projects as Sinatra psuedo-frameworks, with Sequel for the ORM. Sequel is a solid ORM that has a reputation of being stable and reliable. Sinatra is just simple (vs easy sometimes) and I like the way it integrates routing directly. It's good enough to power Neocities anyways, and I've baked in some of the niceties you'd expect from a larger framework (such as testing).

<comment><USER83> I wonder if the author of the article above has looked into Sinatra? It seems to be the solution he is looking for, in a sense.

I have used Padrino ([http://www.padrinorb.com](http://www.padrinorb.com)) a lot recently, which is really a framework on top of Sinatra that make things like testing, ORMs and renderers easier to integrate into a raw Sinatra base.

I especially love that I can use 95% of gems written for Rails in it - <USER3> the only ones I can't use are the ActiveRecord specific ones. (Note: I use DataMapper in most of my projects, but looking at Sequel as the ORM for my current app).

</comment></comment><comment><USER84> I've been developing apps with Rails since it was announced. It's been an amazing tool/toolchain, providing a very useful level of abstraction that allows rapid development.

Recently, I've been doing a lot of Go (Golang) development. For me, it's sort of the anti-Ruby-Rails. I really like the fact that it requires me to "roll my own" in so many situations. I need to understand what's happening under the hood to make things work.

But, the abstraction/magic of Rails is useful. Speed to market with trustable, battle tested magic is a profitable proposition.

I _want_ to introduce Golang into my current project, but I haven't quite found the right place for it yet. Rails makes it so much easier and faster to add functionality at our scale.

<comment><USER54> It might be a better sell if you try to introduce Elixir, and I am guessing its Phoenix library/framework as well.

I've tinkered a bit with Golang and I love it but IMO it's too much extra work in the Web development part. It's exciting and very educational to pop the hood and understand how many things fit together, especially if you're coming from Rails, but you should be aware that after a while the novelty wears off and sooner or later you'll start looking for the quicker paths to introduce trivial Web cruft.

I am yet to experiment with Elixir + Phoenix but the community feedback so far has been fantastic.

</comment></comment><comment><USER85> > _First of all, it worries me that many people react like that. We're > discussing a tool, not a person, no need to get emotional._

Laughably, no.

Code is written by people; it's essentially a set of ideas that execute and do things in accordance with the vision of the creators. The creators poured themselves into the tool. Code is an extension of the self.

(If it isn't, it should be; people take the best responsibility for code when it's like that, and it's probably the main essence that separates OSS from most proprietary work. People don't fully invest themselves into creations that can completely disappear out of their lives forever upon the next organization restructuring.)

</comment><comment><USER86> This article formulates well why I strongly prefer libraries to frameworks.

A framework dictates you the structure of what you are doing. Libraries can be combined, replaced, and used in various ways, fitting more the task at hand than the mist common case.

</comment><comment><USER76> I've always said Rails is good for short-lived build and forget projects, it's too "magic" for my taste.

I can't imagine what it must feel like to receive a mid-to-large sized Rails project to maintain.

<comment><USER54> You don't want to know. I inherited and am currently tech-leading a large e-commerce project powering an e-shop doing $10k+ sales a day. Even a small bugfix or a very minor UI addition is taking _days_ because outdated tests are breaking, because there are dozens of tight integrations directly in the code, because there's zero separation of concerns, and awfully inefficient ActiveRecord queries _everywhere_. Making a cart checkout with ONE item takes 50+ ActiveRecord queries. Yep...

It is extremely challenging and very educational for me, and I appreciate the experience. I've always been a fan of repairing and improving things -- but truth be told, it gets tiresome and annoying VERY quickly.

I am currently working hard to stabilize the entire process of small refactorings for the sake of the new features/bugfixes, streamlining deployment, making full separate QA/Staging environment (yes, even that wasn't addressed by the previous team) so we can test with confidence and without fearing we'll break Prod, and to reduce the 3rd party API dependencies -- right now they are 20+.

I am hopeful that after I stabilize the project and make the process of introducing new code easier and quicker, I could then make the case for gradual exodus to Elixir/Phoenix. Realistically, I am not seeing that Rails abomination I inherited to be a sustainable job for even one year. Inevitably I'll burn out, the customers will lose patience, and my employer will be unhappy both with me and the customers. Not cool for anyone involved.

So I'll try to gradually run away from Rails. As pointed by numerous smart people here, it's suited for medium-sized projects at best. Even Sinatra/Padrino and 50+ attached libraries would have been much easier to maintain.

<comment><USER87> Ive got a similar problem, dealing with a rails app i inhereted that collects telemetry data from thousands of remote units traveling out in the field. Basically there is no separation at all of active record and buisness logic. You end up with connections to ftp servers and other application layer adapters down in active record models. With all of the application layer in the AR models its only a matter of time before the developers end up weaveing a thick carpet of spaghetti dependency through everything.

On top of that changing the database becomes a royal nightmare because the database is what defines this AR model that all of your buisness logic and application layer spaghetti dependency relies on. The databases usually end up full of garbage because without complex validations and lots and lots of tests which by the way were never written ruby and rails will dump any trash into your db whenever. So you end up with columns with like 10 variations of the definition of NULL or FALSE.

Usually around this point your app just slips into a state of quantum uncertainty. It essentially ceases to behave deterministically at least when viewed from within the bounds of human perception.

Its hard for experienced developers to bend rails in away so that things don't become overly dependent on each other and neigh impossible for average or beginner rails developers to manage.

Im just really not impressed with rails at all especially coming off of 6 years of development time on huge enterprise apps written with the c# .net libraries. I mean really they are light years ahead using IOC dependency injection for injecting service apis into controllers while using mapping patterns for keeping buisness and database logic separate. Its the only way to break up large apps and keep them sane and maintainable. Additionally static typing is the only thing that keeps things sane in really large applications doing complex business logic through many layers of interfaces.

<comment><USER54> Hey and sorry for replying with so much delay. I keep forgetting HN won't send me mobile notifications for replies.

Truth be told, I am not sure how well will I cope. I am good, I have experience, I have been doing lots of quality repairs in my life before. But you know what? At certain point you don't think it's worth your time and energy. That's the real enemy here -- demotivation.

I spent humongous amounts of time in the object-oriented land. I think I'll just hop to the functional programming world -- isolated functions, functions as first-class citizens, immutability (hell yes!), no shared shate (oh God please, I want that!), and goodbye side effects. At least I hope so. It might just be another shiny thing I'll be pursuing and won't be much better. We'll see.

But you know what? I prefer working hard to build things from the ground up in a new and much better language and ecosystem than to spend my life trying to demystify somebody's strongly opinionated framework which doesn't cover even 40% of what I need in my project.

</comment></comment></comment></comment><comment><USER88> Explicit is better than implicit.

</comment><comment><USER89> TLDR: People don't do what I want them to do. They don't think the way I want them to think. And my way of thinking is way better than theirs.

<comment><USER90> Alternatively: Rails doesn't believe in doing anything that would make it anything resembling modular so people who don't agree on everything can still work together easily.

</comment></comment><comment><USER91> This is simply why I've never liked Laravel. Don't get me wrong, I love the packages esp. Eloquent and Blade (validaton and translation not far behind) and I reuse them in all my projects now.

I simply hate the "magic". I don't touch anything with too much magic going on and even avoid some features of Eloquent because of that.

And since it is heavily inspired by rails...

</comment><comment><USER92> What is a good alternative?

<comment><USER93> He mentions it at the end, but I'd strongly agree that Clojure addresses the issues he mentions. I see a lot of discussion in this thread about Elixir and Phoenix, but I'd take another look at Clojure.

It's got a strong, friendly ecosystem that encourages small, composable libraries. For every level of your application, there's competition - <USER4> servers, sql abstractions, front end libraries. And there's great resources to help you choose what works best for your use case - the Luminus docs, books, blogs, and several active forums for discussion with library owners and just regular developers.

Couple that with a community that really took Rich Hickey's "Simple made easy" talk to heart and the default immutability and functional paradigm and the abstractions that Clojure itself has to offer, not to mention the performance the JVM brings to the table, and I think it's a great language to hang your hat on in the long haul.

<comment><USER94> I'm going Clojure route and in it for the long run. Being able to eval any single piece of your code in a REPL direct from your IDE in the context of your app is just insane. Also having one single language for JavaScript and JVM is super useful.

Also after programming for 4 years a bit I've felt the core of programming beyond CRUD/consuming APIs is about manipulating data structures. Having powerful utilities for this and not having to shove everything into classes and objects makes it really easy to get stuff done. Going back to Ruby feels like I'm working with a kludge in comparison. Everything that doesn't need to be a class is one, then you get caught up in naming things. Then you try to debug things to end up with an object that has 500 methods on it and you don't know where half of them came from because they were metaprogrammed in through 10 layers of indirection. Yesterday I tried upgrading to Rails 5 and gave up because I couldn't debug an outdated library in 6 hours without realizing I have to figure out what this library and ActiveSupport/Model is doing in order to make headway. Ain't nobody got time for that.

</comment></comment></comment><comment><USER95> I have the same sentiment with Rails. I built a big warehouse/delivery system (routing, etc) on 2006 with Rails 1.2.3. still being used up to this day. After that, I never looked at rails again. All of my web apps small and medium were made with Sinatra. After reading this article, I'll give a look to hanami.

</comment><comment><USER96> Without being negative anyone else found this statement a bit strange - "as my bachelor thesis was about Rails"

* I am not aware of any CS program that do thesis at a bachelor level.

* It is hard for me to imagine getting approval for doing a thesis on "Rails", it is mostly a CRUD web framework.

<comment><USER97> I found it a bit strange, but not _that_ strange. First, a "thesis" isn't too uncommon at the BA level. I majored in math at UCSC where this is an option. Can't say if this is something people do in CS, but I wouldn't be surprised.

[http://www.math.ucsc.edu/undergraduate/compreq.html](http://www.math.ucsc.edu/undergraduate/compreq.html)

I could see how someone might find material in the emergence of Rails in web programming for a thesis at the undergraduate level.

</comment></comment><comment><USER98> Here is a new blogpost from DHH "Provide sharp knives"

[https://m.signalvnoise.com/provide-sharp-knives- cc0a22bf7934](https://m.signalvnoise.com/provide-sharp-knives-cc0a22bf7934)

</comment><comment><USER99> Funny, his complaint about Ruby completely owning your app and the creators wanting it that way are the same that James Shore gives for Ember (also made by the Rails people) on TDJS.

</comment><comment><USER72> This isn't a Rails gripe. He only seems to know Ruby/Rails and lashes out at it. Frameworks = Lots of abstraction. At least the abstractions in Rails aren't leaky.

<comment><USER100> solnic wrote the majority of DataMapper, its successor rom-rb, and the Virtus object modeling library. He knows much more than Rails and understands its problems.

<comment><USER101> Not to take away from solnic's many valuable contributions to open source, but I think it would be more accurate to say he was a heavy contributor to DataMapper rather than that he wrote the majority of it

[https://github.com/datamapper/dm- core/graphs/contributors](https://github.com/datamapper/dm- core/graphs/contributors)

<comment><USER40> Yes, I was on the core team between 2010-20#{hard-to-tell}. DataMapper was created by Sam Smoot and quickly taken over by Dan Kubb who did a crazy amount of work, practically rewriting it and introducing all the crucial features, and then maintained it for a couple of years with the help from a small group of people.

<comment><USER102> This is correct. It's probably hard to measure a person's total contribution to DataMapper because the gems are spread out across 20 to 30 repositories, not just dm-core.

I did maintain DM for a few years, but burnt out as there wasn't enough time to keep up with the community demands and work a full time job. There were a couple of years I effectively worked 40-60 hours a week on DM and only 5-10 on work; this wasn't tenable long term and burned me out.

The small dev team, of which solnic was a core member, are an amazing group and there's no way I could've maintained DM for even a fraction of the time I did without their support.

</comment></comment></comment></comment></comment><comment><USER103> Trying to visit this page makes my browser lock up.

</comment><comment><USER104> Rails developers are spending more time fighting Rails these days than improving it. I have the feeling that good coders have left the ROR ship and that Rails is now the framework for code-schools and learn-to-code bootcamps. It's a bit sad, but as long as Rails is tied to Basecamp I don't see any solutions.

The author is right, competition is important, the Rails/Merb scenario is the open-source version of Microsoft E.E.E

<comment><USER105> Really, even if it weren't tied to Basecamp I think if DHH remains as Rails' BDFL, we won't see the type of changes a lot of developers want to see. Which just means we need to highlight other frameworks like Hanami, Trailblazer, et al. in Ruby user groups.

</comment></comment><comment><USER106> Thanks for posting this, I otherwise I would never have learned about dry-rb, hanami, trailblazer, and rom-rb!

</comment><comment><USER107> Is Django any better?

<comment><USER76> The main difference is that Django does not rely on monkeypatching or magic methods, and for me the separation of concerns feels just natural in Django.

When I started with Rails it felt like magic, you didn't know why things worked.

</comment></comment><comment><USER108> The elves are leaving Middle Earth.

<comment><USER109> ...but these are the same people who made what Rails what it is today. What is concerning is their occupation of top seats on other hot projects (Rust, Elixir etc.).

</comment></comment><comment><USER97> Great article, and only 391 posts. Clearly I need to show up 24 hours after the fact and put in my two cents ;)

From what I've read here, it really doesn't sound like his time with rails is quite "up". It sounds like he has read the writing on the wall about rails, after a very long time with the framework (certainly longer and more involved than I've been, though I have used Rails quite a bit). This is different from realizing that a technology won't last "forever", it's a more distinct understanding that you see where things are going and how your current tools don't quite match up anymore.

But when my time with Rails is "up", that will mean that I have largely stopped using it. I'm mot counting maintenance, or perhaps the occasional one- off, I mean that if my time with a technology is "up", that means I don't use it anymore for day to day work.

I'd be interested in reading more from Piotr Solnica on this topic, because I'm in a similar spot. I don't see Rails as the ideal match for much of what I'm doing on the web, but I'm not anywhere near ready to give it up. I increasingly need much more interaction between the client and server than I get from the MVC approach, but I'm not sold on javascript front ends with a web service backend, at least not the way it's been presented now. For starters, I personally (yes, this is very much a personal trait) don't relish the idea of giving up Ruby to write most of my app in Javascript.

It's not just that I like ruby, I don't really like the idea of giving up the very rich set of languages I can choose from on the server side, or minimizing their role, in order to allow javascript to take over most of my programming work. I also feel that javascript front end frameworks are still a moving target, and I have a suspicion (like I said, I'm trying to sort this out) that when the dust settles, elaborate javascript front ends communicating with a web service written in something else won't be where I go next. I've read about some exciting new possible directions in this blog post, and I've read interesting things elsewhere (Volt, specifically, non-js languages transpiled to isomorphic javascript, more generally). It is all very exciting and promising, but is this the moment to give up on Rails, which works though I find myself increasingly shoehorning things into it? For me (again, just for me, everyone has a different set of interests and tasks), no, not yet.

Drawing on my past experience - the last time I felt this way was when web programming in java moved from the jdbc/servlets/html with libraries to struts, struts2, spring mvc, pico, spring di, jpa, hibernate, ibatis, wicket, tapestry and so forth. Looking back, I wish I'd had the conviction to stick with the old way of doing things even though I knew its days were numbered. Keep an eye on things, keep learning.

It sounds to me, from the end of this article, that this is what Piotr is doing. There are some good suggestions of where to go next, but I guess my question for the author is this: where are you going _now_? Is your time with rails "up" in the sense that you no longer have a substantial day to day use for it, that there is a new technology that you'll be working with now the way you worked with rails for 9+ years? Or is this more a situation where you see that your time with rails is ending - if not today, then certainly before long?

<comment><USER40> > Is your time with rails "up" in the sense that you no longer have a > substantial day to day use for it

It means that I'm no longer interested in supporting Rails in my gems and I accept the fact it may hurt adoption of these gems. It also means that I will be actively working on an alternative stack that can be used instead of Rails. That's why I support Hanami project and experiment with dry-web project too (which is more like a toolkit for building your own stacks, already supports Roda, and we'll add support for Hanami too).

Apart from that I'll be spending less time on OSS and instead I'll be learning new languages. That's pretty much it.

<comment><USER97> Yes, that makes sense. I'm not sure I'd read anything by you until this post, but it sounds like you're talking more about where you are putting your framework development efforts, rather than what you'd use as a framework for the time being.

Framework development is pretty far from what I do (I rely on the efforts of people like you, honestly), but like I said, I can see the need. I'll probably be using something like what you're working on in the not too distant future. Best of luck with your efforts, I hope good things come of it.

</comment></comment></comment><comment><USER110> What I'm trying to understand is why all these coding academy students are learning ruby on rails:

To make them have to go back to coding academy school in two years?

So that they maintain legacy codebases and don't touch the new shiny features the experienced engineers are working on until they get their training wheels off?

Because there is actual demand for ruby on rails despite all the hate and sunsetting of rails I see on HN?

<comment><USER111> I can't speak for other cities because I haven't watched their job markets enough, but anecdotally in Chicago I've seen it break down mostly like this:

Big companies use enterprise Java unless they're stuck with a legacy VB/ASP/Coldfusion stack, with C# less commonly.

Fintech companies use a mix of C# and C++.

Small companies started before ~2010 use PHP, with Rails less commonly.

Small companies started after ~2010 use Rails, with hipster Java (Scala/Groovy/et al) less commonly.

I can only remember offhand seeing one job ad for a company using Sinatra instead of Rails for their Ruby stack.

<comment><USER112> Is node and the JS world not taking over Chicago yet?

<comment><USER110> lol right!?

Chicago, the land the MEAN stack skipped.

</comment></comment></comment></comment><comment><USER113>

</comment><comment><USER114> Another Rails is good/bad post. Just like the rest....

</comment><comment><USER79> Oh no, the Merb heresy comes back to haunt. No merb was not better, it was just different and sucked in some different ways.

</comment><comment><USER115> A few years ago if you said anything negative about Rails, you were either pure evil or unbearably stupid; or both.

If you didn't fully embrace tableless design with CSS, despite the latter's glaring defeciencies for that task, it was the same treatment.

I also recall great pressure to adopt EJB with its deeply flawed architecture, etc.

I could go on, but the point is that there seems to come a time when all of these things face a moment of truth, wherein sober minds feel a little freer to speak aloud on their shortcomings. This frequently snowballs into all out backlash against the tech in favor of The Latest Shiny Thing.

The enforcers of what's hip and smart for everyone now move on to browbeating Developer Land with the new tech, and we all allow it to happen again. Why do we keep repeating this process when we've all seen the movie so many times?

<comment><USER116> Reminds me of "The programming language lifecycle"[1] (written in 2006), which essentially implies that the reason programmers continually search for new languages is simply out of a desire to 'distinguish' themselves from their peers, and have little to do with the actual merits of the languages in question.

[1][https://quoderat.megginson.com/2006/03/06/programming- langua...](https://quoderat.megginson.com/2006/03/06/programming-languages-of- distinction/)

</comment></comment><comment><USER117> > rather than hitting F5. Just saying.

QED. My hypothesis was confirmed, up to this point I was pretty sure he's been living under a rock possibly for decades complaining about how hard programming can sometimes be until I realized he is an IE user.

Show us a better solution without sacrificing everything that rails has given us and maybe we will listen.

<comment><USER118> What does IE have to to do with anything? F5 and ctrl/cmd+r work in all browsers.</comment></comment>


Using The DMCA To Stop Patients From Rating Their Doctors - <AUTHOR> http://www.techdirt.com/articles/20090328/1445494290.shtml <comment><USER2> "Even though you can get in trouble for filing a false DMCA notification (and even for failing to take fair use into account), most online services will quickly pull down content when receiving a DMCA takedown to preserve their safe harbor protections. So in almost all cases, the content will get pulled down, even if the content isn't really infringing."

Although this will be true for content randomly scattered about the internet there aren't that many services reviewing doctors, RateMyMD.com was mentioned, and so I would expect them to have the clout and the incentive to stand against this.

<comment><USER3> My understanding is that the DMCA says that when a site receives a take down notice they have to take down the content immediately and notify the poster. If the poster chooses the contest the take down notice, the service can put the content back up while the supposed-copyright-holder and poster fight things out in court. In return the service isn't liable for what users post.

Thus, RateMyMD.com doesn't get to fight the copyright infringement notice - the poster does.

<comment><USER4> Correct, but knowingly filing a false takedown notice is technically a criminal offense. You are swearing under penalty of perjury that you are the copyright owner.

<comment><USER5> True, but has anyone ever actually gotten charged to this, no matter how egregious? About a year or so ago, the RIAA was caught basically spamming any IP address that their automated system came up with as a possible music downloader including some networked printers that could not have been downloading.

[http://www.schneier.com/blog/archives/2008/06/framing_comput...](http://www.schneier.com/blog/archives/2008/06/framing_compute_1.html)

[http://www.schneier.com/blog/archives/2008/08/monitoring_p2p...](http://www.schneier.com/blog/archives/2008/08/monitoring_p2p.html) (this one has link to an academic paper (pdf) discussing it)

I thought there was a post on Freedom to Tinker about it too but couldn't find anything.

</comment></comment></comment></comment><comment><USER5> "Discrimination is perfectly legal so long as it's not based on a protected class (race, religion, gender, handicap, etc.). Our society hasn't quite yet reached the ridiculous point where refusal to sign copyright clauses is a protected class."

Actually, I, and at least some others here are in an anti-protected class. "Being intelligent is not a felony, but most societies rate it at least a misdemeanor."

</comment><comment><USER6> RateMyMD.com appears to be a parked domain. Maybe they mean <http://www.ratemds.com>?</comment>


Beware of hacked ISOs if you downloaded Linux Mint on February 20th - <AUTHOR> http://blog.linuxmint.com/?p=2994&_utm_source=1-2-2 <comment><USER2> Previous discussion: [https://news.ycombinator.com/item?id=11142986](https://news.ycombinator.com/item?id=11142986)

<comment><AUTHOR> Oh thanks, usually HN catches double-posts as an upvote, but I didn't notice it was already submitted with a slightly different URI.</comment></comment>


SF deals major blow to Airbnb with tough short-term rental law - <AUTHOR> http://www.sfgate.com/news/article/SF-deals-major-blow-to-Airbnb-with-tough-10617319.php <comment><USER2> I used Airbnb (in a basement rental apartment ) the last time I visited San Francisco for a week. It was _way_ cheaper for us and more centrally located than any hotel could have been. We enjoyed the experience greatly. This change means that I'm not going to be spending my next vacation in San Francisco. I'm sure that Daly City would be nice.

"... — the rental giant's refusal to provide the names, addresses and guest stays that would be part of a mandatory registration system for hosts."

there's no reason at all that the City of San Francisco needs to have any of my information just because I'm spending a few nights there.</comment>


LinkedIn files registration statement for Initial Public Offering - <AUTHOR> http://blog.linkedin.com/2011/01/27/linkedin-ipo-registration/

<comment><USER2> Some tidbits from the registration statement:

1\. 90 million registered members worldwide. 2 million registered groups. 65 million unique monthly visitors. 5.5 billion page views in December, 2010.

2\. $160 million in revenues during Q1-Q3 2010 (already doubling 2009 numbers).

3\. Company is currently profitable.

4\. Class A stock being offered to public. All key insiders (founders) hold Class B, which has a 10x voting advantage over the A. Preferred holders will convert into B at the time of the offering, thus also having a 10x voting advantage over the public shareholders. As with Google, the insider group will have firm control of the company even after the offering.

5\. Offering will be from newly issued shares of the company and also from piggy-back sales by certain preferred investors.

For anyone interested, the S-1 registration statement is here: [http://www.sec.gov/Archives/edgar/data/1271024/0001193125110...](http://www.sec.gov/Archives/edgar/data/1271024/000119312511016022/ds1.htm)

<comment><USER3> "65 million unique monthly visitors. 5.5 billion page views in December, 2010."

It's extremely ominous that they're only offering such disingenuous metrics. They even admit as much in the footnotes:

"We define unique visitors as users who have visited our website at least once during a month regardless of whether they are a member, based on data provided by comScore"

In other words, they're counting people from India and other countries that aren't worth anything to advertisers, people who get there accidentally by clicking Google results and email signatures, etc. And not only that but they aren't even using their own analytics data. It wouldn't surprise me if 80+% of their traffic was fake. Not to mention the fact that:

"The number of our registered members is higher than the number of actual members, and a substantial majority of our page views are generated by a minority of our members."

This whole thing has scam written all over it. It wouldn't surprise me if this IPO ends up throwing cold water on the valuations of the entire sector, similarly to how eToys destroyed the first dotcom bubble after they couldn't deliver their shipments in time for Christmas.</comment></comment>


GridList – Drag and drop library for a 2D resizable and responsive list of items - <AUTHOR> http://ubervu.github.io/grid/

<comment><USER2> Neat, but the zoom works the opposite way that I'd expect, is that just me?

<comment><USER3> It was reversed up until a few days ago, when I was told "adding/removing rows works the opposite way that you'd expect it" heh

Either way it's just two API calls in the demo page, the buttons aren't part of the lib itself

<comment><USER4> This is possibly because the buttons aren't labeled. Depending on whether you see them as "zoom in/out" buttons or "add/remove columns" buttons, your expectation is going to be different.

<comment><USER3> You're right, the demo is far from user friendly. Thing is we completed 90+% of the current functionality last year and then kept working on integrating it internally and the rest of our milestone. At this point so much time had passed that the open source prospects almost disappeared, so I decided it was now or never to release it to the public, since we had 4 months to "prepare" it and nothing happened. To see it gather over 1000 stars on Github is mind boggling, I didn't expect 100 honestly. The demo page is what I put together when showing the grid around internally as work in progress.

</comment></comment></comment></comment><comment><USER5> I don't see why the items should dance around when "zooming out"/adding more rows, if the available space and constraints are the same. Is there a gravity component to it?

[http://cl.ly/image/1E0A0z2C0x0b](http://cl.ly/image/1E0A0z2C0x0b) -> [http://cl.ly/image/102E232Z443j](http://cl.ly/image/102E232Z443j)

<comment><USER3> Well we're trying to 1. occupy as much empty space as possible and then 2. preserve as much as possible of the horizontal order of items when resizing the grid

PS. We have some docs for these methods [https://github.com/uberVU/grid#resizegridrows](https://github.com/uberVU/grid#resizegridrows)

</comment></comment><comment><USER6> Neat, but when building draggable things, I always end up needing to have tabs, each of which is a draggable list like this, that can accept an element from another list.

</comment><comment><USER4> Changing my browser window width doesn't seem to affect anything. Even after a page reload. It doesn't seem responsive at all. Am I missing something?

<comment><USER3> It's a horizontal grid, so it's responsive when you change height and it scrolls horizontally.

Take a look at the project README for more info: [https://github.com/uberVU/grid/blob/master/README.md](https://github.com/uberVU/grid/blob/master/README.md)

</comment></comment><comment><USER3> Github repo in case you missed it: [https://github.com/uberVU/grid](https://github.com/uberVU/grid)

</comment><comment><USER7> This can work for replicating awesomeWM in the browser. Nice.

</comment><comment><USER8> nicely done. i would reverse the functions of the zoom buttons as others have mentioned. adding responsiveness/media queries would make this ideal

</comment><comment><USER9> Shame it uses the bloated jquery UI

<comment><AUTHOR> I liked this script, do you know something good not made in jQuery UI? thanks

<comment><USER10> similar libs: packery, masonry, gridster</comment></comment></comment>