RawJS é uma maneira melhor de chamar document.createElement()
Uma nova biblioteca frontend chamada RawJS afirma ser uma forma leve e mais ergonômica de chamar `document.createElement()` e construir interfaces sem React ou um virtual DOM. Os comentadores criticam amplamente sua página inicial voltada para marketing, a falta de exemplos de código claros, a ergonomia estranha e a dependência de TypeScript e de uma estrutura de projeto pouco convencional, argumentando que ela não escala bem para apps complexos ou equipes em comparação com frameworks estabelecidos. Alguns apreciam o objetivo de minimizar dependências e ficar mais próximo do DOM, mas a maioria vê o RawJS como uma ferramenta de nicho ou experimental, em vez de um substituto prático para frameworks modernos como React, Vue ou Svelte.
Landing Page, Demo e Docs
- Muitos comentadores acharam a página de marketing vaga: sobretudo afirmações, poucos exemplos de código e posicionamento pouco claro.
- A demonstração ao vivo recebeu críticas por problemas de UX: spam no histórico ao usar o botão voltar, modais desajeitados (sem botão claro de fechar, problemas com o backdrop), tipografia enorme e uma sensação geral de “pouco polido”.
- Erros de digitação e um link confuso de “Check out Squares” para um repositório de exemplo (e não para o site principal) reduziram a confiança.
- Várias pessoas pediram um exemplo simples e canônico (por exemplo, um app TODO) e comparações lado a lado com React/jQuery/vanilla, à la “youmightnotneedjquery”.
Design da API e Ergonomia
- Os trechos de código compartilhados foram amplamente vistos como verbosos, imperativos e mais difíceis de ler do que tanto o jQuery quanto templates de frameworks.
- O estilo de sobrecarga de parâmetros (misturando strings, funções, helpers de eventos, attrs, arrays) foi visto como “mágico” e propenso a erros, contrariando o marketing de “sem mágica”.
- Escrever HTML e CSS por meio de chamadas de função em JS desanimou muitos que preferem templates ou HTML+CSS puro aprimorado por JS.
Posicionamento vs Frameworks e Vanilla JS
- Os apoiadores apreciaram a intenção: dependências mínimas, uso direto do DOM, sem virtual DOM e “DOM como estado”.
- Os críticos argumentaram que construir o DOM não é a parte difícil; o difícil é gerenciamento de estado e atualizações escaláveis, onde React/Vue/Svelte/Solid brilham.
- Vários acharam que o RawJS se parece com “jQuery com componentes” e não escalaria bem para apps grandes ou equipes.
- Outros apontaram que JSX + React já servem como um padrão de fato e que ferramentas mais simples como htmx, Hotwire, ArrowJS ou Vue puro talvez fossem preferíveis.
Build, Dependências e Módulos
- A mensagem do repositório de exemplo sobre “sem bundler/build” versus “TypeScript compila seu app” confundiu alguns; depois foi esclarecido como “sem webpack/rollup, só tsc”.
- A recomendação de usar apenas dependências hospedadas no jsdelivr e a piada sobre “programadores de npm install” geraram resistência, especialmente considerando as próprias dependências no estilo npm do projeto.
- A antipatia da biblioteca por módulos ES e listas de importação gerou debate; outros defenderam ESM e imports explícitos como prática padrão.
Afirmações, Desempenho e Escala
- Afirmações como “sem curva de aprendizado”, “sem mágica estranha”, “sem sobrecarga de performance”, “sem bugs conhecidos” e o uso de TypeScript enquanto é chamado de “RawJS” foram vistas como excessivamente confiantes ou enganosas.
- O sentimento geral foi cético: objetivos interessantes, mas exemplos fracos, UX rude, benefícios pouco claros em relação a bibliotecas existentes e dúvidas sobre viabilidade em frontends grandes e reais.