Talks
Panel: Single Page Applications Frameworks
#angular-js
#client-side-rendering
#frontend
#javascript
#single-page-applications-spa
#software-architecture
#user-experience-ux
Panel: Single Page Applications Frameworks
by Piotr Sarnacki, Andrzej Krzywda, Patrick Mulder, and Adam PohoreckiThe panel discussion titled 'Single Page Applications Frameworks' featured speakers Piotr Sarnacki, Andrzej Krzywda, Patrick Mulder, and Adam Pohorecki at the wroc_love.rb 2013 event. The conversation mainly revolved around the increasing prevalence of single-page applications (SPAs) in web development and their impact on user experience and application architecture. The speakers emphasized the following key points:
Introduction of Speakers: Each speaker briefly introduced themselves, with insights into their professional background in JavaScript and web development.
Single Page Applications: The panel discussed whether SPAs dominate modern web development. They concluded that SPAs are beneficial in situations requiring significant interactivity, but for mostly static content, traditional web pages remain viable.
User Experience: The discussion highlighted that SPAs typically offer better user experiences, often resulting in higher satisfaction among users compared to multi-page applications.
Technology and Tools: With advancements in browser capabilities, the necessary tools to support SPAs are now available, making the transition from static to dynamic content more feasible. However, discussions acknowledged challenges in the integration between client-side and server-side programming.
Security Considerations: The importance of evaluating data security at both runtime and on the server was addressed, noting that a mistake could lead to significant setbacks in application development.
Differing Frameworks: The panel shared insights on various JavaScript frameworks, including Angular, Backbone, and Ember, comparing their architectures and features like bi-directional data binding, which simplifies synchronizing the frontend with the backend.
SEO Challenges: There were discussions regarding the SEO constraints of SPAs, emphasizing the need for server-side rendering solutions to enhance visibility in search engines, countering the myth that SPAs are not indexable.
Framework Selection: The conversation touched on how to select an appropriate framework for project needs, outlining the unique benefits and drawbacks of popular options like Angular and Ember for managing larger applications.
Community and Resources: The panelists encouraged audience participation and contribution to the frameworks discussed, highlighting community resources like documentation, GitHub, and online forums where developers can seek help and contribute to ongoing developments.
In conclusion, the panel agreed that SPAs are essential tools for modern web applications, offering numerous advantages in user engagement and experience. However, careful consideration of when and how to implement SPAs is crucial, as well as ongoing support and resource sharing within the developer community.
00:00:29
I'd like you guys to introduce yourselves, maybe very quickly.
00:00:35
Okay, yes. That would be awesome. It's good to meet the others.
00:00:41
Frameworks hands down are fantastic, so there's really no need for this discussion.
00:01:15
So, I'll be the technology representative today. Oh, um, Patrick.
00:01:22
I got involved with JavaScript a few months ago and I've made quite good progress with it since then. I did a lot, so I thought it's a good time to be here.
00:01:30
Okay, okay.
00:01:39
In recent years, we've seen a movement on the web where many applications are developed by placing most of the logic on the client side.
00:01:46
I'm not sure if this trend is going to dominate the internet or if it's just about single-page applications.
00:01:52
Are single-page applications dominating the web now? Can anything be a single-page application? That was a question for all of you.
00:02:10
From my experience, I think single-page applications are needed only for specific parts of some applications. It's not necessary everywhere.
00:02:27
It primarily depends on interactivity.
00:02:34
If you have applications that need to be interactive and can handle changes without reloading the entire page, you should probably go for a single-page app. However, if you have mostly static pages that need to be indexed by Google and don't require much interactivity, you'll likely be fine with regular static pages.
00:02:46
So, it really depends on the use case. I wouldn't say that single-page applications will dominate or not dominate the internet because there will always be places for static pages.
00:03:08
The user experience is generally much better with single-page applications. The architecture also benefits developers, and usually, customers are happier with single-page applications.
00:03:21
So, I don't see any reason to avoid single-page applications. In my Ruby program, the historical reasons for not using them were due to browsers being unable to run those applications before. Now, I think they can handle it.
00:03:32
We already have the necessary tools and browsers that can support single-page applications and rich client-side applications. However, we are still missing the connection between the server-side and client-side.
00:03:56
There's still a shortage of programming languages that can efficiently work on both the client and the server. You can use JavaScript with Node.js, but its event-driven programming model is not suitable for everyone. It's not as easy as the traditional programming methods we are familiar with, like Ruby.
00:04:19
As much as I enjoy writing single-page apps, I believe we still need to consider the entire user experience.
00:04:31
While obviously a backend is still required, it's often better to treat front-end and back-end as two separate applications. Typically, you should start with your front end and then adjust the marketplace based on your needs.
00:04:50
Nevertheless, there is still the question of security. It's crucial to evaluate your data both at runtime and on the server.
00:05:03
If you make one mistake, you'll have to go back and rework your steps.
00:05:09
I think from one standpoint, it seems like we're creating a jQuery library that we see in almost every application today. It's likely that many applications will improve if we add a touch of backend.
00:05:30
I think it's also useful to consider not just single-page applications, even if you don't currently use them for your use cases.
00:05:43
For example, I’d like to ask Andre: would you create something like Wikipedia or any other content-centered site that primarily displays static content and has very minimal interactivity, like simple editing, as a single-page app? Why or why not?
00:06:09
Yes, that's a tricky question. If I had to clone the existing user interface for Wikipedia, which I don't think is excellent, I probably wouldn't consider a single-page application as a good fit.
00:06:26
However, there's much we could do to improve the Wikipedia interface before turning it into a single-page application.
00:06:39
Indexing by search engines is indeed very important, and this is another area where tools are currently lacking.
00:06:56
There's a common myth that single-page applications are not indexable. Google has official documentation on how to make your website deployable, which really boils down to doing some work on the server.
00:07:15
Essentially, it involves rendering relatively simple HTML. You don't have to deal with JavaScript and CSS.
00:07:29
While it may seem like additional work, it's not as complicated as some may believe compared to not using single-page applications.
00:07:47
As for SEO, I have heard discussions in the JavaScript community about phantom.js that allow you to render the entire application for SEO.
00:07:58
The drawback with traditional Rails applications is that you don’t need to do that, but with single-pages, you will have to.
00:08:09
I implemented something similar for my purpose, and it took a few hours, but I know there may be some corner cases and caching issues that I might not be aware of.
00:08:26
All of this just indicates that single-page applications usually require more work than traditional ones.
00:08:47
Let's switch topics: the next topic is key features of your approaches and their importance. Who wants to start?
00:09:03
I'll take a shot! I’d be surprised if you all haven't heard of it.
00:09:10
It has been in production in my team for over a year, for about 40 front-end applications. It's not really a framework.
00:09:20
There isn't anything you can download and use. It's more of a set of guidelines, an architectural style. Imagine if you were to combine recommendations from Rails and add things from Dragonfly.
00:09:38
So, we're doing programming the library modeling, and also applying a simple architecture approach to write code on any platform. That said,
00:09:51
I can't compete directly with established frameworks because they are available for download.
00:09:59
However, if you visit the website, you can download an example application. We have plenty of examples, and we are committed to adding more.
00:10:07
So, it is more of a set of guidelines at this stage.
00:10:23
I thought it would be good to hear about Angular.
00:10:30
If you haven't heard about it before, it is a framework designed to ease the management of applications.
00:10:38
We aim for it to manage all the housekeeping so you can focus on writing less code.
00:10:50
I appreciate that, but when you opt for a lighter approach like Backbone or Hexagonal, you'll find yourself writing a lot of code just to manage views.
00:11:03
Especially for nested views; managing events and bindings can become complex as your application scales.
00:11:15
If the framework you pick doesn't handle this for you, you'll have to do it yourself.
00:11:32
Many frameworks may appear minimalistic, but someone still has to write that code.
00:11:38
Thus, when frameworks are small, their maintainers may not have the capacity to optimize anything.
00:11:50
Likewise, if you run into specific issues or bugs in your application, you will need to solve them yourself.
00:12:02
That's why I focus on doing as much as I can to manage the application, allowing you to write the smallest amount of code possible.
00:12:14
Speaking from experience, the main argument here in terms of size and minimization is that we don't want to introduce too many dependencies into our code.
00:12:30
You can gradually build up your models and views. If you need a controller, you can add it as needed.
00:12:41
This may help minimize bugs, but only time will tell the full impact. It's interesting to note that version 0.5 became popular not long ago.
00:12:56
Now we are seeing version 0.9, but changes haven't been significant.
00:13:08
In comparison, moving between major versions in larger frameworks like Rails can be a headache.
00:13:23
I think Backbone provides a smaller framework, so it might not break as drastically as larger ones when moving versions.
00:13:37
So, you can adapt everything upon release.
00:13:47
Among us, we represent several different approaches.
00:13:56
I think two key features are bi-directional data binding, which should be a primary consideration when choosing a JavaScript framework.
00:14:04
It is a significant feature that alleviates much of the complexity in synchronizing HTML with your JavaScript.
00:14:15
Indeed, right in the middle of every single-page JavaScript application, there's a wall between HTML and JavaScript.
00:14:29
A framework that can bridge that gap by managing how changes to HTML are reflected in JavaScript is crucial.
00:14:44
Moreover, there's another significant distinction: while frameworks like Ember implement their own object model,
00:14:56
and force you to use methods like get and set instead of direct property access, frameworks such as Hexagonal or Angular allow you to write pure JavaScript.
00:15:08
This means your code can be purely JavaScript; you only tie into the library when you need specific features.
00:15:21
It's incredibly easy to test, and your application can function independently from Angular.
00:15:39
For instance, you could conceivably use AngularJS with existing technologies, it allows flexibility.
00:15:55
I’d highlight that Angular as a framework facilitates the development of larger applications efficiently.
00:16:04
It has the support of Google and is more mature than Ember, which changes quite frequently.
00:16:19
I highly encourage everyone to give it a try.
00:16:31
I should cover the topic of data binding sharing my two cents.
00:16:50
In most cases, it's not as crucial as one might think.
00:17:02
In fact, I worked on various applications where manual control over changes was not overly challenging.
00:17:12
If done right, that control can be as clear as other frameworks with data binding.
00:17:21
Hexagonal indeed does not have data binding built-in; for it, the applications are less about data changes and more about actions.
00:17:35
In my opinion, both Angular and Ember are strong contenders for constructing larger applications.
00:17:46
On the flip side, I think managing views and other parts of the application without relying on data bindings can be overly complicated.
00:18:11
Especially with multiple nested views, you risk ending up with unclean code.
00:18:21
It's common to find many queries on Google regarding zombie views related to memory management.
00:18:30
Another point to discuss is the complexities associated with Angular's DOM compiler.
00:18:42
You need a solid understanding of how it manages DOM elements to effectively extend the framework.
00:18:55
Being aware of its intricacies can be quite overwhelming.
00:19:06
I'm on the opinion that Angular simplifies the process of building applications, but you'll need a good grip on its inner workings.
00:19:22
One downside to Angular’s approach to data binding is its use of a dirty checking mechanism.
00:19:34
When an object changes, Angular doesn't immediately track changes but checks if the property was altered.
00:19:48
This approach can limit binding to a predefined threshold, and managing larger datasets becomes cumbersome.
00:19:58
In projects where we had to load large tables with numerous dynamic elements and custom validation, we faced considerable challenges.
00:20:07
If an application has four or five levels of nested views, controlling them manually is far from trivial.
00:20:31
It's possible to end up with performance issues with too many bound properties.
00:20:44
However, it's essential to structure your application properly.
00:20:56
Rendering only what needs to be visible and offloading data instead of binding may mitigate these challenges.
00:21:05
I definitely recognize that directive usage can elevate efficiency.
00:21:11
With directives, you may seek out smaller reusable code that solves specific issues.
00:21:30
Historically, using them could differentiate standard components in your views.
00:21:47
Let’s switch to another topic. In our last conversation, there was discussion about pure JavaScript.
00:21:56
You don’t have to be confined by framework rules in your architectural mindset.
00:22:06
Most aspects in Angular are optional; if you don’t want to use its built-in utilities, you can avoid them.
00:22:17
If you don't utilize the HTML compiler, you might not realize the full advantages of data binding.
00:22:30
As we observe the vocabulary variants among frameworks, it's clear that terms like 'controller' may carry different meanings in different contexts.
00:22:50
This inconsistency is common due to the developmental stages of many frameworks.
00:23:00
None are fully matured yet. We are not at the stage of Rails.
00:23:12
Each of us is focused on our respective mindsets for architecture.
00:23:21
It's totally viable to use different frameworks step by step, but they tend to differ.
00:23:30
In regards to Backbone, my experience combining it with Rails was not seamless.
00:23:44
Back when I started, the asset pipeline needed compiling CoffeeScript, adding complexity right from the start.
00:23:58
Now, I prefer working purely with JavaScript and have been using Sinatra just for the API.
00:24:14
I believe it's essential to stay focused on JavaScript.
00:24:28
Ember has its own class model, requiring you to use pattern calls to set or get data, which I find restrictive.
00:24:42
This can make it cumbersome to optimize and detach things without interfering with the application code.
00:24:54
As I noted, the average user experience differs based on what users are looking for.
00:25:07
In the JavaScript ecosystem, the conversations are often about managing alternate approaches.
00:25:21
It’s beneficial to consider different frameworks based on your project requirements.
00:25:31
For those keen on framework involvement and learning how to contribute,
00:25:43
Angular has excellent documentation and a supportive community to help developers navigate its ecosystem.
00:25:54
If anyone wants to contribute to Angular, GitHub is the core platform to engage with.
00:26:06
There's an active mailing list, and any queries will get a quick response.
00:26:17
So yes, we just started; it's been in production for a year, and we've started gaining recognition.
00:26:30
Our website is relatively new, and we have documentation and examples that are a work in progress.
00:26:46
We have a strong team behind it, even though it may not have the full framework capabilities, we are on the right path.
00:27:04
Any engagement from interested parties would be appreciated.
00:27:18
As for involvement, you can explore their website for directions, and they often have communication platforms.
00:27:31
Connecting via platforms like IRC may yield the quickest response.
00:27:46
Also, feel free to reach out on Twitter.
00:27:58
As for the conference,
00:28:16
there are many active JavaScript developers eager to help newcomers.
00:28:29
Ruby programmers can assist as well.
00:28:34
Thank you very much for your attention.
