A la carte, please!

Talks

A la carte, please!

Florian Gilcher

@skade

#ruby-on-rails

#web-development

A la carte, please!

by Florian Gilcher

In the talk "A la carte, please!" presented by Florian Gilcher at the wroc_love.rb 2013 event, the speaker critically examines the philosophy behind the Ruby on Rails framework, likening it to 'omakase'—a Japanese dining experience where the chef decides the meal. Gilcher, as an outsider to the Rails community and a supporter of the Padrino framework, advocates for a more flexible approach to programming akin to 'à la carte.' The main points discussed include:

Opinionated Framework: Rails is heavily opinionated about its structure and processes, which can limit developers’ flexibility and adaptability.
Complexity Concealment: Rails attempts to simplify the user experience by hiding complexities, which can lead to misunderstandings and unexpected behaviors in code.
Limited Development Environment: The Rails generator system has restrictions that hinder developers from modifying or removing components easily.
Static Evolution: Although Rails was initially beneficial for new developers, its static nature may prevent users from leveraging advancements in the programming landscape.
Security Risks: Rails assumes defaults that may not be secure, exposing developers to vulnerabilities without their explicit awareness.
Comparison with Padrino: Gilcher promotes Padrino as a framework that values transparent support for integrations and allows developers to generate projects more tailored to their needs.

Through the talk, Gilcher illustrates that the notion of ease of use does not equate to the speed of setup but should instead focus on clear guidelines and a broader integration philosophy. He concludes that developers should have the freedom to explore various options in the Ruby ecosystem, balancing reliance on frameworks with the need to customize according to specific project requirements.

00:00:18.320 I'd like to welcome Florian Gilcher. Give him a big round of applause!

00:00:27.760 Hello! Just as Reg mentioned, there are frameworks for literate documentation that are important. Here's a cool one that I'm using, so please take a note.

00:00:41.280 As introduced, I'm Florian Gilcher. These are all my accounts, but the most important one is my Twitter account, which is @agarac. You can find all the others on the slides. I own a company called Ascerra, where we build backend systems and APIs.

00:00:52.079 I am also running another conference in the summer in Berlin. Just to mention how we organized the bus to get here from Berlin, it was a fun experience, and maybe the folks from Wrocław could organize a bus to go to Berlin next time.

00:01:11.760 I like this talk because I work on a not-so-big framework called Padrino RB. Padrino emphasizes building projects in small components, where controllers are organized into appropriate components.

00:01:24.600 This framework allows programmers the flexibility to organize their code in a manner that makes sense for their specific projects. I want to clarify that this is not a talk about my framework being better than yours; it's from the perspective of an outsider to the Rails community. I wish to discuss the philosophy behind Rails, which David Heinemeier Hansson has described as 'omakase.' For those unfamiliar, omakase is a Japanese term used in sushi restaurants where you essentially say, 'I trust the chef to serve me something great.'

00:02:03.200 Hansson's blog post critiques the Rails project. While he believes it is an excellent framework, he acknowledges that 'omakase' has hidden complexities. He states that although patrons can express exceptions and substitutions, it immediately breaks down when it comes to programming. My perspective is that if Rails were truly omakase, the expectation would be to specify what you don’t want or need when ordering.

00:02:29.200 The big question is whether this is genuinely what you ordered or what you want to order. I personally prefer 'à la carte,' and that’s why I’ve chosen to engage in this talk.

00:02:39.840 From my point of view, Rails has several issues. The first is that it is opinionated about everything. There's nothing in the framework that doesn't come with a predefined opinion from Rails.

00:02:52.480 A small example is whether to include bin files in your git repository. This idea led to an interesting blog post, as it's a minor, yet indicative detail. Additionally, since Rails presents as a 'cooked meal' for user convenience, it attempts to conceal the complexities of composition, providing a smooth experience without exposing the underlying structure.

00:03:12.560 Another significant issue is that it adopts the position: 'just take what you ordered.' This perspective makes it challenging to argue against anything within the framework. If you want to order something different, do so—but not Rails. This presents practical challenges in a development environment.

00:03:40.000 For instance, the generator system in Rails is somewhat limited. It’s tailored for building Rails generators and lacks the flexibility to modify or remove components, which hinders developers. Furthermore, the support within the framework for setting up projects with varied components is also weak. For example, if you want to use RSpec for testing, you’ll find no native support from Rails—it's RSpec that has to provide support for Rails.

