Talks

Summarized using AI

Volt

Ryan Stout • March 11, 2015 • Wrocław, Poland

In the presentation titled 'Volt' at the wroc_love.rb 2015 event, speaker Ryan Stout discusses the increasing complexity in web development and introduces an innovative solution through his isomorphic web framework for Ruby, known as Volt. He highlights key historical shifts in web development and the evolution that led to the current intricate environment, citing events like the emergence of Ruby on Rails and AJAX applications. The primary focus is on how the accumulation of technologies over time has necessitated a simplification of processes.

Key points discussed include:

- The overwhelming complexity that developers face due to the constant addition of new technologies and methodologies.

- A historical analysis of web development complexity, starting from Ruby on Rails in 2004 to modern advancements, including the rise of JavaScript frameworks and the challenges they present.

- The concept of isomorphic app development, which allows code sharing between client and server to reduce complexity.
- Introduction of Volt as an isomorphic framework that leverages Opal, enabling Ruby code to be compiled to JavaScript, thus facilitating smoother development.
- Explanation of Volt’s architecture, which utilizes reactive bindings, automatic data synchronization, and a Model-View-ViewModel (MVVM) pattern to enhance user interactivity and simplify web application development.
- A live coding demonstration showcasing Volt’s capabilities in building a dynamic to-do list application, illustrating how it allows direct Ruby code usage in templates and real-time data updates.

In conclusion, Ryan Stout emphasizes that Volt aims to alleviate common web development challenges by centralizing state management and establishing a unified architecture, ultimately improving efficiency and outcomes for developers. By utilizing Volt, developers can streamline their workflows, eliminate excess complexity, and maintain a single language across both client and server codebases.

Volt
Ryan Stout • March 11, 2015 • Wrocław, Poland

wroclove.rb 2015

