DEV Community: Nina Kitsu

Runtimes JavaScript [pt-br]

Nina Kitsu — Tue, 17 Jan 2023 15:11:00 +0000

Para desenvolver e/ou rodar uma aplicação local JavaScript você precisa instalar um Runtime localmente.

Mas o que é um runtime?

A palavra em si pode significar muitas coisas na área da computação. Porém um significado em específico será utilizado aqui, que é o de ambiente de runtime.

Este ambiente de runtime é a base, a interface que lida entre seu programa e a máquina, que pode ser local, virtual, na nuvem...

Um famoso runtime é o Ambiente de Runtime do Java, do inglês Java Runtime Environment, também conhecido por sua sigla JRE. Simplificando, este é responsável por rodar uma aplicação Java na Máquina Virtual do Java.

Então pro JavaScript teria algo como um ambiente de Runtime JavaScript, certo? SIM! Mas sendo este artigo sobre ferramentas, listarei apenas as que rodam direto numa máquina e não num navegador.

Infelizmente nenhuma ferramenta tem um nome sugestivo sendo sigla do que ele faz. Mesmo porquê teria as mesmas iniciais da Runtime do Java. Mas os desenvolvedores das runtimes foram até que criativos.

Node.js

Este é o mais famoso runtime JavaScript e um dos primeiros a existir fora do navegador.

Ele foi desenvolvido em cima do interpretador V8, criado pelo Google, o mesmo interpretador de código JavaScript embutido nos motores de renderização Blink, presente em navegadores Chrome e outros navegadores baseados na versão de código aberto Chromium.

Confuso né?

Diagrama comparando o navegador com o Node.js

Assim tornou-se possível rodar aplicações escritas em JavaScript fora do navegador. E aplicações de diversas naturezas. Aqui abordo ferramentas, porém devido ao seu suporte para diversos sistemas operacionais, o Node também pode ser usado para criar aplicações web para servidores e até mesmo ser utilizado em controle de dispositivos IoT.

Infelizmente este artigo não é focado em desenvolvimento utilizando Node.js. Existem diversos artigos e cursos espalhados pela Internet. Irei focar nos executáveis em si.

Existem outros runtimes para ambientes JavaScript?

Sim, e citarei duas que estão dominando as discussões ultimamente (no momento de escrita deste artigo).

Deno

DENO LOGO

Desenvolvido pelo mesmo criador do Node.js, Ryan Dahl. Escrito em Rust e também tendo como base o motor JavaScript V8.

A motivação da criação desta nova runtime foram alguns arrependimentos do criador em relação a decisões tomadas quando o Node foi criado. O Deno foi anunciado em 2018, quase 10 anos após o lançamento do Node.

Abaixo o vídeo, em inglês somente, da talk do Ryan Dahl com o título de "10 Coisas que me arrependo sobre o Node.js".

Dentre estas melhorias:

Rodar TypeScript e usar ES6 por padrão;
Não requer um gerenciador de pacote, a resolução de módulos é feita por URLs;
Melhor controle de permissões...

Em 2020 foi lançada sua primeira versão estável.

Bun

BUN LOGO

Já o Bun, criado em 2021 pelo Jarred Sumner, tenta ir por outro caminho diferente do Node/Deno.

Ao invés de ter como base o V8, o Bun utiliza como base de seu interpretador o Webkit, presente no navegador Safari. E foi programado em Zig, outra linguagem de programação low-code voltada a performance, como o Rust.

Suporta TypeScript e JSX por padrão e possui um instalador eficiente compatível com npm.

Porém como toda novidade, este runtime ainda está em fase experimental, sem lançamento de uma versão estável.

Diferenciais

Uma premissa de ambos desde sua concepção foi serem criados com suporte ao TypeScript. Muito do que a linguagem evolui sobre padrões EcmaScript da TC39 é também atrelado a este suporte ao TS, já que o próprio TypeScript acaba adotando como padrão as evoluções das propostas da ES. Logo também é padrão a utilização de ESModules.

O Bun está em estágio experimental e é o caçula dos runtimes. Podem ter funcionalidades, bibliotecas e ferramentais que ainda não possuam suporte.

Um diferencial que considero legal de se citar do Deno é que desde sua criação teve-se uma preocupação maior sobre permissões. Ou seja, ao rodar uma aplicação feita em Deno, é preciso prover explicitamente permissões ao rodar a aplicação. Pode até ser algo que parece irritante durante o desenvolvimento esquecer de dar alguma permissão, porém evita que alguma dependência execute certos scripts, maliciosos ou não.

Conclusão

Como tanto o Deno quanto o Bun são runtimes um tanto recentes e não cheguei a estudar profundamente.

Se deseja testá-los, é possível instalá-los utilizando o asdf. Ambos possuem plugins já criados:

História sobre usar o JavaScript para programar JavaScript

Nina Kitsu — Mon, 31 Oct 2022 23:23:53 +0000

Olá pessoa desenvolvedora. Depois de muito tempo resolvi tentar voltar a escrever artigos. A de hoje não tem nada de programação, é muito mais historinha. Espero que gostem. :)

Não sou historiadora e os fatos não estão descritos necessariamente numa ordem cronológica certa tão pouco científicos. Esse texto tem tanta credibilidade quanto uma página da Wikipédia no início do milênio, ou seja, nenhuma. Não a usem como base histórica.

Motivação

Quem no começo da carreira não se preocupava com quantos espaços identava seu código, se usava tab, se botava ou não chaves se o if tinha apenas uma linha...?

E claro que com isso empresas e pessoas desenvolvedoras começaram a se preocupar com a forma que iriam programar. Criaram diretrizes, chamadas de Guias de Estilo, ou em inglês Style Guides, para todos escreverem um programa de forma única parecendo como se fosse programado por apenas uma pessoa.

Por outro lado, pessoas desenvolvedoras também se preocupavam se seu programa funcionava de forma correta. Testavam manualmente e viam se o comportamento do teste condizia com o que foi planejado.

Não só isso. Com o passar do tempo vieram outras preocupações como qualidade de código, se existe muitos códigos duplicados, se o programa roda regularmente em qualquer ambiente que for suportado.

Imagine pessoas lidando com tudo isso, lendo e corrigindo códigos, apontando erros, verificando se a aplicação não quebraria, testando em diversos ambientes... Um tanto inviável, certo?

Criou-se então uma necessidade de se automatizar tarefas "triviais" (no sentido que possam ser reproduzidos) de forma não humana pois usando um programa para avaliar outro programa seria muito mais rápido que uma pessoa avaliando o código fonte ou funcionalidade de outro programa em específico.

Hoje em dia, quem processa contas complexas mais rápido? Uma pessoa mediana/padrão ou um computador já configurado para fazer contas?

Então por que não atribuir tarefas corriqueiras pra máquinas para as pessoas programadoras se preocuparem muito mais em criar programas que ficar pensando qual a melhor maneira para programar?

E o JavaScript?

Os navegadores sempre foram bons programas em acessar um servidor, pegar uma informação em texto e imprimir pro usuário.

Este protocolo de mensageria entre navegador e um servidor é a própria HTTP. Do inglês Hypertext Transfer Protocol, literalmente traduzido como Protocolo de Transferência de Hipertexto.

Mas somente imprimir um texto na tela é chato, não? Imagine não poder nem botar uma corzinha, uma imagenzinha... E com este pensamento os navegadores evoluíram e agregaram mais funcionalidades.

Em 1995 foi atribuida uma tarefa para um funcionário da Netscape chamado Brendan Eich: desenvolver uma linguagem que seria embutida nos navegadores da Netscape. Inicialmente chamada de LiveScript, mas pouco tempo depois renomeada para JavaScript para aproveitar a popularidade de outra linguagem de programação: o Java.

Apesar de ser uma das primeiras linguagens da Web a possibilitar adicionar interatividade às páginas estáticas, o JavaScript nem sempre foi fácil de programar. Linguagem que apesar do nome, não se parecia em nada com o Java.

