fbpx

Conheça Svelte, o framework “compilador”

VueJS, Angular e React são nomes populares quando o assunto é framework para desenvolvimento de web apps. Eles popularizaram o conceito de DOM virtual, assim não é necessário atualizar o DOM diretamente. Há uma sincronização entre o dom virtual e real. A vantagem disso é que sua página só seria atualizada no momento que fosse realmente necessário. O processo de sincronização é chamado de reconciliação. Basicamente esse processo existe para facilitar o controle de estado da sua aplicação. Você especifica o state para o framework e ele vai garantir que o DOM real esteja nesse estado. Quando utilizamos essa abordagem precisamos de runtime, ou seja, quando você faz o build da sua aplicação uma porção de código do framework fica responsável por rodá-la.

Svelte

Svelte é um framework novo que não possui runtime, ou seja, ele funciona mais como um compilador do que um framework. Ele pega o seu código e compila para funcionar com a API nativa do browser. Nenhum código além da sua aplicação será rodado. Isso implica em outra característica do Svelte: o fato de não utilizar o virtual DOM. Segundo os próprios criadores do Svelte o virtual DOM é puramente uma sobrecarga. Isso acontece porque há um preço em se comparar o Virtual DOM com o real. O Virtual DOM não existe para tornar sua aplicação mais rápida, ele existe puramente, como já supracitado, para facilitar o controle de estado da aplicação.

De fato, o framework prova cumprir o seu papel. Em testes publicados no FreeCodeCamp pode-se observar que o tamanho final do build fica substancialmente menor que outros frameworks (imagem 1).

Ainda assim, em termos de performance ele tem se mostrado com desempenho comparável aos concorrentes. Algo que sempre fica como uma questão é se os testes iniciais de benchmark se manterão em projetos mais complexos. Essa questão acaba deixando o desenvolvedor em dúvida se vale a pena lançar mão de uma nova tecnologia pelo que ela promete e não se apoiar no antigo que já está consolidado no mercado.

Neste artigo o Svelte será introduzido brevemente, com o intuito de se ter uma visão geral do framework e sirva como um direcionador para a construção de um projeto. No final apresentarei o tradicional projeto de jogo da velha para demonstrar seus recursos.

O Jogo da Velha

Vamos desenvolver um pequeno jogo da velha. Vocês verão que escrever componentes em Svelte é basicamente escrever HTML, Css e JavaScript. Existe uma sintaxe específica do framework, mas ela é de fácil aprendizagem, simples e intuitiva.

A primeira parte do código é a definição de variáveis necessárias. Guardamos o vencedor como O ou X em winner e o jogador em turn. O board é guardado em uma variável dinâmica do Svelte, por isso o label “$”. Variáveis dinâmicas são assim definidas porque a alteração dessas implica na renderização do componente. É particularmente útil redesenhar tudo no momento de mudança do board em um jogo da velha, assim mantemos o que está desenhado sincronizado com a lógica. Podemos pensar como um watch para aqueles que vem do Vue.

A seguir temos duas funções, uma para jogar, que armazena o jogador na posição que estiver vazia e checa se houve alteração do vencedor. O operador de assimilação “=” é muito importante no Svelte, pois é como ele sabe que algo mudou e precisamos renderizar novamente.

A seguir temos a versão que verifica se as posições que indicam a vitória foram preenchidas e retorna os jogadores que ocupa essa posição e é, portanto, o vencedor.

A lógica do jogo é basicamente essa, o resto é o desenho do board em puro html e CSS para estilização.

Era possível utilizar mais recursos do Svelte, mas eu preferi não fazê-lo para mostrar que com JavaScript, HTML e CSS podemos construir nossos componentes. Há renderização condicional, tratamento para renderização de promisses de forma especial e muitos aspectos interessantes do framework.

O código completo está disponível no meu github.

Conclusão

