Talks
The Front-End Future
Summarized using AI
The Front-End Future
by Francis HwangThe video titled 'The Front-End Future,' presented by Francis Hwang at GoRuCo 2012, discusses the implications of thick client web development in contrast to traditional thin client approaches, particularly within the Ruby on Rails community. Hwang emphasizes the growing trend of using JavaScript frameworks like Backbone.js and Ember.js, which shift the view logic to the browser and utilize a JSON-based REST interface for server communication.
Key points discussed include:
- Definitions: Thick clients move rendering logic to the web browser, while thin clients rely on server-side rendering.
- Complexity and Speed: Thick clients add complexity and may require more initial development time, but can yield benefits like faster load times after the initial phase.
- Crawlability: Web applications that heavily use JavaScript can suffer from indexing challenges on search engines like Google, potentially affecting visibility.
- Decoupling: A major advantage of thick clients is the separation of concerns, allowing for a cleaner architecture and better scalability, particularly in mobile-first development.
- Responsiveness: Hwang notes that a primary benefit of thick clients is improved user experience through enhanced responsiveness and faster interactions post-load.
- Future Considerations: Adopting thick client methodologies is framed as a strategic decision that requires an organization's commitment to modern technologies, as well as an understanding of talent acquisition trends.
- Career Implications: The talk highlights that while JavaScript’s popularity is rising, Ruby still holds value, and developers should focus on adaptability across technologies.
- Common Myths: Hwang dispels misconceptions about thick clients, clarifying that client-side code still relies on server-side logic for security and data management.
Hwang concludes by encouraging engineers to foster community discussions and adapt to the evolving landscape of front-end development, emphasizing the importance of addressing the challenges while harnessing the opportunities that thick client frameworks present. The takeaways underscore the necessity of thoughtful strategic planning in choosing between thick and thin client development, along with considering organizational capacities for emergent technologies.
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.
Explore all talks recorded at GoRuCo 2012