Mesmo assim a web evoluía e novas formas de interatividade foram criadas.

Applets em Java... Animações em Flash...

E o JavaScript além de possuir limitações, cada navegador podia adicionar alguma funcionalidade no JavaScript da forma que bem entendesse e quando entendesse.

Mas da mesma forma que vieram e tiveram seu hype, também tiveram sua decadência. Applets Java utilizavam a JVM, Java Virtual Machine, ou em português: Máquina Virtual do Java, trazendo um problema de segurança. Sendo o mesmo interpretador que estava na máquina do usuário, uma pessoa desenvolvedora poderia maliciosamente criar um programa com outra finalidade e ter acesso ao computador do visitante.

Já sobre o outro, havia uma frase famosa que todos repetiam na época:

O Flash foi morto pelo Steve Jobs

Quando a Apple criou o iPhone, contendo um navegador dentro dele, foi-lhe arrancada qualquer método de rodar Flash. Animações e aplicações em Flash rodavam perfeitamente no computador, porém num computador de bolso poderia exigir mais da máquina e comprometer o tempo de bateria do dispositivo.

Também haviam outros fatores como a Apple ter que lidar com um produto de uma companhia externa que talvez exigisse algum retorno por ceder uso de uma tecnologia proprietária.

Ferramentas para códigos escritos em JavaScript

Uma das primeiras ferramentas criadas com o intuito de modificar um código JavaScript foi devido a preocupação de enviar um código muito grande pra quem navegasse a página que carregaria este script.

Ninguém escreve código todo em uma linha, certo? Digo, pessoas programadoras normais. Ficaria ilegível.

Mas e se uma ferramenta tirasse os espaços e quebras de linha e o meu arquivo JavaScript tivesse um tamanho menor?

Assim foi criado o minificador de código. E qual o ganho? O usuário do site iria ficar esperando menos tempo para baixar script embutido na página.

Esta mesma pessoa que criou o minificador também tinha umas opiniões fortes sobre como um desenvolvedor deveria escrever seu código.

Logo em seguida o mesmo criou uma ferramenta que apontava más práticas de escrita de código JavaScript e também procurava erros triviais como estrutura do código, se uma instrução foi escrita sem erro... Coisa que já existia em outras linguagens. Este analizador de código estático foi chamado de JSLint.

A pessoa que criou ambos se chama Douglas Crockford. Não sei se foi realmente as primeiras ferramentas criadas para códigos escritos JavaScript, porém foram uma das primeiras ferramentas mais populares.

Este também foi responsável por popularizar o formato de documentos JSON.

Leia mais sobre o JSMin, em inglês

Porém mesmo sendo umas das primeiras ferramentas para modificar códigos JavaScript, a primeira rodava em linha de comando e foi escrito em C. A segunda só rodava no navegador.

Google quem?

Uma empresa que já estava bem consolidada no mercado de buscas se intromete e decide também ditar regras de como uma pessoa desenvolvedora de tecnologias web deveria escrever seus sites de forma performática, já que era assim que eles faziam.

Sim, essa empresa era..... o Yahoo!.

Uma das primeiras ferramentas online sobre performance (pelo menos que eu tenho ciência) foram feitas por eles. Leia mais no site do YSlow, em inglês..

Algo que era hype nessa época eram os Provedores de Serviços. Sites que agregavam de tudo. Nelas qualquer pessoa podia fazer sua página, ter sua conta de email, ver notícias, enviar mensagens, jogar joguinhos em Flash... TER SEU BLOG!!!

Outra coisa que era hype na época eram ~~discadores personalizados~~ barras pro Internet Explorer personalizados. Toda empresa provedora de serviços tinha um navegador onde o usuário só clicasse e a primeira página que abria era a da própria provedora.

E com isso o visitante nem precisaria digitar dáblio dáblio dáblio ponto......

E mesmo o Yahoo! sendo um dos portais mais famosos e acessados da Internet na época e sempre pensando em performance, uma empresa rival no setor de buscas começou a ter visibilidade e abocanhar seu market share quando ofereceu uma conta de email onde a capacidade da sua caixa de entrada seria de um giga. Nenhuma outra empresa oferecia tanto espaço para guardar emails. Algumas davam 1mb, 4mb de armazenamento e a pessoa tinha que apagar os emails pra ter espaço para receber mais e-mails.

Mas esta empresa não contente com o navegador da Microsoft, resolveram ao invés de só criar uma barra personalizada, lançaram um novo navegador: o Google Chrome.

Que quase levou o nome de GBrowser, analogamente ao GMail.

Ok, não foi bem assim...

Não foi só pra ter um navegador próprio que a Google criou o Chrome. Foram contratades pessoas desenvolvedoras que participaram do desenvolvimento do Internet Explorer e de ferramentas da Mozilla para a concepção deste produto.

O Firefox também já existia na época. Mesmo assim o Internet Explorer dominava o market share dentre os navegadores (claro que por ser um navegador que vinha junto do Windows por padrão).

Mas a motivação para a criação de um novo navegador pela Google foi a de ter uma experiência para seus usuários do Gmail, Blogger e YouTube muito mais parecida com um aplicativo Desktop que simples páginas web.

Caso queira saber mais sobre a criação do Google Chrome, veja este artigo, em inglês.

Tá, e pra que toda essa historinha longa?

Este novo navegador criado pelo Google, inicialmente utilizava Webkit, criado pela Apple e já sendo código aberto (open source) desde 2005.

Porém por problemas de compatibilidade, a Google decidiu criar seu próprio motor interpretador de JavaScript, o V8.

Toda essa volta pra falar que uma pessoa pegou esse motor do navegador e decidiu tirar ele de lá e rodar localmente na máquina.

Assim surgiu o Node.js. E nome deste programador é Ryan Dahl.

~~E assim começaram os pesadelos e os full stacks unicórnios~~

Isso possibilitou que as pessoas programadoras pudessem usar o mesmo JavaScript que existia no navegador para criar programas que rodavam não no navegador, mas sim na máquina.

E assim aqui eu costuro com o começo da história:

O Node tornou possível que pessoas desenvolvedoras na linguagem JavaScript pudessem usar o JavaScript para criar programas que automatizassem tarefas triviais como análise estática de código, validadores de sintaxe, executáveis de testes unitários com emuladores de API do navegador etc...

E então o npm fomentado pelo Open Source explodiu de aplicações que faziam de tudo, pois muito dev já programava em JavaScript para web.

Uma delas é o CoffeeScript, uma das primeiras linguagens a compilar para JavaScript. Também foi precursor para que voltassem as discussões do Ecma262 e a TC39, que são comitês de padrões ligados ao JavaScript voltadas às evoluções da linguagem. Inclusive, com o CoffeeScript já era possível utilizar arrow functions.

Hoje existem diversas outras linguagens que compilam para o JavaScript: TypeScript, ClojureScript, Elm, ReasonML, dentre outras.

Atualmente também existem ferramentas que mesmo rodando a partir do Node, parte foi programada em outra linguagem, muitas vezes low-code como C, C++ e ultimamente Rust e Go para serem mais performáticas.

Olá pessoas, sou a Nina Kitsu.

Decidi contar uma historinha, como diriam, "baseadas em fatos reais", de como foi a minha percepção de fatos sobre tempo enquanto profissional da área focando no surgimento de aplicações feitas com JavaScript fora do navegador, nas máquinas locais.

Hoje aplicações JavaScript são usadas diariamente no frontend, no backend e até no seu computador.

E com esta historinha abro uma série onde falo um pouco de ferramentas para ambientes JavaScript e configuração de repositórios.

Fontes

Refatoração de código React

Nina Kitsu — Thu, 06 Feb 2020 17:51:31 +0000