Svelte é um framework novo que foge ao conceito de virtual DOM e runtime. Funciona mais como um compilador que “converte” os componentes feitos de forma declarativa para a API imperativa do browser. Os compila para um JavaScript otimizado e eficiente.

Referências

https://svelte.dev/

https://svelte.dev/blog/virtual-dom-is-pure-overhead

https://github.com/rbentivenha/svelte-jogo-da-velha.git

https://pt-br.reactjs.org/docs/faq-internals.html

Understanding Node.js and their modules

History

Node.js was created in 2009 by Ryan Dahl, inspired by Flickr’s file upload progress bar, where he realized that the browser didn’t know how much of the file was uploaded and had to consult a web server to get this information.

Node.js is a JavaScript Server-side and open-source execution environment, using a combination of Google V8, Event loop and Single thread, asynchronous API, and non-blocking I / O, the project was first presented at the European JSConf.

Google V8

V8 is an engine created by Google, open source and written in C ++, it is used in Google Chrome and also by the Node.js runtime and was designed to improve the performance of JavaScript execution in web browsers.

JavaScript is an interpreted language, so it has a lower performance than a compiled language, V8 was created thinking about this language problem, instead of using an interpreter, it compiles the JavaScript code for machine code, executes, handles memory allocation and does garbage collector work.

Single thread

Node.js came with a single thread proposal, where only one thread takes care of requests and each one is treated as an event. Unlike other languages such as PHP, Java, and Ruby, which are multi-thread, where every request received is created a new thread, which often ends up consuming computer resources unnecessarily.

This model may seem strange at first because we always hear that having something multi-thread has better performance. But even though Node.js is a single thread, we are able to handle requests concurrently. Using non-blocking I/O calls and asynchronous API, considered a strong feature within Node.js, not blocking the execution of resources facilitates parallel execution and makes better use of computational resources.

Event Loop

The key that makes Node.js so efficient is the Event Loop concept, with great responsibility it is basically an infinite loop that at each iteration checks if we have events to be executed in the Task Queue.

In Task Queue he takes the event and sends it to be executed in the Call Stack. Its performance is due to the way it is executed, in a non-blocking way.

Call Stack 

In Computer Science, a stack is a data structure that allows the removal of elements and insertion of new objects. It works using the LIFO (Last in First Out) concept. Its basic operations are push and pop, a stack must keep its maximum size in a variable, and when that size is exceeded we have one of the famous errors in the programming, stack overflow.

Heap

It is the memory available to the Node.js process, whenever we call a “new Object” or create a variable to store a value, it is the responsibility of the Heap to store the values.

Task Queue

It can be considered as a queue of messages to be processed when we have calls such as setTimeout, access to network modules, I / O, among others.

The Event loop checks if it is a task that will require heavier processing if it does, it sends these executions to libuv, which executes them in a separate thread pool, allowing V8 to continue executing the code on the main thread.

However, if it is a lighter process it sends to be processed in the call stack.

Um exemplo de função que tem um processamento mais pesado é o readFile do módulo fs do Node.js, a libuv administra essa função em outra thread, quando ela terminar de ser

An example of a function that has heavier processing is the readFile of the fs module.

Libuv manages this function in another thread. When it finishes executing the callback will be added to the Task Queue to be executed in the call stack as soon as it is available.

The responsible for analyzing if my call stack is empty and if there are tasks in the Task Queue to be processed in the Call Stack is the Event Loop.

He is responsible for calling the next tasks while Node.js is running.

Macro e Micro Tasks

Up to this point, we understand how Call Stack works and how our functions are organized within the Task Queue.

But within the Task Queue, we have two types of tasks:

  • Micro tasks: such as promises and process.nextTick;
  • Macro tasks: where we have well-known examples in day-to-day development, such as setTimeout, setInterval.
Check out this video to better understand (PT-BR)

In this article I tried to explain in a basic way the functioning of the modules of the Node.js virtual machine, I will write more content about Node in the future.