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.