Trago neste artigo alguns aprendizados acumulados durante minha carreira. É importante lembrar que apesar dos exemplos serem um pouco generalizados são voltados para utilização dentro de aplicações que utilizem componentes em React e que por isso supõe-se que u leitore tenha algum conhecimento sobre a biblioteca e também sobre ECMAScript.

Também adiciono que podem ter pontos tanto básicos da linguagem quanto algo avançado.

E meu português para artigos continua coloquial e com alguns erros de sintaxe que possam gerar confusão.

Esse é um assunto recorrente para toda pessoa programadora e em qualquer outra linguagem e em qualquer era da computação.

Contos da meia noite

(em fast forward)

Para contar uma história resumida ao extremo sobre como surgiram padrões de projeto, ~~Our whole universe was in a hot, dense state...~~ dois programadores: Kent Beck e Ward Cunningham pegaram as idéias de um arquiteto chamado Christopher Alexander e tentaram portá-las para o mundo da criação de Software.

fonte: Wikipedia

Depois vieram os Gang of Four, 4 outros autores, e lançaram um livro:

Trata-se de um compilado de padrões de projeto para programação orientada a objetos e que foi base para toda a popularização sobre o tema, tal que foi portado e adaptado para todas as outras linguagens.

E este é só um storytelling para dizer que este problema pode ser mais antigo o quanto você imagina e que a dor está em todos os lugares.

Tá, mas e o React?

Falando da lib em si, a própria documentação tem uma parte falando sobre o tema, explicando como foi tracejado sua concepção. Recomendo a leitura para entender mais como foram as idéias por trás de sua criação.

Tendo em mente tais idéias, antes de apresentar a minha lista gostaria de evidenciar alguns ideais de desenvolvimentos que serão pertinentes para o decorrer deste artigo:

DRY - Don't Repeat Yourself
KISS - Keep it simple...
Formatação Vertical & Horizontal - Clean Code

Se não tiver com pressa, busque sobre o assunto no Google mesmo, depois volte aqui :D

Bom senso

Creio que acima de tudo, vale o bom senso. Talvez da própria pessoa desenvolvedora (ou seja, você) ou mesmo em acordo de time. O padrão de desenvolvimento adotado na concepção do produto deve ser um princípio na criação do produto. Um ótimo exemplo é no link lá em cima dos princípios de design do React, o importante é o projeto ter consistência.

Não fará nenhum sentido colocar 20 design patterns enquanto você cita 10 nomes de pessoas importantes no desenvolvimento de Software se ninguém mais do seu time comprar a idéia. Seu código não tornará mais legível se quem ler seu código não entender onde você quer chegar.

Minha listinha

Essa lista não é bem uma lista, mas sim algumas releituras de documentações e alguns exemplos de melhorias de código que fui acumulando durante minha carreira.

Também aponto uma outra fonte de padrões já existentes: https://reactpatterns.com/

Citarei alguns padrões existentes na lista deles porém com outro viés.

Também gostaria de explicar algumas idéias básicas para quem é iniciante e que estão acessando esse artigo, então se algum item você achar básico demais pode pular.

JS(X)?

(jeiésséquis is too sexy)

O JSX é uma extensão de sintaxe JavaScript inspirada no XML, famoso "tag HTML dentro do seu JS". Coloco ele como uma primeira idéia a discutir pois ainda vejo muita galera que está começando com React achá-lo estranho. E é mesmo.

Porém gostaria de dismistificá-lo. O JSX, tal como explicado na documentação do React, diz-se "uma extensão de sintaxe para JavaScript". E realmente é. Apesar de popularizado pelo React, tem muito mais a ver com o Babel, que é uma ferramenta que compila seu código ECMAScript para uma versão que pode ser interpretada pelos navegadores.

ECMAScript é a mesma coisa que JavaScript, só que sem direitos autorais

Ou seja, quando você ver esse código:

function Component ({ children, ...props }) {
  return <div {...props}>{children}</div>
}

Se trata apenas de ECMAScript.

function Component ({ children, ...props }) {
  return React.createElement('div', props, children)
}

Se não acredita em mim, teste você mesmo! Escrevendo sem JSX você consegue usar React direto no navegador, já que o mesmo não entende código JSX.

"Ah mas eu uso classes".

Classes no ES6 são apenas syntax sugar de funções e prototipagem. Brinque um pouco com o REPL do Babel e veja como seria seu código para navegadores que não suportam ES6.

Darei outro exemplo abaixo, utilizando um componente dentro de outro:

function OutroComponente ({ children, ...props }) {
  return <div {...props}>{children}</div>
}

function Component ({ children, ...props }) {
  return <OutroComponente {...props}>{children}</OutroComponente>
}

O Babel transforma o acima no abaixo.

function OutroComponente ({ children, ...props }) {
  return React.createElement("div", props, children);
}

function Component ({ children, ...props }) {
  return React.createElement(OutroComponente, props, children);
}

No final é tudo função. - Guarde bem essa afirmação.

Render wat

No React meu componente pode retornar um componente ou uma composição de componentes.

function Component () {
  return <OtroComponente />
}

Mas lembre também que seu componente pode retornar também outros tipos:

Strings

function Component () {
  return "Oi leitore!"
}

Null

function NullComponent () {
  return null
}

(na verdade ele não renderiza nada visual)

Array

function ArrayComponent () {
  return [
    'Repetindo ',
    9,
    <NullComponent key='null' />,
    <StringComponent key='string' />
  ]
}

// Renderiza: "Repetindo 9Oi leitor!"

(Após o React v16.2)

É importante ressaltar que é necessário o atributo key e que assim funciona da mesma forma que a maioria dos reacteires estão acostumados a enfrentar laços de repetição:

function Component ({ items }) {
  return (
    <div>
      {
        items.map(({id, value}) =>
          <span key={`item-{id}`}>{value}</span>)
      }
    </div>
  )
}

edit: por favor, não utilize o índice do array como atributo key. Obrigado Stefano por me lembrar.

Seria como imprimir um vetor de componentes:

function Component (...) {
  return (
    <div>
      {[
        <span key={`item-1`}>{item1}</span>,
        <span key={`item-2`}>{item2}</span>,
        <span key={`item-3`}>{item3}</span>,
        {/* ... */}
      ]}
    </div>
  )
}

edit 2: A forma como o Typescript lida com childrens pode ser diferente.

Fragments

Também na versão do React v16.2 vieram os fragmentos. A idéia é bem similar aos DocumentFragment já existente no DOM.

function Component () {
  return (
    <React.Fragment>
      <li>hum</li>
      <li>dovs</li>
      <li>trevs</li>
    </React.Fragment>
  )
}

Utilizando o Babel após a versão 7 também é possível utilizar um shorthand:

function Component () {
  return (
    <>
      <li>hum</li>
      <li>dovs</li>
      <li>trevs</li>
    </>
  )
}

Link do repl do Babel pra você brincar.

Declaração de função: explícita ou Arrow Function

Nota da autora: essa é uma posição pessoal. Fique livre em discordar e não utilizar.

Para componentes React minha preferência é para funções explícitas quando não utilizar HOC ou algum "gerador" de componente. Um exemplo claro de função retornando componentes são styled components:

const Button = styled.button`
  /* ... */
`

Mas ...Por que?

Prefiro funções explícitas pois, por legibilidade, é mais fácil encontrar uma função no meio de diversas outras quando está declarada explicitamente que uma no meio de diversas consts.

Também historicamente o React DevTools não pegava o nome do componente a não ser que estivesse sido declarado utilizando função explícita. Hoje a história é outra. O DevTools consegue (nem sempre, discutirei mais a frente) pegar o nome do componente sem problemas.

Arrow Functions são anônimas, o que dependendo do problema chega-se a outro padrão:

.displayName

Use quando necessário. Fica difícil depurar código quando o DevTools mostra toda uma árvore de Anonymous Components. Não é nem questão de escrever ou não utilizando arrow function, adicionar .displayName não mata gatinhos e vai auxiliar bastante mesmo para diminuir a quantidade de styled(AlgumaCoisa) que pode prejudicar a visualização.

