Talks

The Front-End Future

With the rise of Javascript MVC frameworks like Ember and Backbone, web programmers find themselves at a fork in the road. If they keep doing server-side web programming, they'll benefit from tried-and-true tools and techniques. If they jump into Javascript MVC, they may be able to offer a more responsive web experience, but at significant added development cost. Which should they choose?

This talk will address the strategic costs and benefits of using Javascript MVC today. I will touch on subjects such as development speed, usability, conceptual similarities with desktop and mobile applications, the decoupling of rendering and routing from server logic, and the state of the emerging Javascript MVC community. I will also discuss the impact of this seismic change on Ruby, Rails, and your career as a software engineer.

Help us caption & translate this video!

http://amara.org/v/FGjF/

GoRuCo 2012

00:00:16.640 Hi everyone, thanks for coming! I hope you're having a good day.
00:00:22.359 I've been an organizer of GoRuCo for the whole time; this is our sixth year. I've been there every year, and I've never wanted to give a talk here, actually.
00:00:29.400 I've never had an idea that I thought was important enough, but I wanted to talk about this topic today.
00:00:34.559 The title of my talk is 'The Front-End Future.' Today, I will be discussing thick client web development.
00:00:41.039 This development approach is having a significant impact on the web engineering industry.
00:00:46.680 I actually think that here in the Ruby and Rails scene, we are not sufficiently discussing it. So I want to initiate that discussion.
00:00:54.480 First, let's start with just some basic terms. Some of you may not be familiar with the concepts of thin and thick clients, but I'm sure you understand the general ideas.
00:01:00.000 A thin client is a traditional server-side view in Ruby on Rails. In this model, the server receives a request, renders the view in Ruby, and sends a large HTML page to the browser.
00:01:07.040 That's something we've all done, I'm sure. A thick client, on the other hand, is the new trend.
00:01:12.520 In this model, the view logic is moved into the browser, often utilizing JavaScript frameworks like Backbone.js or Ember.
00:01:17.600 The communication between the browser and the server employs a JSON-based REST interface.
00:01:23.119 This talk contains technical aspects, but it is not a deeply technical discussion. Instead, it will be more about macro considerations and strategic thinking.
00:01:29.479 I aim to discuss how you should think about thick client development when building a new product, leading an engineering team, and most importantly, directing your own personal engineering career.
00:01:35.680 However, first, I want to start with a disclaimer.
00:01:41.399 Big disclaimer: I don’t truly know what I’m talking about, and honestly, none of us do.
00:01:48.079 This is an exceptionally chaotic time in our industry. We're essentially discussing probabilities, hedging bets on things that may or may not happen.
00:01:54.360 It's very difficult to predict with certainty what the next couple of years will look like, but I don't believe that should lead to pessimism.
00:02:05.200 There's a lot of exciting potential in that chaos, so let's begin by considering whether thick client development is right for your product.
00:02:11.680 If you were starting a new web product today, would you opt for a thin client or a thick client? What are the reasons for choosing one over the other?
00:02:18.319 There are many pros and cons to consider. Let's begin with some of the drawbacks.
00:02:23.959 Thick client development is inherently more complicated. Dealing with fine-grained events can involve more work.
00:02:30.280 It will be slower initially because we are still early in this process, and a lot of practices, libraries, and frameworks are still developing.
00:02:37.120 You'll end up spending more time on basic tasks than you would with established methods.
00:02:42.959 Additionally, there is significant turnover in libraries and frameworks.
00:02:48.239 If you choose Backbone, Angular, or Ember, you will likely face a bumpier upgrade path than if you were simply using server-side Rails.
00:02:54.000 From time to time, there is also a risk of selecting a framework that becomes outdated, either due to lack of maintenance or being absorbed into another project.
00:03:00.239 Staying current with the state-of-the-art in the field can be a bumpy path.
00:03:06.440 Testing is inherently more complicated as well. Unit testing is improving, with tools like Jasmine.
00:03:12.319 However, integration testing remains challenging, typically relying on Selenium for browser-based tests.
00:03:17.879 While Selenium is a remarkable feat of engineering, it is also a significant headache when writing tests that need to pass consistently on a CI server.
00:03:24.080 Furthermore, first-page load speed is a critical consideration.
00:03:29.400 The thick client must bootstrap by loading all the additional JavaScript code and templates into the browser before displaying anything.
00:03:36.400 For instance, when you open Gmail, there's a progress bar, and it takes a few seconds.
00:03:43.640 In Gmail's case, this trade-off is acceptable since users often leave it open for extended periods.
00:03:51.519 However, if your application is designed for users who typically visit a few pages and then leave, this bootstrapping phase could be a significant issue.
00:03:58.000 Twitter is a pertinent example. They previously rolled out a very thick client for their website, but they later reassessed this approach.
00:04:04.799 They even reverted some aspects of their approach, like their tweet URL design.
00:04:10.519 Initially, accessing the tweets URL required launching the thick client application, but they now serve plain HTML directly.
00:04:16.519 This change was made to accommodate users who were new to the application who hadn't yet loaded the client.
00:04:23.280 Another issue is crawlability, which primarily affects search engines, especially Google.
00:04:29.000 Google struggles to deal with JavaScript heavy applications, which can challenge their indexing and crawling.
00:04:36.880 If you create numerous public pages accessible through frameworks like Backbone or Ember, they might not appear in Google search results.
00:04:43.080 Recently, Google introduced a pseudo-spec to address this, involving hashbang URLs, which most developers found unappealing.
00:04:49.520 It's crucial to be aware of how this affects the crawlability of your thick client application.
00:04:55.160 In theory, these issues could be resolved through various means, like PhantomJS or headless Selenium, but it complicates things.
00:05:00.880 Assuming this problem will resolve easily in the near future would be unwise.
00:05:06.800 That's one reason why GitHub excels, as they keep their application thin and maintain excellent crawlability.
00:05:12.520 GitHub employs surgical, partial Ajax techniques, but every URL is directly accessible.
00:05:19.600 This enables users to find GitHub repositories easily through search engines.
00:05:25.520 While there are numerous cons to thick client development, there are also many significant advantages.
00:05:31.400 First and foremost, RESTful APIs are incredibly powerful.
00:05:39.680 However, many of us may not be fully utilizing them yet.
00:05:46.279 Decoupling server logic from the front-end is a vital benefit.
00:05:51.480 A significant number of you are actually required to implement this decoupling.
00:05:58.880 Raise your hand if you are currently working on software where mobile is the primary interface.
00:06:05.320 That's a considerable portion of the room.
00:06:11.840 It's common to launch products that prioritize mobile interfaces first before the web component.
00:06:18.400 In previous years, this would often involve generating the server-side views traditionally while handling API calls separately.
00:06:25.120 This created needless duplication in logic between the HTML views and the JSON responses.
00:06:32.640 Today, there are better ways to manage this architecture that reduce that duplication.
00:06:39.160 Employing RESTful principles allows you to utilize HTTP efficiently, benefiting both caching and resource allocation.
00:06:45.480 It enables better parallelization of requests, leading to faster page rendering.
00:06:51.680 In Rails, when using server-side rendering, multiple processing requests can lead to longer load times.
00:06:58.480 The initial loading of Active Record objects can significantly contribute to this delay.
00:07:04.880 By distributing tasks into multiple AJAX requests, you can yield faster response times for users.
00:07:11.360 There's also the benefit of separation of concerns.
00:07:17.200 In Rails, we often blend logic for database actions with the response-rendering logic.
00:07:23.400 Separating these concerns allows for cleaner controller code that promotes better maintenance.
00:07:29.360 Implementing RESTful APIs facilitates easier A/B testing without cluttering the server-side code with conditional logic.
00:07:36.720 From a user experience perspective, speed is a critical consideration in development.
00:07:44.880 A responsive design allows users to engage more fully with the application, minimizing distraction.
00:07:53.120 Jacob Nielsen, a notable figure in web usability, states that about one second is the threshold where users perceive the system as responsive.
00:08:01.000 At the ten-second mark, user engagement wanes significantly.
00:08:08.160 It’s essential to keep in mind that we are responsible for optimizing the entire request process.
00:08:16.240 Improving responsiveness has been a long-standing challenge, and recent advancements could signify a more favorable trajectory for client applications.
00:08:22.640 Hosting services and caching technologies have also improved significantly over the years.
00:08:28.720 Content delivery networks (CDNs) help accelerate page loads, leading to a faster user experience.
00:08:35.960 Once you move beyond the initial bootstrap phase in thick client applications, you'll enjoy increased speed and responsiveness.
00:08:43.760 For instance, JSON data transmission is generally faster than returning a pre-rendered HTML.
00:08:51.760 Being able to show previously loaded data without requiring an additional server request is tremendously beneficial.
00:08:58.160 This swift response allows users to interact immediately, enhancing the overall experience.
00:09:03.520 Moreover, concepts like optimistic UI designs add to the perceived performance.
00:09:10.560 This means you can provide instant feedback to an action, which enhances user satisfaction.
00:09:17.120 We are on the verge of a faster, smoother web experience for users.
00:09:24.640 Future-proofing is another reason to explore thick clients More robust technologies can potentially complicate future changes.
00:09:32.400 Should you build an application using Rails today, there may be challenges later if a switch to Django or another platform is required.
00:09:41.520 If you've built a thin client application, transitioning to thick client architecture may also pose difficulties.
00:09:48.240 Making the wrong decision could lead to using outdated frameworks or tools.
00:09:54.840 Starting off with the right technologies is crucial for long-term strategy.
00:10:02.000 Another consideration is recruiting talent.
00:10:08.240 Talent acquisition may become more challenging if your company relies heavily on server-side Ruby.
00:10:16.640 The competition for tech talent is fierce, and some prospective employees may have preferences for thicker client frameworks.
00:10:24.080 When considering your team’s needs for thick client technologies, you need to be accountable regarding your capabilities.
00:10:32.240 Consider whether you can invest in cutting-edge technologies. What is your organization’s current standing?
00:10:40.960 Sometimes it’s acceptable to work in more conservative development environments.
00:10:48.560 However, always be conscious of your organization's capacity to support emerging methodologies.
00:10:56.240 A culture of engineering excellence demands that you have both aptitude and experience, and the ability to pivot.
00:11:04.560 Evaluate whether your organization can tolerate the extra time investment in engineering culture.
00:11:12.160 Many of us have been spoiled by Rails in terms of conventions and software quality.
00:11:20.000 Embracing thick client applications means you may need to develop your team conventions.
00:11:29.600 If your organization supports conventional team structures, it can significantly improve development processes.
00:11:37.320 Now, let’s discuss what this means for your career as a Ruby or Rails developer.
00:11:45.200 This segment may delve into some philosophical reflections, so I’ll share a few quotes.
00:11:54.200 'It is better to be lucky than good,' a sentiment attributed to WWII pilot Lamar Gillet.
00:12:01.920 There is truth in the idea that timing can significantly influence one’s career.
00:12:09.960 Many of us benefited greatly from our involvement in Ruby and Rails during a time of rapid growth.
00:12:17.600 Recognizing how luck intertwines with our personal achievements is essential.
00:12:23.760 Although there’s undeniable technical capability, external factors have played a major role in career advancement.
00:12:31.600 More recently, JavaScript has overtaken Ruby in many development rankings and discussions.
00:12:39.200 However, this doesn’t automatically translate to more opportunities, nor does it diminish the value of Ruby.
00:12:47.680 It’s crucial to recognize that shifts in technology often result in shifts in resource allocation.
00:12:55.040 If you have talented developers, they will adapt to whatever technology stacks emerge.
00:13:02.560 Ruby may lose its prominence, but it will also remain an excellent tool for many applications.
00:13:10.800 It’s not about the end of craftsmanship but rather about adaptation and evolution.
00:13:18.040 Lastly, let's consider prevalent myths around thick clients.
00:13:26.080 Sometimes, the notion arises that with programming languages in the client, we don't need server code.
00:13:32.960 This idea is challenging since, in reality, client code must still communicate with server-side logic.
00:13:39.520 Another falsehood is the belief that having a common language on both client and server justifies forgoing server infrastructure.
00:13:47.440 While it might sound appealing, server-side coding is essential for various reasons, including data protection and security permissions.
00:13:55.520 You cannot leave permissioning logic exposed on the client-side, as that would compromise your application.
00:14:02.080 While it is advantageous to share code, doing so in the same context could introduce complexities.
00:14:10.120 There are advantages to having distinct service-side setups, which provide controlled environmental management.
00:14:18.240 Node.js has proven beneficial for an array of tasks, but for others, using Rails makes more sense.
00:14:26.080 We are still witnessing progress in the management of thick client technologies within Rails.
00:14:33.520 Open-source projects like the Rails API initiative aim to streamline app configuration.
00:14:40.720 As we explore this movement, remember that conversations around Rails will influence our trajectory.
00:14:48.800 As we navigate this evolving landscape, let’s continue to connect and build community bonds.
00:14:59.600 This collaboration will empower our development processes as we adapt together.
00:15:08.160 So, as we venture into thick client development, let's embrace the challenges and opportunities it presents.
00:15:15.520 And let's strive for excellence, together, in whatever paths we choose.