00:05:03.040 Rails creates a challenging environment where high-level abstractions like adapters and view models, which are common in other frameworks, are noticeably absent. While it aims for simplicity and flexibility, it simultaneously imposes a considerable framework size, leading to inconsistencies in how developers approach project setups.

00:06:56.160 One of the biggest issues is that Rails tries to hide as much complexity from you as it can. This approach can lead to potential misunderstandings, especially when code behaves unexpectedly. A humorous example from my experience was in Argentina, where the meat quality can vary significantly.

00:08:46.880 The critical point here is that sometimes users don’t need to know about the underlying complexities, which can be problematic for professional programmers. In my framework, Padrino, we often take a different approach, providing clarity on whether a piece of code was loaded from a gem, allowing developers to see what components are in use.

00:10:19.040 I believe that Rails is optimized to get a full stack running as quickly as possible, but this ultimately complicates the user experience and contradicts the guidance that should be present in a framework.

00:10:28.720 Moreover, the discovery aspect of APIs is often hindered due to attempts to keep things implicit. For frameworks such as Rails, you might open an Active Record class and not know what attributes are available simply because they are tied to the runtime's current database context.

00:12:12.560 Additionally, Steve Klavnik, a fellow critic of Rails, has identified that Rails has two default stacks: the 'omakase stack,' which is the standard stack involving ERB, MySQL, and MiniTest, and the 'prime stack,' which favors PostgreSQL, RSpec, and a different modeling philosophy. The reality is that the differences between them are not as significant as they may seem.

00:14:15.440 Starting with the omakase stack tends to create a sense of confinement—developers often seek improvements that diverge from this initial setup rather than exploring a broader spectrum due to the inherent limitations in flexibility within Rails. Meanwhile, this 'omakase' meal, although enjoyable, has potential dangers, such as security vulnerabilities stemming from default settings. Security issues can arise when the framework assumes defaults that may expose users to security risks.

00:16:34.120 Historically, when Rails began, it provided a solid path for new developers by creating an opinionated default structure conducive to learning. However, as the development landscape has evolved, this philosophy is starting to show its constraints while various Ruby components continue to mature. Rails has primarily remained static in its overall philosophy, which can result in developers missing out on significant advancements occurring throughout the programming world.

00:18:29.040 My position is that we should rethink how ease of use and support are defined in frameworks. Framework support should be more about having a development philosophy that embraces a wide variety of integrations rather than strictly adhering to defined stacks, like SQL or NoSQL. Additionally, ease of use does not equal speed of setup; it requires a balance of setup time with clear guidelines on extending frameworks.

00:20:24.000 If menus are as appealing as they can be, I would prefer to order off a menu! Thank you for your attention.

00:20:41.600 Now, we have about ten minutes for questions or discussions. Feel free to come up to the stage or ask questions from your seat.

00:21:07.760 If Rails does so many things wrong, what does Padrino do better? The key difference is that we are much clearer about the support we provide through plugins. If you want RSpec, you can generate your project with the appropriate settings without needing to adjust the gem file.

00:22:00.800 The question arises: should I use it for post modifications, or should I go with something else? Padrino is essentially a way to organize a Sinatra application. It builds on Sinatra as a library.

00:22:39.600 To clarify further, the differences between Rails and Padrino largely depend on the project generator's functionality. In Rails, you have specific switches that could be fewer in number, but it still allows for additional flexibility through the installation of gems as needed.

00:23:56.400 In terms of security, it’s essential that smaller frameworks, like those associated with Sinatra, consider incorporating standard security measures. Padrino installs a standard security stack by default to maintain integrity while making developers more conscious of potential vulnerabilities.

00:24:35.440 While Rails does an admirable job of pursuing proactive security, frameworks that activate components automatically without explicit developer consent can introduce vulnerabilities. It is important for developers to be aware of what’s being activated by the framework from the get-go.

00:26:54.080 The ongoing debate regarding Rails revolves around adjusting security philosophies and framework components over time. The presence of gems can make developers vulnerable if not utilized consciously, as many gems rely on Rails without considering distinct frameworks, hindering flexibility.

00:29:08.600 In the end, developers are encouraged to explore various options to bring their projects to life, whether it's through Padrino, Rails, or exploring other alternatives in the Ruby ecosystem. Finding the right balance between framework reliance and the freedom to explore and adjust according to project needs is critical.

wroc_love.rb 2013