E vai aparecer bonito na stacktrace

Smart vs Dumb Components

(no geral) Dumb Components são fáceis de mockar, testar e inclusive de visualizar no Storybook

Separe sempre que possível seus componentes. Curto e utilizo bastante o Storybook. Com ele é possível deixar um componente fullscreen e inclusive utilizar uma view inteira da sua aplicação, mockando seus dados caso ela seja burra e testar a responsividade da página inteira utilizando o Chrome DevTools.

.defaultProps

Há duas formas para atribuir valores padrão para as props em Componentes Funcionais:

function Greeting({ name = 'Kitsu' }) {
  return <div>Hi {name}!</div>
}

function Greeting({ name }) {
  return <div>Hi {name}!</div>
}

Greeting.defaultProps = {
  name: 'Kitsu'
}

Prefira o primeiro formato exceto no caso que descreverei abaixo:

shouldComponentUpdate()

Quando fazíamos componentes usando classes, havia uma forma de otimizar a renderização e deixar explícito para o React quando é para renderizar novamente ou não dependendo de alguns fatores previamente configurados. Esta ferramenta é o shouldComponentUpdate.

class MyComponent extends Component {
  shouldComponentUpdate(nextProps, nextState) {
    // props
    if (this.props.name !== nextProps.name) {
      return false
    }

    // state
    if (this.state.name !== nextState.name) {
      return false
    }
  }

  render () {
    // ...
  }
}

Em componentes criados a partir de classes é possível utilizá-lo para controlar a renderização somente quando há alteração de props ou do state e inclusive dizer quais mudanças o componente deveria ativamente ouvir para renderizar ou não o componente.

Ainda sobre componentes de classes, também existe um shorthand que faz uma checagem shallow (raza):

class MyComponent extends PureComponent {
  render () {
    // ...
  }
}

A comparação raza é feita da seguinte forma: ele verifica se algum ítem de props ou do state alteraram no primeiro nível dos objetos. Trabalhando com imutabilidade dá pra gerenciar bem quando o componente deve renderizar.

E pra Componentes Funcionais?

O React.memo é algo novo (veio na versão 16.6) e veio exatamente para auxiliar neste problema, só tem um detalhe: funciona apenas para props (pois estados utilizando Hooks são executados dentro do próprio render do componente, não sendo possível uma interceptação do dado pelo React.memo). Abaixo um exemplo retirado da documentação.

function MyComponent(props) {
  /* renderize usando props */
}

function areEqual(prevProps, nextProps) {
  /*
  se prevProps e nextProps renderizam o mesmo resultado,
  retorne true.
  caso contrário, retorne false.
  */
}

export default React.memo(MyComponent, areEqual);

A maneira que o React lida com estado de componentes funcionais foi introduzida na versão 16.8 com a vinda dos Hooks.

Como os Hooks são executados dentro da própria função de render, o React.memo não consegue manusear por fora do componente o que acontece dentro dele.

E aí que vem o ganho de utilizar .defaultProps fora dos argumentos do React:

function Greeting({ name }) {
  return <div>Hi {name}!</div>
}

Greeting.defaultProps = {
  name: 'Kitsu'
}

const MemoGreeting = React.memo(Greeting)

Você pode deixar ítens no .defaultProps e eles ficam disponíveis para comparação na função do React.memo. Quando você deixa default props dentro da chamada dos argumentos da função, ele sempre será executado somente após o React.memo, não sendo possível efetuar a comparação.

Prop Types com Spread de atributos

(Se você usa TypeScript ~~(ou Flow)~~, pule uma casa.)

No React Patterns tem um exemplo bem bacana, mas gostaria muito de compartilhar um fato quando define-se propTypes no JavaScript. Pense no exemplo a seguir:

function Greeting({ name, ...restProps }) {
  return <MyDiv {...restProps}>Hi {name}!</MyDiv>;
}

Greeting.propTypes = {
  name: PropTypes.string.isRequired
}

O mais comum é deixar que o componente MyDiv tenha sua validação de Prop Types. Porém se em algum momento você precisar validar no seu componente coisas que já são validadas nos Prop Types do componente filhe, lembre que o .propTypes é um objeto.

Greeting.propTypes = {
  ...MyDiv.propTypes,
  name: PropTypes.string.isRequired
}

Você pode estender os seus Prop Types com qualquer outro objeto de Prop Types.

Condicionais

Ter condicionais no meio do JSX é um anti-pattern bem eficaz, muito utilizado e amplamente difundido por reacters. É normal encontrar um short-circuit evaluation ou mesmo um ternariozinho aqui ou lá e retirar esses condicionais torna o código verboso por provavelmente precisar criar mais Componentes. Porém creio que todos que já codaram React também já viram códigos com uma superutilização delas.

function Component ({ vaiChover, diaDeBanho, calor }) {
  return (
    <div>
      {!vaiChover && diaDeBanho && calor && <Chuveiro />}
    </div>
  )
}

Nestes casos o que recomendo como ação básica imediata é: extraia a lógica de condicionais para uma variável a parte:

function Component ({ vaiChover, diaDeBanho, calor }) {
  const shouldDisplayChuveiro = !vaiChover && diaDeBanho && calor
  return (
    <>
      {/* ... */}
      {shouldDisplayChuveiro && <Chuveiro />}
      {/* ... */}
    </>
  )
}

Melhora a legibilidade? Nem tanto.

Porém em alguns casos é possível jogar essa responsabilidade pro componente filho (claro, quando fizer sentido essa responsabilidade ser repassada para ele). Lembra que você pode fazer seu componente retornar null e não renderizar conteúdo?

function Chuveiro ({ vaiChover, diaDeBanho, calor }) {
  if (vaiChover) return null
  if (!diaDeBanho) return null
  if (!calor) return null

  return 🚿
}

function Component (props) {
  return (
    <>
      {/* ... */}
      <Chuveiro {...props} />
      {/* ... */}
    </>
  )
}

Proxy

O site do React Patterns tem um ótimo exemplo simples com um botão:

<button type="button">

// Ergo Proxy
const Button = props =>
  <button type="button" {...props} />

Mas gostaria de estender essa idéia. Na verdade, tá mais para um hack. No React você grosseiramente pode utilizar componentes com ponto (.). Um exemplo da própria documentação do React é a Context API.

const MyContext = React.createContext(defaultValue)

// Provider
<MyContext.Provider value={/* some value */}>

// Consumer
<MyContext.Consumer>
  {value => /* renderiza algo baseado no valor do context */}
</MyContext.Consumer>

Ok, eu menti sobre usar componentes contendo ponto no nome, tecnicamente não é o correto. Mas sim, você pode utilizar componentes como atributos de objetos. Isso possibilita a criação de certos componentes "escopando" sua utilização, como por exemplo:

import MyBanner from 'path/to/MyBanner'

<MyBanner>
  <MyBanner.CloseButton>Mensagem a11y pro botão de fechar</MyBanner.CloseButton>
  <MyBanner.Image
    src="https://..."
    alt="mensagem descritiva sobre a imagem" />
  <MyBanner.Text>Conteúdo pro meu banner</MyBanner.Text>
  <MyBanner.Cta onClick={handleOnClick}>E aqui vem o call-to-action</MyBanner.Cta>
</MyBanner>

E o arquivo do meu componente seria algo como:

// MyBanner.js

const MyBanner = styled.div`...`

MyBanner.CloseButton = styled.button`...`
MyBanner.Image = styled.img`...`
MyBanner.Text = styled.p`...`
MyBanner.Cta = styled.button`...`

export default MyBanner

Claro que esse padrão é longe de ser algo ideal, eu diria que é muito mais situacional: quando não há um controle sobre criação de componentes que sejam reutilizáveis ou para algo muito específico que vale ter tal escopo.

