Realmente precisamos do TypeScript em 2020?

O TypeScript se tornou uma das habilidades essenciais para um desenvolvedor web moderno. Em 2019, ele entrou nos 10 idiomas mais usados ​​no GitHub , seu suporte foi totalmente adicionado ao aplicativo Create react e você pode encontrar muitas outras evidências de sua crescente popularidade. Ao mesmo tempo, linguagens como Java e C continuam a perder terreno .

Quando falamos sobre os benefícios do TypeScript, geralmente aparece a seguinte lista:

• TypeScript suporta digitação estática
• O TypeScript facilita a leitura e a compreensão do código.
• O TypeScript ajuda a evitar os muitos erros dolorosos que os desenvolvedores costumam fazer, graças à verificação de tipo no código
• TypeScript incentiva os desenvolvedores a seguir as melhores práticas de OOP
• Como resultado acima - o TypeScript economiza tempo dos desenvolvedores

Curiosamente, todos os itens desta lista são levados com fé sem um olhar crítico. Hoje, sugiro que você considere esses pontos mais de perto e descubra se eles são realmente tão úteis para nós.

Como o principal objetivo do TypeScript é reduzir o número de bugs, vamos decidir por que isso é tão importante? A resposta é simples: quanto menos erros, menos tempo dispendioso para desenvolvedores e testadores, obteremos um produto que vale a pena por menos dinheiro e ele começará a gerar renda mais cedo.

Com isso em mente, vamos descobrir como o TypeScript pode nos ajudar a melhorar nossa produtividade e eficiência.

Digitação estática - um tablet mágico para bugs?

O principal recurso do TypeScript é o suporte à digitação estática. Existe uma crença generalizada entre os desenvolvedores de que a digitação dinâmica é a fonte de quase todos os problemas que os desenvolvedores de JavaScript têm.

Eu me pergunto o que as pessoas más encontram na digitação dinâmica? Por que essa enxurrada de críticas não recai sobre outras linguagens dinâmicas, por exemplo, Python e Ruby? Só posso supor que o problema não está tanto na digitação dinâmica quanto na conversão de tipo no JavaScript. De fato, às vezes pode ser muito desagradável surpreender código como este:


Mas esse é um problema, e não um conhecimento insuficiente de JavaScript, e não a própria linguagem. Imagine que você tem um carro esportivo poderoso. Mas suas habilidades de condução são suficientemente medíocres. Você exigirá que o fabricante do carro faça alterações para reduzir a velocidade máxima do carro ou aprenda a dirigir de forma avançada e se torne um profissional excepcional? O que o TypeScript nos oferece é limitar as possibilidades de digitação dinâmica, em vez de aprender o JavaScript adequadamente.

Outra pergunta para os oponentes da digitação dinâmica é que, se a digitação estática é tão boa, por que ainda estamos encontrando erros no código escrito em Java e C #? Sim, podemos detectar esses erros na fase de compilação, mas sejamos honestos, isso não é suficiente. Devemos seguir os princípios do SOLID e outras práticas recomendadas para garantir um código de qualidade. E novamente - isso se aplica mais aos conhecimentos e qualificações dos programadores do que à linguagem de programação.

O código TypeScript é mais fácil de ler?

Aqui estão 2 exemplos de Redux Thunk:

const getUsers = async dispatch => { //... try { const users = await APIService.get('/users') dispatch(successGetUsers(users)) } catch(err) { dispatch(failedGetUsers(err)) } } 

e o mesmo no TypeScript:

 const getUsers = (): ThunkAction<void, {}, {}, AnyAction> => async (dispatch: ThunkDispatch<{}, {}, AnyAction>) => { //... try { const users: User[] = await APIService.get('/users') dispatch(successGetUsers(users)) } catch(err) { dispatch(failedGetUsers(err)) } } 

O que significam todos esses genéricos? Por que existem 2 objetos vazios neles? Quanto tempo devemos gastar lendo a documentação para descobrir tudo? Bem, isso ainda é normal para o Redux Thunk, como é um middleware muito popular para o Redux, eles têm uma excelente equipe de suporte e documentação. Mas e se tivermos que manter um código que não tenha tudo isso?

Não haverá mais erros sutis?

No exemplo anterior, você viu como o TypeScript torna o código mais detalhado. Como você sabe, quanto maior e mais complexo o sistema, maior a probabilidade de erro. Além dos erros que poderíamos cometer no código JavaScript, devemos também tomar cuidado para não cometer erros de digitação nas interfaces, erros nos genéricos etc. Para ser justo, vale a pena notar que o compilador o ajudará a encontrar e corrigir rapidamente esses erros, mas sem o TypeScript, não os teríamos encontrado.

Seguindo as melhores práticas de OOP

Como sabemos, devemos seguir as práticas recomendadas se queremos escrever código de alta qualidade, facilmente escalável e sustentável. E o TypeScript pode nos ajudar com isso. Isso parece ótimo, vamos ver um exemplo do Express:

userRoute.js

 router.get('/users', (req, res) => { //get users from DB res.json(users) }) router.post('/users', (req, res) => { //create user res.json(userCreated) }) 

userRoute.ts

 class UserRouter { public router = express.Router() public address = '/users' constructor() { this.initRoutes() } initRoutes() { this.router.get(this.address, this.getUsers) this.router.post(this.addressm this.createUser) } getUsers(req: express.Request, res: express.Response) { //get users from DB res.json(users) } createUser(req: express.Request, res: express.Response) { //create user res.json(userCreated) } } 

A primeira coisa que chama sua atenção é que mais código está sendo escrito novamente. Usamos classes para escrever no estilo OOP. Teremos que instanciar essas classes. Além disso, podemos usar interfaces, tipos estáticos e outras construções. E para que tudo isso não se transforme em caos completo, não temos escolha a não ser usar as melhores práticas. E é assim que se chama: "encorajando os desenvolvedores a usar as melhores práticas de POO" .

Quando os desenvolvedores votaram em linguagens simples, flexíveis e dinâmicas, como JavaScript e Python, quando o paradigma de programação funcional mostrou suas vantagens e a capacidade de resolver alguns problemas de maneira mais elegante e eficiente (e em JavaScript, podemos usar as duas abordagens), o TypeScript nos leva a escrever código à moda antiga, no estilo OOP Java e C #.

Para resumir, vimos que o TypeScript não economiza muito tempo, nem nos protege de um grande número de bugs, nem aumenta nossa produtividade. Além disso, requer a criação de mais código, configuração adicional, arquivos de definição de tipo e perda de tempo lendo a documentação adicional. Um novato provavelmente escreverá, talvez não seja um aplicativo ideal, mas funcionando em JavaScript ou Ruby, enquanto escreveremos um excelente aplicativo TypeScript de acordo com todos os princípios. E então ele nos contratará para reescrever sua inicialização, onde podemos usar o TypeScript para fazer tudo certo.

É divertido ver como linguagens massivas, verbosas e complicadas desaparecem, incapazes de resistir à competição com outras mais dinâmicas e simples, e depois as últimas abandonam tudo o que as ajudou a se desenvolver tão rapidamente e se esforçam para se tornarem mais pesadas, mais verbais e mais complicadas.

Eu vejo assim:

Ok, não queremos mais Java, queremos JavaScript. Mas não gostamos de JavaScript, então vamos torná-lo um pouco mais parecido com Java. Ótimo, agora temos tudo o que estava em Java, e isso não é Java. Vamos lá!