Aqui está a questão: os desenvolvedores front-end devem tratar as soluções no-code como seus aliados.

Esse debate interminável de código vs. no-code não leva a lugar nenhum. A melhor solução é combinar os dois.

E para isso, precisamos de um sistema de blocos para o conteúdo.

O cenário atual

Atualmente, as startups têm duas opções:

• Criando seu site em uma plataforma no-code como o Webflow
• Ou codificando seu site do zero

A primeira pode levar a colocar seu site lá fora mais rápido, mas você dependerá da plataforma escolhida. Isso significa que você pagará o preço que eles escolherem e construirá em torno das restrições impostas por eles.

A segunda opção te dá total liberdade. Você pode criar literalmente qualquer coisa que quiser. Mas a flexibilidade total significa que você precisará de mais tempo para colocar seu site em funcionamento.

Para ser honesto, nenhuma dessas opções é perfeita. Mas isso não é um problema do no-code. Afinal, o interesse no no-code tem crescido consistentemente ao longo dos anos. O problema está na forma como o no-code se incorpora ao restante do nosso trabalho.

É por isso que propomos um meio-termo: uma combinação dos dois, que se adequará a tantos casos de uso quanto possível.

Fundindo código e no-code

Para misturá-los, precisamos mudar a forma como o no-code se incorpora à web.

A principal razão pela qual a escolha entre código e no-code é tão binária é que as ferramentas no-code não são tão flexíveis. As maiores plataformas no-code do mercado te obrigam a usá-las como um todo: você não pode apenas construir algumas páginas de destino em seu próprio domínio, e você não pode estilizar rapidamente uma parte de uma página e incorporá-la em um código existente.

A flexibilidade do no-code é na verdade uma ilusão.

Dê uma olhada nas plataformas no-code mais populares. Nenhuma delas oferece a flexibilidade de fundir código e no-code.

Glide, Bubble, Webflow, Airtable, Softr - todos eles te forçam a seguir a estrutura de conteúdo deles.

Para misturar ambas as abordagens - e assim permitir que desenvolvedores front-end aproveitem a velocidade de trabalhar com no-code - devemos permitir que o no-code seja incorporado ao código existente, liberando os desenvolvedores de tarefas repetitivas e fornecendo ferramentas para enviar mais rápido.

Uma abordagem baseada em blocos para o no-code

Nos deparamos com esse problema e foi assim que começamos com o Notice.

Em vez de forçar os usuários a escolherem entre "código" e "no-code", permitimos que os desenvolvedores incorporem componentes em seu código, como FAQs, Vagas de Emprego, Postagens de Blog ou qualquer outra coisa que desejarem.

Depois que o código é colado, qualquer pessoa da equipe pode entrar no Editor do Notice e fazer as alterações que quiser. Mudanças de estilo, nova estrutura, cópia atualizada - qualquer coisa.

Para dar um caso de uso prático:

Imagine que o Gerente de Marketing quer incluir um FAQ em uma das páginas de destino. Eles te chamam no Slack.

Você obtém o texto, a estrutura, o estilo - tudo o que você precisa para começar. Mas em vez de codificar isso na página, tudo o que você precisa fazer é colar uma linha de código na página. Depois disso, você ou qualquer pessoa da equipe pode ir para o editor de Notas e alterar o estilo e o texto. É a flexibilidade e velocidade do no-code combinadas com o código existente!

Agora compare essa abordagem com as outras duas que descrevemos inicialmente:

Para começar, você não seria capaz de incorporar apenas um FAQ em sua página usando as ferramentas no-code atuais. Ponto final.

E se você quisesse codificar isso, você gastaria uma quantidade infinitamente maior de tempo. Sem mencionar que qualquer atualização no futuro significaria que você precisaria sair do seu fluxo de trabalho para implementá-las.

É hora de misturar o melhor dos dois mundos

Esse debate interminável deve acabar.

A resposta está no meio - incorporando ferramentas no-code em nossos fluxos de trabalho para que possamos trabalhar mais rápido e ter mais tempo livre para lidar com desafios complexos.