Ainda ressalto que o ideal e mais recomendável seria utilizar componentes já existentes:

import MyBanner from 'path/to/MyBanner'

<MyBanner>
  <CloseButton>Mensagem a11y pro botão de fechar</CloseButton>
  <Image
    src="https://..."
    alt="mensagem descritiva sobre a imagem" />
  <Text>Conteúdo pro meu banner</Text>
  <Button onClick={handleOnClick}>E aqui o call-to-action</Button>
</MyBanner>

E Hooks?

Creio que este é um assunto que vale uma nova postagem só para este assunto e acho que já me estendi em vários outros aspectos.

Mas tudo que falo para componentes vale para funções ;D

Quando refatorar?

Queria usar etimologia para lembrar que sempre dizemos refatorar e nunca fatorar. Ou seja, antes de tudo: faça funcionar. E exatamente por fazer funcionar, ninguém vai fazer um código a la John Carmack de primeira. Também muitos de nós enfrentamos entregas, não há como fugir.

Faça com calma e coloque testes. Lembre daquele ciclo do TDD e aplique: red-green-refactor. Faça o teste para quebrar; faça funcionar e então faça direito. Ou mesmo:

Faça funcionar, faça direito, faça-o executar rapidamente. - Kent Beck

Por que refatorar?

Mesmo com a correria de prazos, refatorar o código de uma maneira que utilize padrões já conhecidos ou mesmo sem utilizá-los já é um ganho quando bem executado. Se o produto tem a necessidade de ter futuras manutenções e ser escalável, é necessário ter um código de fácil legibilidade e sem muito atrito para modificações e melhorias.

Ainda jogo uma analogia com algo da nossa área: para otimizar a rapidez de leitura geralmente bancos de dados gastam mais tempo na parte da escrita para deixá-lo com certa ordenação para facilitar no resgate do dado.

Creio que para código podemos ter algo semelhante: perca um tempo para escrever um código que fique fácil de dar manutenção pois quando for preciso e chegar a hora da manutenção, terá menos problemas e vai ser mais rápido fazer qualquer alteração.

Como refatorar?

Eu indico Refactoring, do Martin Fowler ~~e também o Clean Code, do Uncle Bob~~.

Os pontos abaixo são bem explorados pelos livros e creio que com estas 2 dicas sensacionalistas resumidas você irá conseguir escrever seu código tão desejado:

Formatação

Atente-se à formatação do teu código. No Clean Code há partes onde explicam tanto formatação horizontal quanto formatação vertical.

Em qualquer idioma, ler parágrafos grandes prejudica a leitura de qualquer conteúdo editorial. Da mesma forma, ter código pouco espaçado ou com muito scroll acaba virando um pesadelo para entender seu funcionamento.

Escreva seu código como uma carta de amor para outro desenvolvedor

Levem na brincadeira a afirmação porém escrevam código para que outros desenvolvedores entendam, você inclusive. E não estou dizendo de encher seu código de comentários que muitas vezes podem ser redundantes. Deixe o seu código semântico, não importando se é HTML, JS ou qualquer outra linguagem, e que seja fácil de ser lido e com APIs de fácil utilização. Faça com que seu componente seja fácil de ser utilizado e entendido. Faça uma boa documentação e de fácil manutenção/atualização (ex: Storybook) e automatize o que for possível (ex: documentar as PropTypes direto da declaração de interface do TypeScript).

Algo que vejo crescer nos últimos anos é o termo Developer Experience (DX). Mesmo se seu código não for aberto, ao escrever código que possa ser lido até por uma criança de 5 anos (não literalmente, pfv), isso pode facilitar pra você mesmo quando tiver de dar manutenção 5 anos depois, lembrando zero em relação ao conhecimento que você possui no momento da escrita do código.

Estrutura

Para estruturar arquivos e código existem diversos padrões. Antes de tudo: dê preferência pro padrão já existente, ainda mais se for um padrão já adotado pelo time.

Existem diversos padrões: ducks, Clean Architecture...

Pessoalmente gosto de algo mais livre com uma pegada mais funcional e um pouco de DDD. Caso também seja o teu perfil, recomendo bastante a estrutura do Dan Abramov:

https://react-file-structure.surge.sh/

E eu estenderia também para código, tal como John Carmack sugere. Como citado anteriormente: Se teu módulo (arquivos ESM) começar a ficar grande, quebre em mais arquivos.

Estrutura bonus

Tente também não criar uma estrutura de arquivos muito aninhada. Tente sempre deixar o mais flat possível, ou seja, evite diretórios dentro de diretórios virar uma árvore gigante. Tente sempre deixar o mais perto possível da raiz do pacote/projeto e quebre mais os seus componentes e código se começar a aninhar muito.

Se seu projeto for um monorepo, extraia/quebre funcionalidades em módulos/pacotes. "Make each program do one thing well". Quebre mais seu código e faça com que seus módulos sejam pequenos e que façam apenas uma coisa e bem. Isso também facilitará na hora de trocar um módulo por outro e facilita também na hora de criar testes.

E não se esqueça

Use tanto testes quanto estilo de código (Coding Style) e ferramentas de automatização ao seu favor. Faça interfaces que facilitem o uso de componentes, "Não me faça pensar".

Quanto mais abstraído teu código e fácil de entender, mais rápido será para fazer alterações, dar manutenção e adicionar funcionalidades.

Conclusão

Desenvolvimento de Software ainda é uma disciplina bem artesanal. Mesmo tendo automações, ainda é necessário escrever código para que programas, sites e aplicativos funcionem. Ainda não é acessível ter automatizado algo que nos cuspa códigos, pior ainda para frontend que ainda temos que além de pensar em fazer um bom código e tanto seu código quanto a saída pro usuário devem ser semânticas, leves e rápidas para rodar em celulares e em leitores de tela por exemplo.

Outra profissão que gosto de citar é a de arquitete, já que as idéias para padrões de projetos foram inspiradas por um. Só que a diferença é que nós pessoas desenvolvedoras temos que arquitetar sistemas que além de possuir uma base boa e forte, todo o produto deve ser escalável e possível de adicionar novas funcionalidades, algo que para um arquitete seria bem mais limitado.

Enquanto a tecnologia não evoluir a ponto de escrever programas inteiros usando inteligência artificial e automações, apesar de escrevermos códigos que serão lidos pela máquina, não se esqueça que eles também serão lidos por outros humanos.

EDIT

Por favor, se for consumir os livros: "Código Limpo", "Arquitetura Limpa" ou "Codificador limpo" não compre, ~~pirateie~~.

Pois o autor é assumidamente transfóbico. Sei que é um pedido egoísta mas por favor, não consuma artigos de pessoas transfóbicas.

Experiências com Svelte por uma pessoa desenvolvedora React (defasado) [pt-BR]

Nina Kitsu — Thu, 01 Aug 2019 21:29:46 +0000

ARTIGO ANTIGO Artigo escrito em agosto de 2019. Na época o Svelte não possuia suporte nativo a TypeScript e o Sveltekit ainda não existia.

Esta não é a primeira versão do Svelte e creio que a grande maioria nunca se importou antes pois não parecia maduro o suficiente. Para mim foi assim, pelo menos. Também sinto que não sou o único que começou a ter interesse na ferramenta após a versão 3.

...e fiquei empolgada ^{^fodeu}

Para situar você, meu caro leitor, minha cara leitora e meu caro leitore de único artigo, vou introduzir um pouco sobre Svelte. O texto acabou ficando um pouco longo pois não pretendo dividir em partes dado que faço artigos com pouquíssima freqüência (nula, pra ser sincera). As minhas experiências foram focadas em integrações de Svelte com ferramentas e tecnologias de mercado. Caso você já saiba o que é Svelte, pule para a parte que falo das minhas impressões.

Adiciono também que eu repito muita coisa tanto neste próprio post quanto de conteúdo de outras postagens. Apesar disto, se você ver que eu passei rápido por um assunto é porque devem ter fontes melhores aprofundadas e eu focarei sobre esse meu tempo experimentando o framework.

