00:00:18.680
All right, thanks everybody for sticking around for my talk. I'm going to go ahead and get started. For those of you who don't know me, my name is Ryan Stout.
00:00:25.519
If you Google my name, you will find nothing about me because there is a comedian who has my name. This is actually good for me because I happen to have the handle 'ran Stout' on Twitter.
00:00:31.039
So at least twice a day, I look down at my phone and see a tweet from someone I don't know telling me I'm hilarious. I can't help but think to myself, 'Yes, I am.'
00:00:43.559
I just wanted to provide a little context in case I make a joke that falls flat. I've had way too much encouragement from random strangers on the Internet.
00:00:58.239
What I really want to talk about today is complexity in web development. I've been building web apps since 1996, starting with my first form mailer in Perl.
00:01:09.400
I've noticed a pattern, and I think many of us in the web development community see this as well. We start with a simple stack, and as new technologies and techniques emerge, we keep adding to our stack.
00:01:20.960
Although this allows us to build better things, it also increases complexity. Things start getting more complicated, and it takes someone to stop and evaluate the situation.
00:01:35.880
It's kind of like packing a suitcase; at some point, you realize there’s too much going on, and you have to dump it all out and start over. Many people in the web community are now looking at ways to simplify things.
00:01:47.600
This talk is about one approach to achieving that. Before I dive deeper, I want to touch on some history. If you’ve been in web development for a while, you’ve likely seen complexity come and go.
00:02:04.479
Around 2004 and shortly thereafter was kind of a low point for complexity. Rails had just come out, and at that time, I was doing professional Java development. Many of the things we were doing were disorganized and repetitive.
00:02:39.959
Rails was able to move a lot of that logic into the framework, providing a structure to organize our applications. Additionally, before working with Rails, in 2004, we were mainly producing HTML.
00:03:00.480
Rails took the previous ten years of HTML production and figured out a solid abstraction for it. In the subsequent year, Gmail launched, and so did the buzz around AJAX, leading everyone to embrace rendering views without full HTTP requests.
00:03:23.239
As years passed, our JavaScript usage grew, and Rails introduced the Asset Pipeline in response to sending more JavaScript and CSS to the client. By 2009, we were sending so much data that best practices began to evolve.
00:03:52.479
By 2011, I had started employing full MVC on the client-side, using Ember and syncing data between the browser and server with AJAX. The landscape continued to change and by 2012, the JavaScript ecosystem had exploded with various libraries.
00:04:06.319
In 2013, we began experiencing improved routing for front-end frameworks, leading us to a state in 2014 where our applications were more complex than ever, yet we desired many features that seemed unmanageable.
00:04:22.479
People outside of our web community find this complexity astonishing. I believe they find it crazy because it is crazy. We've kind of been in a boiling frog scenario regarding the duplication of logic and overall complexity.
00:04:37.360
At times, I feel overwhelmed by this situation. So, what’s the solution? Obviously, it’s Turbolinks—just kidding! The answer lies in isomorphic app development.
00:05:01.120
Isomorphic is a mathematical term meaning similar in form. To popularize a buzzword, you can’t go wrong with rebranding a math term because they sound cool, and nobody knows what they mean in web development.
00:05:08.640
In our context, isomorphic refers to sharing code between the client and server. If you look at the complexity charts, it’s apparent that we need to eliminate duplication by finding a way to share code effectively.
00:05:25.840
Once we achieve this, we can have models on both sides of the application, allowing them to communicate with each other seamlessly. We could also use technologies like WebSockets to automatically update clients in real time.
00:05:43.920
This concept of autosync is something I want to discuss further. Additionally, we ought to unify our package management and asset packaging strategies, reinforcing the idea that isomorphic code is about sharing between the client and server.
00:06:07.680
For those of you who haven't heard of Volt, it is an isomorphic web framework for Ruby. You might be thinking, 'How can you write an isomorphic framework in Ruby? JavaScript is the language of the browser!'
00:06:24.000
We're leveraging a project called Opal, which allows you to write regular Ruby code and compile it to JavaScript. If you haven't used Opal yet, it's quite excellent.
00:06:39.120
Volt allows you, through Opal, to share your code—controllers, models, views, and routes—between the client and server. This means you can run the same code on both ends.
00:06:53.760
I'm genuinely excited about this possibility, and trying to emphasize this point. Volt provides many benefits similar to those found in front-end frameworks, including reactive bindings.
00:07:09.440
It has DOM bindings that know to update automatically whenever your models change, allowing you to write declarative DOM manipulations in Ruby. Additionally, it features automatic data syncing.
00:07:29.040
If I modify a model on my client side, that change will sync back to the database. Based on certain rules you can establish, it will also sync to all other clients, enabling shared functionality.
00:07:47.200
For instance, if you have a shared text field, others can type into it simultaneously. As a developer using Volt, you don't need to do much work to make this happen; Volt handles it internally.
00:08:05.720
Another interesting aspect of Volt is that you can build your applications as nested components. A pattern I've seen in web development is that we start building something and plan to extract it into a gem later.
00:08:20.040
However, by the time we get to that point, it’s often too late, as it becomes too integrated into the app. Volt encourages building your app's parts as siloed components.
00:08:39.520
You can declare dependencies between these components, making it easy to package them into a gem whenever necessary. Now, let’s return to Opal, which is the Ruby to JavaScript compiler.
00:08:53.440
There is a common perception that compiling to JavaScript complicates things, leading to a belief that it adds significant complexity. In our minds, we picture a lengthy path from raw JavaScript to compiled output.
00:09:07.640
On one side, we see the base JavaScript language with its inconsistencies and issues. However, if we truly evaluate the situation, compiling to JavaScript offers major advantages.
00:09:26.320
I can concede that additional debugging complexity exists when using Opal, but it’s minimal. Other concerns regarding performance and bridging to JavaScript can be largely mitigated.
00:09:41.200
Douglas Crockford is a significant name in the JavaScript community, and in one of his presentations, he mentions halting the use of certain JavaScript functionalities, highlighting its many broken aspects.
00:09:54.560
Having written ample JavaScript over the years, I believe the reasons people persist with it sometimes relate to enduring various pains. There's also a belief that, given our experiences with JavaScript, using Opal should come with inherent problems.
00:10:13.920
However, what compiling to JavaScript excels at is concealing some of that complexity. With C development, you don't need to know the intricate details of registers; the compiler does that work.
00:10:30.720
Similar principles apply to how Opal operates—we're able to focus on Ruby while it handles the translation to JavaScript. Now, let's quickly discuss file size concerns, which are always relevant.
00:10:43.360
I'll share some uncompressed and minified file size comparisons across various libraries, including Opal and Volt. Opal, along with Volt, isn't adding too much overhead when it comes to file sizes.
00:10:56.160
In fact, Volt offers a full data syncing layer, which would equate to certain advantages over other frameworks like Ember and Angular. I can assure you I haven’t done any work to minimize file size.
00:11:09.120
Debugging in Opal is also quite pleasant. Unlike other Ruby to JavaScript compilations that use bytecode and virtual machines, Opal transpiles Ruby to JavaScript.
00:11:26.640
Ruby and JavaScript are similar enough for this to be practical—local variables in Opal map directly to local variables in JavaScript, and instance variables become object properties.
00:11:40.800
Methods in Opal match up with object properties prefixed with a dollar sign, giving you easy-to-trace behavior. Additionally, Opal's generator provides source maps, making debugging straight-forward.
00:11:57.000
Thus, when you encounter an error, you can directly reference your Ruby code for clarity. Recent features in browsers allow for framework black-boxing, which treats Volt and Opal's code as native, simplifying debugging further.
00:12:09.760
You can even engage with IRB in the browser through Opal for immediate feedback. Opal is rigorously aligned with Ruby specs, so testing in both environments yields consistent results.
00:12:20.960
As for performance, while there may be slight hits, they aren't substantial, especially considering robustness in JavaScript testing and performance are generally quite satisfactory.
00:12:35.360
If you're engaging in extensive calculations, it may be preferable to drop to JavaScript for efficiency. Thankfully, anytime during Opal, you can bridge back to JavaScript seamlessly.
00:12:55.760
Hopefully, that was a brief yet comprehensive overview of Opal's advantages. It becomes clear that compiling to JavaScript isn’t just feasible but beneficial.
00:13:07.680
Interestingly, the JavaScript community appears most open to compiling, likely due to their hands-on experience. This makes it exciting to see how these new JavaScript languages are evolving.
00:13:20.160
Returning to Volt, it introduces a concept of collections, which help abstract how we store data. There are various collections designed for different storage locations but with a similar interface.
00:13:30.400
For example, 'page' is used for temporary memory, while 'store' is for databases, and 'pams' deals with browser URL parameters. This categorization allows for streamlined data handling.
00:13:48.640
In contrast to traditional MVC frameworks like Rails, which process requests on the server side, Volt primarily operates as a front-end solution, utilizing an MVVM pattern.
00:14:05.520
We still refer to our components as controllers, even though they essentially serve as our view model. When you engage bindings in Volt, it’ll automatically signal methods in the controller.
00:14:17.680
If the controller doesn't have certain data, it can then respond with the model that does hold that data. This creates an efficient method of maintaining accurate data in the interface.
00:14:25.920
In showcasing this feature, I want to do a quick live coding demonstration. Immediately, I’ll create a simple to-do app to illustrate how to utilize Volt effectively.
00:14:38.560
As you see, Volt implements an automatic code push feature that reloads changes instantly upon saving, streamlining development further.
00:14:53.120
For the to-do items, I'm going to create a form that will register the input, bind it to our collection, and establish a proper interaction channel within Volt.
00:15:04.480
The input field will link with a new to-do object in the page collection. By leveraging binding, it allows accurate retrieval and processing of input seamlessly.
00:15:18.240
Once the add function is called, the controller updates the model accordingly. Additionally, I'm implementing a table to display the to-dos dynamically.
00:15:29.440
I aim to make everything work fluently, catering to changes in labels and bound values so that users experience a seamless interface.
00:15:44.480
Moreover, introducing an interactive checkbox to each to-do allows toggling completion status, which enhances user engagement significantly.
00:15:58.720
Consequently, the application becomes richer in functionality, with the ability to reflect completed tasks through visual cues in the UI.
00:16:15.600
I then created a mechanism for the to-do delete function, enabling users to manage their tasks more effectively. As the controller stores these elements within the page, transitions between states are smoother.
00:16:29.840
With the added ability to synchronize multiple clients in real time, whenever a change happens on one client, it automatically updates others—it’s incredibly efficient.
00:16:44.480
The user experience remains intact regardless of whether you operate with the 'page' collection or a 'store' in your app. Thus, we see tremendous synergy in using Volt.
00:17:00.480
Next, I want to implement an index selection within the to-do list. This process will allow users to click and interact with index values effectively while navigating through their tasks.
00:17:14.560
By managing current selections through an integer index, users will find navigating their to-dos more intuitive and cohesive with the app’s capabilities.
00:17:31.120
Once that’s done, we’ll implement a method to extract the selected to-do details and display its attributes, enriching user interaction with streamlined access.
00:17:44.160
Now, I’ll add outputs for titles and descriptions within the interface while ensuring data consistency using the designated control paths.
00:17:58.080
This quick demo emphasizes how easily users can work within a modern Ruby framework like Volt, offering a replicable balancing act between simplicity and functionality.
00:18:12.720
I want to highlight again that Volt provides ways to build components, simplifying bundle packaging for both client-side and server-side implementation while maintaining code clarity.
00:18:23.920
Validations can easily be integrated into your application logic as it processes actions, ensuring prompts that offer users more guidance in interaction.
00:18:35.360
Users can set validations effortlessly to enhance their applications, which demonstrates how efficiently components can be set up within the Volt ecosystem.
00:18:48.880
There are numerous components available, including field validations, pagination, file uploads, and authentication templates. Volt’s continuously growing ecosystem is pivotal to its potential.
00:19:06.960
Additionally, Volt handles tasks—that is, executing side-server code requests from the client, effectively using promise styles to manage responses and permissions.
00:19:25.760
In summary, we've seen how we can rethink how we build web apps, focusing on clarity and organization while eliminating the need for excessive REST APIs for internal structures.
00:19:43.600
For me, as a web developer, I've found that I've spent the last few years overbuilding REST APIs just for the front-end to consume. We need to eliminate that redundancy.
00:20:03.200
A unified approach, condensed into one language, allows us to reduce the complexity while simplifying component and state management within our applications.
00:20:19.520
I didn’t have time to dive into it today, but we also have a unified router that helps you share routing between the client and server, reflecting ambitions to streamline the development process.
00:20:36.560
As we explore these possibilities, we hope to retain all the capabilities you were able to incorporate in previous frameworks while paving new paths for effectiveness.
00:20:50.920
Volt is still a major work in progress. If anyone is interested in getting started with it, we have video tutorials available and documentation for reference and guidance.
00:21:05.680
I’m active in the community, and you can reach out on GitHub for any support. It’s thrilling that the initial buzz about Volt reached such a wide audience, marked by significant interest from fellow developers.
00:21:23.280
We're aiming to expand functionality soon, including adding multiple data stores and better Rails integration for those working with legacy applications.
00:21:36.560
Server-side rendering of HTML is also on the agenda, which will enhance initial load times and SEO. Furthermore, we’re contemplating RubyMotion integration for mobile application compatibility.
00:21:52.960
If anyone finds this exciting and works for a company that might be interested in sponsoring our efforts, please encourage them to consider investing in Volt.
00:22:08.400
Finally, I want to express my gratitude to everyone who contributed to this project and helped us to get where we are today. You can check out more information at voltframework.com.
00:22:24.640
Does anybody have any questions?
00:22:34.560
Thank you!