00:00:12.240 First, thanks for having me. I'm just going to jump right in.
00:00:20.080 For those of you who don't know me, my name is Ryan Stout. You can find me on Twitter and GitHub, pretty much everywhere on the internet at @RyanStout. Interestingly, there is a comedian from where I'm from who has a similar name and the Twitter handle @RyanStout.
00:00:33.520 What's funny is that about twice a day I receive tweets from random people who think they are tweeting the comedian. They tell me I'm funny, and I can't help but think, 'Yes, I am,' even though I know they're not referring to me. So, I just want to give a disclaimer: if I make a joke that doesn't land, just know I've had way too much encouragement from random strangers on the internet.
00:01:03.920 But what I really want to talk about today is the complexity in web development. As developers, especially those of us who have been programming for a long time, we start to notice a pattern where new technologies and techniques emerge, and we add them to our stack. Over time, this increases the complexity of our work.
00:01:16.720 As we add more technologies, tools, and patterns to our toolkit, it becomes overwhelming. It's akin to packing a suitcase: as you keep adding items, eventually, you need to dump it out and start over. I believe we're at a point in web development where the complexity has become so high that many are beginning to 'dump their suitcases out' and explore simpler, more effective ways to build.
00:01:35.920 This process of repacking enables us to determine what we genuinely need and what we can eliminate. Sometimes, we get lucky and discover better methodologies by examining the bigger picture. Many of us, myself included, are looking for strategies to simplify our work while maintaining the benefits we’ve previously gained.
00:02:15.200 To provide some historical context, especially for those new to web development, I want to discuss the history of complexity in this field. One significant shift occurred around 2004 when Ruby on Rails emerged. Before Rails, web applications primarily rendered HTML and handled form input. Rails took lessons from ten years of Java web development and other paradigms and repackaged them in a more elegant and effective way.
00:02:54.000 One of the key innovations of Rails was the MVC (Model-View-Controller) pattern, which became a standard way to structure applications. In 2004, a typical Rails app would include routes, models, controllers, and views, all geared towards rendering HTML. However, this approach was much simpler and cleaner compared to the methods that preceded it.
00:03:20.640 In 2005, Gmail launched, introducing AJAX applications. At that time, AJAX meant we could update parts of our HTML without refreshing the whole page. By 2005, AJAX's popularity exploded, leading to an increasing reliance on JavaScript, which continued to grow as developers became more proactive in using JavaScript rather than simply making XMLHttpRequests.
00:03:43.760 By 2009, as client-side code volumes increased, we needed to establish best practices to ensure efficient delivery of that code to the browser. Rails anticipated this requirement and implemented the Asset Pipeline, which streamlined how assets were handled. Meanwhile, by 2011, I began using Ember and started to work on implementing MVC principles on the client side.
00:05:00.000 With the demand for modular components on the client side on the rise, tools like Bower emerged to handle front-end asset loading. It wasn't until 2013 that front-end routing truly improved, thanks in part to advancements in the browser's History API. Thus, by 2015, we had progressed to a highly complex web development environment.
00:05:37.760 Day-to-day, I feel the weight of this complexity, which can be overwhelming. I’ve noticed that the Rails team is aware of this challenge and is working hard to address it. I recall seeing a tweet where one user expressed excitement for RailsConf in Atlanta, mentioning that 'Rails 5 is going to be... okay' with an emoticon. This suggests a lukewarm enthusiasm.
00:06:18.560 It's intriguing that someone’s excitement about Rails 5 may be lackluster compared to their active pursuits outside of development, such as racing cars.
00:06:43.360 So, what is the solution to all this complexity? Some might half-joke that it boils down to TurboLinks, but I'm kidding here. A more serious consideration is the concept of isomorphic app development, which involves sharing code between the client and server.
00:07:01.360 This term, ‘isomorphic’ comes from mathematics, where it refers to two structures sharing a similar form. In software development, we repurpose this term to signify sharing code between the client and server. If we examine the current complexities, we can see how code duplication abounds and thus signifies a need for simpler methodologies.
00:07:40.960 Ideally, we would want to only write one set of views, controllers, and models on both ends, thereby unifying our routes. Once we share models on both sides, we eliminate manual data synchronization since we could alter the model on one end, which would automatically sync to the other via mechanisms such as WebSockets.
00:08:27.680 I want to introduce the web framework I have been working on called Volt, which is an isomorphic web framework for Ruby. You might be questioning how we can have an isomorphic framework in Ruby since JavaScript is typically used for client-side development. The answer is that Volt leverages a project called Opal.
00:09:14.239 So how many people have heard of Opal? Great! Opal is a Ruby to JavaScript compiler, often referred to as a transpiler. It allows us to write our application code in Ruby while compiling it to JavaScript, thus facilitating code-sharing across the client and server.
00:09:55.760 Volt enables us to share controllers, models, views, and routes. You can write the same code for both the client and server, which I believe opens a myriad of possibilities for simplifying our application development.
00:10:18.720 With Volt, you get reactive bindings to the DOM akin to features available in Ember and Angular. Additionally, it provides automatic data synchronization and is designed to build applications using nested components.
00:10:45.440 As a Rails developer, I've often envisioned code being moved into Rails engines or gems during development. However, I realized that my code often becomes tightly coupled with other aspects of the application. Volt's philosophy is to start with component-based architecture, allowing easier extraction of components when necessary.
00:11:29.679 Next, let's explore Opal in more detail. There is a common misconception that compiling a language to JavaScript adds substantial complexity, and we often associate that complexity with the pitfalls of JavaScript itself.
00:12:04.960 JavaScript has its own sets of challenges, including type coercion and a lack of a standard library. Additionally, some of the language's oddities stem from its rapid development—created in just ten days—leading to enduring issues.
00:12:43.919 I want to clarify that I've been involved in JavaScript development since 1996, and while it's a usable language, I feel Ruby has benefitted from a smaller community over the years, refining itself and becoming a more robust language for building applications.
00:13:18.559 When discussing the complexities of compiling Ruby to JavaScript, it's important to recognize that while there might be some concerns about performance and debugging complexity, these are often overstated. For example, a well-known figure in the JavaScript community, Douglas Crockford, has emphasized simplifying his coding practices and avoiding certain language features, which could highlight the struggles developers encounter.
00:14:19.680 Therefore, understanding Opal offers a refreshing perspective on the perception of complexity in terms of code compilation. Many users have had positive experiences and indicated that experimenting with Opal often yields no issues, which contrasts with the expectation that using a compiler will generate hurdles.
00:15:19.760 To provide some insight, transpiling from Ruby to JavaScript works differently than conventional language compilers—you map concepts from Ruby directly to JavaScript. The compiled code retains a structure that resembles JavaScript, making it more understandable.
00:15:55.360 With that in mind, thanks to source maps, we can trace errors back to the original Ruby code, making debugging significantly easier. Framework black boxing also allows us to ignore specific framework-related errors, presenting only our code in stack traces.
00:16:47.360 Furthermore, Opal's IRB function enables running Ruby code directly in the browser. Another point worth mentioning is that Opal is being tested against Ruby specs. Even though it doesn’t pass every single test, it provides a high level of confidence in the reliability of the framework.
00:17:55.439 Concerns about file size are prevalent, but I've found that Opal maintains competitive sizes compared to other frameworks like Ember and Angular. Even with runtime components, the size remains manageable.
00:18:33.440 People often worry about the performance of compiled Ruby to JavaScript. For instance, when comparing performance between JSON stringification implementations, Opal's implementation actually holds up quite well against standard JavaScript methods.
00:19:19.920 Another benefit of using Opal is the simplicity with which it bridges data between Ruby and JavaScript. With local variables functioning in a familiar manner, integrating JavaScript calls is seamless.
00:19:52.239 The key takeaway is that working with Opal allows Ruby developers to retain a level of familiarity while navigating the complexities of web development, yielding multiple advantages.
00:20:39.360 Now, let me explain how Volt operates. Volt combines collections—structures that persist data—similar to structures like ActiveRecord, but they maintain a uniform interface across various data persistence methods.
00:21:47.440 Volt is an MVVM (Model-View-ViewModel) framework, which differs from traditional MVC. In Volt, we begin with the view, and each time a binding is triggered in the templates, it calls the relevant code in the associated controller.
00:22:24.159 I can demonstrate this with a quick live coding session. I'll start a basic Volt app that immediately offers functionality, including auto-reloading when I edit the templates. My aim is to build a simple to-do list application.
00:23:02.559 With Volt, bindings allow me to use Ruby code directly in templates. For instance, I can create a form to add a to-do while binding the inputs directly to the respective data models. As I code, you'll see that my changes reflect dynamically in the application.
00:23:50.560 I can quickly implement functionality such as adding and deleting items on the to-do list by using buttons that invoke methods in the controller. Additionally, since the model updates automatically when I alter the to-do items, the app reacts seamlessly to the actions performed.
00:24:57.839 With targeted assistance, I can even track how many to-dos are completed with a simple change linking to the model's properties. By making these adjustments, I create a more dynamic and interactive user experience.
00:26:14.239 I can also add enhancement features such as highlighting selected tasks or providing feedback through pop-ups or dropdowns to facilitate an intuitive interface. This interactivity works efficiently across multiple devices, synchronizing effortlessly.
00:27:20.640 Lastly, I wanted to introduce components, which can provide additional features and support validation and field handling, making it easier to manage input data efficiently.
00:28:12.639 In creating validations, I can leverage these components to ensure that inputs meet specified criteria while maintaining a clean interface that simplifies the user experience.
00:29:03.920 Finally, in recap, Volt distinguishes itself with features like automatic syncing, enabling developers to avoid extensive REST API configurations while maintaining a single development language, thus alleviating the complexities commonly encountered in web development.
00:29:55.840 By centralizing state management and providing a unified architecture, Volt enables smoother operations for developers, leading to improved efficiency and outcomes in project development.
Explore all talks recorded at wroclove.rb 2015
+6