O que é Svelte?

Oh noes! Mais um framework...

Svelte é um framework de componentes com escrita declarativa e que converte seus componentes em código nativo pro navegador.

acima é um resumido daqui

Quando fala-se de frameworks para componentização com escrita declarativa nada mais é que escrever componentes tal como hoje os maiores frameworks de mercado fazem (React, Vue, Angular...) e evitar ficar jQueryzando toda sua aplicação, escrevendo código imperativo que modifica direto pro DOM.

Já o diferencial desta ferramenta é a segunda parte:

Na verdade este framework não é um framework que dá importância em runtime como os frameworks atuais, muito pelo contrário, seu ponto forte é o compilador.

ele compila seus componentes para código nativo do navegador

O compilador irá transformar todo seu código declarativo e bem estruturado em algo que altere imperativamente o DOM. Diga adeus ao Virtual DOM. Ele irá jQueryizar sua aplicação por você enquanto seu código continuará componentizável e de fácil manutenção.

e não é só isso!

Desde sua concepção foi pensado em gerar aplicações reativas. Recomendo muito a palestra do Rich Harris sobre "Pensando em reatividade" 🇬🇧.

Antes de tudo, sintaxe!

Recomendo este completíssimo artigo escrito pelo Claudio Holanda: Svelte: A era dos frameworks-compiladores.

E por onde começar?

O site oficial conta com uma ótima ferramenta ao qual nós desenvolvedores estamos bem acostumados: REPL. É basicamente o parquinho das pessoas desenvolvedoras e a principal ferramenta usada pela comunidade (no chat - link no final do artigo) para apontar problemas ou erros. Não é necessário baixar nada, programe na esquerda e veja a saída na direita. Simples assim.

Caso queira um melhor direcionamento sobre as funcionalidades da plataforma, baseado no REPL também foi criada uma ferramenta interativa com tutoriais e uma galeria com exemplos básicos.

Svelte, hoje vou lhe usar!

De acordo com a documentação, para inicializar projetos Svelte foi popularizado uma outra ferramenta geradora de código chamado degit, também desenvolvida pelo Rich Harris. Basicamente com esta ferramenta você passa um repositório público Git e ele irá baixar e descompactar a última versão de uma branch na pasta onde você irá desenvolver seu código.

Para facilitar, foram disponibilizados repositórios de template com a possibilidade de escolher a ferramenta para criação de bundle em duas opções: Webpack e rollup.

Desenvolver em Svelte loucamente localmente

Para iniciar localmente uma aplicação SPA em Svelte, basta baixar o template:

# using rollup
npx degit sveltejs/template my-svelte-project
# using webpack
npx degit sveltejs/template-webpack my-svelte-project
cd my-svelte-project

npm install
npm run dev

fonte: https://svelte.dev/

Ao rodar npm run dev a aplicação irá subir um servidor local em modo de desenvolvimento apontando para http://localhost:5000/. Após o desenvolvimento, basta rodar npm run build e sua aplicação SPA estará pronta para produção com os artefatos criados dentro da pasta public.

Usando o Sapper

Desatualizado. Ler sobre Sveltekit

O Sapper é uma aplicação inspirada no Next.js, um framework bem famoso na comunidade React. Mas uma funcionalidade que me agradou bastante foi a de geração de conteúdo estático, algo bem parecido com o Gatsby (porém mais básico, sem GraphQL etc).

# for Rollup
npx degit "sveltejs/sapper-template#rollup" my-app
# for webpack
npx degit "sveltejs/sapper-template#webpack" my-app
cd my-app

npm install
npm run dev & open http://localhost:3000

fonte: https://sapper.svelte.dev/

Um aviso importante: o reload automático (HMR) pode não funcionar muito bem utilizando Sapper, necessitando constantemente ter que matar e reinicializar a aplicação durante o desenvolvimento ao utilizar códigos durante lifecycle.

Ao executar npm run build, o Sapper gera uma aplicação Node dentro da pasta __sapper__/build. Também é possível utilizar express (no template é utilizado um servidor mais leve chamado Polka).

Para os hypeiros e amantes de JAM Stack, como eu mencionei anteriormente também é possível gerar conteúdo estático. Basta rodar npm run export e ele criará os artefatos para produção na pasta __sapper__/export.

Pontos interessantes

Infelizmente não há suporte nativo oficial para TypeScript mas por um outro ângulo, talvez faça desta ferramenta mais amigável para quem está começando em relação a...

Outras ferramentas do gênero

Tem alternativas? Tem sim senhor!

Stencil

A filosofia do Svelte não é gerar web components como foco principal 🇬🇧. Porém também é possível criar custom elements nativamente conforme esta issue e utilizar como web components.

O Stencil é desenvolvido pela equipe responsável pelo Ionic (ou seja, projeto "parrudo de responsa") e tem em seu showcase empresas de renome. Mesmo o Svelte tendo uma versão para mobile (svelte-native), diria que vale a pena ver ambos. Utiliza TypeScript.

Algumas alternativas em 2022 (edit)

SolidJS
Qwik

Real laife

Mesmo sendo clichê de todo artigo brazuca sobre Svelte, repito aqui também um dos maiores cases são as maquininhas verdinhas de pagamento da Stone, usando o Svelte (versão 2 do Svelte).

Como citado no vídeo do Rich Harris

open source 😍.
créditos: @kaisermann

"Mas quero ver um caso real na web! 😡😡😡"

Ao lembrar que o criador trabalha no The New York Times na Vercel dedicado somente ao Svelte (2022), encontrei um outro case de uso de quando ele ainda trabalhava no NYT, integrando com d3: um especial sobre a votação na grã-bretanha. Também foi desenvolvido numa versão mais antiga do Svelte.

Enfim...

Vim de React.

Fanboy mesmo, assumida.

Sempre tinha um detalhe ou outro e que sempre me motivou a não trocar de framework do coração.

Já tinha visto algo bem superficial sobre o Svelte e tinha achado interessante porém sempre passava batido por não ter ouvido muito sobre utilização.

Passou um tempo e após três versões major surgiram muitos cases bem legais e pensei em finalmente dar uma chance e aprender mais sobre.

E por onde comecei?

Sinceramente digo que quando eu começo a aprender algo novo, me sinto intimidada em ir direto na documentação por mais que ela seja boa. Tutoriais e artigos também nem sempre são completos ou abrangentes e geralmente deixam passar algo. Optei então por um curso na Udemy (variando de R$ 28 - 60, quando tem promoção... ~~clichê de pitches: não estou ganhando nada em citar eles 😞~~) ministrado pelo Maximilian Schwarzmüller: Svelte.js - The Complete Guide (em inglês), do Academind.

É um curso que, apesar de básico/iniciante, cobre muito bem diversas partes das funcionalidades principais contidas no Svelte 3 (versão atual no momento da postagem) e é bem didático.

Componentização

Como todo framework atual, seu desenvolvimento é voltado a componentização da UI. Achei a parte da criação de componentes bem semelhante ao Vue.js no caso de ter tanto o código de marcação (Markup), os estilos e o JavaScript num único arquivo.

Dentro do JavaScript, é possível escrever direto em ES6. Como citado anteriormente, ainda não possui suporte a TypeScript nativo, porem...

Preprocessadores

Como o código no Svelte é compilado, é possível utilizar preprocessadores de um jeito bem trivial. Como se trata de uma ferramenta de terceiro (módulo não oficial porém com muitos mantenedores), sua integração pode não ser das melhores.

É possível integrar outras linguagens ao escrever componentes como TypeScript e CoffeScript para aplicação; Pug (antigo Jade) para Markup (HTML) e Postcss, SASS, Less e Stylus para estilização. É bem simples para integrar.

Dei umas brincadas usando TypeScript e testei usar Stylus e não tive muitos problemas na utilização, porém tive outros problemas (que foram agregados num ítem a parte no final do artigo) com...

Ferramentas e Integrações

É bem completo o suporte do Svelte para ferramentas de integração.

ESLint

Adicione este plugin oficial: eslint-plugin-svelte3. Simples assim.

Sua configuração é bem trivial e como não se trata de um preset, é bom lembrar que a ativação das regras devem ser feitas individualmente dentro de rules no arquivo de configuração.

Testes

Para quem veio de React já deve conhecer o react-testing-library do Kent C. Dodds. Quando a ferramenta se popularizou e generalizou dando origem a outras Testing Libraries, e o Svelte não ficou de fora: @testing-library/svelte.

Ele requer um transformador para o Jest: jest-transform-svelte.

Prettier

Esse "embelezador" de código também não poderia ficar de fora. Basta adicionar este plugin e adicionar um override nas configurações do Prettier conforme descrito na documentação.

Storybook

Sim, é possível ter um Storybook com componentes escritos em Svelte. Seu suporte ainda é básico.

Famoso "saiba mais"

Com um famoso clique aqui.

E estilos?

Existem certas características que eu já adianto:

todo css escrito num arquivo de componente será escopado para aquele componente somente

Ao compilar, o Svelte altera os seletores e adiciona classes para evitar conflitos de estilo. E esta funcionalidade é padrão do framework.

não é possível utilizar interpolação de variáveis JavaScript dentro da tag `<style>`.

Porém nada impede de repassar tais valores utilizando variáveis CSS: exemplo leviano. Claro que também é possível alterar estilos inline utilizando o atributo style, porém lembre que por boas práticas...

o Svelte assume que o CSS deve ser intocável

Ou seja, o que estiver dentro da tag <style>, após a transformação dos seletores em classes escopadas é um código pronto para ser extraído para um arquivo separado (extract-text-webpack-plugin, estou falando de ti).

Não sei nem se é possível utilizar CSS-in-JS, inclusive. Porém lembre do front-end raiz, onde utilizamos classes para definir diferentes estilos ao invés de alterá-los em tempo de execução.

Mas... Não tem Virtual DOM?

É inegável que o pattern de Virtual DOM do React é performático (palavras sob influência da minha fanboyzisse, não leve a sério!), porém pela filosofia do Svelte de compilar seu código para uma aplicação que utiliza e altera direta e cirurgicamente o DOM, ter um Virtual DOM seria redundante além de adicionar um runtime talvez desnecessário.

Reatividade

O que também me chamou muita atenção foi a atualização de variáveis de forma reativa. No código, basta adicionar uma instrução específica pro Svelte: "$:".

Faz parte da sintaxe do JavaScript, é válido e até tem um nome específico: etiqueta. No JavaScript é utilizado como controle de fluxo em loops e em outras linguagens, geralmente como controle em goto.

Resumindo, toda vez que uma atribuição de variável, expressão ou execução de função é utilizada à direita do sinal $: será calculado ou executado novamente em caso de mudança de valores de variáveis utilizadas.

Stores

Como toda biblioteca de componentização de UI, não poderia faltar um gerenciador de estado. E suas Stores nativas foram desenvolvidas nesta versão já pensando em reatividade, utilizando um padrão já conhecido das pessoas desenvolvedoras que é o pub-sub.

E para usos simples, há um shorthand (escrita facilitada) onde facilita o uso de dados da Store sem se preocupar com subscribe ou unsubscribe.

Loops Eficazes

Outro ponto que achei legal é que mesmo lidando direto com o DOM, o Svelte se vira bem em relação a loops. Claro que infelizmente não é algo automático pois o Svelte precisa saber qual a key para cada elemento porém é possível trabalhar com eficácia na hora de utilizar loops, evitando repaints.

E falando em shorthands...

Gostei bastante da escrita de componentes, para as tarefas mais triviais sempre tem uma forma mais reduzida de se escrever, por exemplo, um two-way bind; repassar um evento, seja personalizado ou não; alternar classes CSS; usar rest-spread ou até mesmo...

Transições e animações!

Algo que eu realmente não esperava vir de brinde. Para animações, efeitos e transições triviais o Svelte possui uma mini biblioteca com uma coleção delas, e de fácil implementação.

Também é possível utilizar funções de animação e easing personalizadas, mas aí meu amigo:

...é muita matemática rs. Deixo esta parte pra galera que curte desenvolver jogos ou nunca faltou em uma aula de álgebra linear.

Tags especiais

O Svelte também possui alguns componentes nativos que auxiliam no desenvolvimento de um código mais declarativo. Por exemplo, fica bem trivial obter a largura do viewport.

Dentre as tags especiais há funcionalidades como alterar tags no head dentro do Sapper, usar recursividade no próprio componente, usar componentes dinâmicos...

Compilador opinativo

Tanto o compilador quanto os linters de sintaxe (pelo menos digo isto em relação ao plugin de Svelte para Visual Studio Code) avisam quando há erros triviais de acessibilidade (imagem sem alt) e código css não utilizados pelo componente.

Reatividade (parte 2)

Quando ouço reatividade, a primeira coisa que veio à minha cabeça foi RxJS (digo pelo nome da lib)...

Pensei levianamente comigo: "e se eu trocasse a store nativa com autosubscribe por um Observable?" Tinha lido que haviam certas compatibilidades entre ambos e decidi testar por conta própria. Para minha surpresa:

^{(desculpe a bagunça no código)}

Sim, o Svelte integra bem com RxJS.

edit: infelizmente o exemplo acima está rodando com Svelte v3.6. Quando houve a atualização para a v3.7 acabou quebrando. Por enquanto eu fixei o codesandbox de exemplo na versão v3.6 do Svelte. Agradecimentos ao @kaisermann novamente por ter me avisado :D

Deixo um lembrete: o Svelte não lida tão bem enquanto ainda não tiver recebido algo do stream (timeouts). Para evitar possíveis erros, recomendo uma das seguintes soluções: mesclar com um outro Stream, contendo um valor nullable e emitindo antes da resposta, assim podendo checar dentro de um {#if} se já foi emitido algum valor ou englobar o stream numa Promise/generator e utilizar {#async}.

Mas ...runtime?

Ok, eu menti quando falei que o Svelte não possui uma lib de runtime. Não tem, claro, para Virtual DOM pois como expliquei, seria redundante. Porém a runtime é bem enxuta. São praticamente funções que lembram Hooks do React.

documentação

Lifecycle

Os pares onMount & onDestroy relativos a renderização e beforeUpdate & afterUpdate relativos a atualização do componente.

Context

setContext & getContext. Também semelhante a contextos no React.

`preloading`

Este é exclusivo do Sapper. Este é executado quando utiliza-se diretivas nos links, carregando e executando dados antes mesmo do usuário clicar no elemento (no evento de mouseover, predizendo sua ação).

E claro, SSR!

Fica a critério do desenvolvedor. Como anteriormente citado, o Sapper auxilia neste aspecto. Como anteriormente citado, esta ferramenta foi inspirada no Next.js. Claro que é possível juntar tudo num bundle utilizando somente o Svelte e criar sua SPA.

Porém usando o Sapper, é possível estender a funcionalidade da sua aplicação para utilizar um servidor com SSR (podendo inclusive utilizar Express).

Ou no melhor dos casos, exportar uma aplicação JAM Stack utilizando o sapper export (algo como um Gatsby simplificado), gerando artefatos estáticos, prontos para subir para um CDN. O próprio Svelte lida automagicamente com a parte de hidratação da aplicação.

Problemas que tive

Claro que nem foi somente louros. Contarei algumas experiências:

Jest

Tive alguns problemas ao utilizar Stylus. Para testes, foi contornado utilizando um transformador próprio (neste exemplo estou utilizando somente Stylus, mas é possível integrar qualquer um existente. Aconselho a utilizar este transformador personalizado pois o jest-transformer-svelte e a maioria dos outros pacotes similares possuem dependência com rollup, pessoalmente considero desnecessário e cria arquivos não referenciando o arquivo original. Apesar disto, lembro aqui que a cobertura de código é um tanto confusa para arquivos Svelte, senão inexistente, ou seja, não muito confiável. Logo aconselharia a descartar cobertura de código em projetos Svelte.

Prettier

Algo que me fez deixar preprocessadores em segundo plano foi que tive muitos problemas ao utilizar o plugin para Prettier. Este funciona muito bem para código de estilos feitos em CSS porém a integração com o Stylus não é bem definida e tive muitos problemas como formatação errônea. Como o plugin não integrava muito bem com preprocessadores, acabava transformando o código em algo ilegível e não parseável, e, para evitar escrever muitos prettier-ignore, recomendo evitar o uso de preprocessadores.

Para estilos em específico, vi também que ao utilizar um preprocessador o compilador não chega a verificar e validar estilos não utilizados pelo componente.

ESLint

Teve um bug em específico no ESLint (já corrigido) usando Sapper. Como o lint-staged passa o nome do arquivo e os arquivos de rota com parâmetro do Sapper (e do Next.js 9) usam colchetes, o ESLint interpretava os colchetes como parâmetro de busca do Bash e não encontrava o arquivo, mesmo escapando.

HMR

Outra dor de cabeça que tive, utilizando Sapper é que o live reload pode não funcionar muito bem ao utilizar funcionalidades do lifecycle do Sapper como o preloading. Caso for utilizar o Svelte puro não terá problemas, porém ao utilizar o SSR do Sapper, ele meio que se perde ao ter modificações no lado do código do servidor sendo necessário reiniciar a aplicação dependendo da modificação.

Conclusão

^{(como ensinado nas aulas de redação, tem que ter um, claro!)}

Não me considero uma early adopter... hypera talvez. Porém a minha experimentação foi positiva e muito melhor do que eu esperava. Como disse, balançou meu coração que era anteriormente exclusivo do React. Muitas das funcionalidades acima listadas não são nem um pouco triviais de implementar nem no meu framework favorito.

Ainda é novidade e não há mercado para sua utilização por aqui (Brasil). Porém na minha opinião ainda tem muito potencial. Claro que muito do que eu falei tem meu viés. Mesmo curtindo React, meu perfil é muito mais tentar ir para o lado do SSR e otimizações estáticas, não curtindo tanto manter somente em SPA, mobile (e consequentemente webcomponents e micro frontend) e tentar aliviar ao máximo a execução da aplicação no navegador do usuário. Logo este framework acertou em cheio minhas expectativas.

Espero em breve ter Meetups à medida que sua adoção cresça (tenho esperanças rs).

Este post foi criado como uma resposta ao pedido do @felipefialho para falar sobre minhas experiências com o Svelte

Gostaria de agradecer a galera do Discord por terem ajudado em alguns pontos deste artigo.
Também agradeço o @kaisermann novamente, por ter ajudado a escrever este artigo.

Também:

Curto conversas mais informais e memes antigos... Dificilmente escrevo para a comunidade não sendo nos fóruns. Não é minha intenção ofender ninguém com postagens deste tipo. Peço também para não me ofender nos comentários lá embaixo se não achou graça neste post e achou que isto estragou o conteúdo. A tentativa foi para tentar deixar o conteúdo do post mais leve para leitura. Peço desculpas pelos erros, principalmente de concordância, pois vou alterando o texto de acordo com o que me passa pela cabeça e nem sempre os diffs ficam harmoniosos. Ainda mais tendo este texto como um compilado de tudo que passei durante esse tempo de experimentação. As opiniões expressadas são pessoais e sobre este específico momento. Nunca as tome como verdade e tanto minhas opiniões como as ferramentas descritas podem mudar e evoluir e se tornarem futuramente divergentes deste texto. BTW eu adicionei as imagens sem me preocupar em normalizá-las ou copyrights pois são somente ilustrativas (inclusive podem parar de funcionar pois hotlinkei ilegalmente, sendo bem amador mesmo). Este post não possui monetização (pelo menos não para mim, autor...). Adicionalmente, peço para levar na brincadeira sobre minha posição sobre React. Não existe melhor framework, e sim o melhor framework é aquele que melhor se adequa ao produto e ao time.

Join Us!

Referências

(os conteúdos exclusivos em inglês eu deixei uma bandeirinha unicode do lado: 🇬🇧)

Meta 🇬🇧

Posts relacionados

Why I don't use web components 🇬🇧, por Rich Harris (post obviamente viesado, porém recomendo ler os comentários)
Svelte: o framework JavaScript que não é um framework, por Thiago Frias
Svelte: A era dos frameworks-compiladores, por Claudio Holanda
Svelte 3 + Firebase: Criando um CRUD com a nova ferramenta JS, onde o Sergio Lima ensina a fazer uma aplicação integrada com o Firebase
Disappearing Frameworks 🇬🇧, por Peter O'Shaughnessy
Getting Started with Svelte 3 🇬🇧
Svelte 3 Tutorial for The Impatient (React) Developer 🇬🇧, por Valentino Gagliardi

Com direito a tradução dos últimos dois artigos feita pelo Eduardo Rabelo:

Vídeos

Cursos

Svelte.js - The Complete Guide 🇬🇧, por Maximilian Schwarzmüller

Changelog

2019-08-06

Adicionado breve referência sobre Storybook
Patchfix do codesandbox fixando o Svelte na versão 3.6
Adicionado o post do Sergio Lima nas Referências

2022-10-19

Adicionando descrição para as imagens (espero não ter pulado nenhuma)
Alteração de pronomes e utilização de linguagem neutra (posso ter também passado batido por algo)

Licença deste texto

Beerware

DEV Community: Nina Kitsu

Runtimes JavaScript [pt-br]

Mas o que é um runtime?

Node.js

Existem outros runtimes para ambientes JavaScript?

Deno

Bun

Diferenciais

Conclusão

Links

História sobre usar o JavaScript para programar JavaScript

Motivação

E o JavaScript?

Ferramentas para códigos escritos em JavaScript

Google quem?

Ok, não foi bem assim...

Tá, e pra que toda essa historinha longa?

Fontes

Refatoração de código React

Contos da meia noite

Tá, mas e o React?

Bom senso

Minha listinha

JS(X)?

Render wat

Strings

Null

Array

Fragments

Declaração de função: explícita ou Arrow Function

Mas ...Por que?

.displayName

Smart vs Dumb Components

.defaultProps

shouldComponentUpdate()

E pra Componentes Funcionais?

Prop Types com Spread de atributos

Condicionais

Proxy

E Hooks?

Quando refatorar?

Por que refatorar?

Como refatorar?

Formatação

Escreva seu código como uma carta de amor para outro desenvolvedor

Estrutura

Estrutura bonus

E não se esqueça

Conclusão

EDIT

Experiências com Svelte por uma pessoa desenvolvedora React (defasado) [pt-BR]

O que é Svelte?

Antes de tudo, sintaxe!

E por onde começar?

Svelte, hoje vou lhe usar!

Desenvolver em Svelte loucamente localmente

Usando o Sapper

Pontos interessantes

Outras ferramentas do gênero

Stencil

Algumas alternativas em 2022 (edit)

Real laife

Enfim...

E por onde comecei?

Componentização

Preprocessadores

Ferramentas e Integrações

ESLint

Testes

Prettier

Storybook

Famoso "saiba mais"

E estilos?

todo css escrito num arquivo de componente será escopado para aquele componente somente

não é possível utilizar interpolação de variáveis JavaScript dentro da tag <style>.

o Svelte assume que o CSS deve ser intocável

Mas... Não tem Virtual DOM?

Reatividade

Stores

Loops Eficazes

não é possível utilizar interpolação de variáveis JavaScript dentro da tag `<style>`.

`preloading`