DEV Community: Ricardo Gouveia

Separating Logic from UI in React: A Comparison with Angular Services

Ricardo Gouveia — Tue, 20 May 2025 01:14:01 +0000

Angular developers are used to a well-defined flow for building features: typically, services act as a middle layer between business logic and UI.

In React, the architectural freedom makes this separation less explicit — which often leads to questions about where to place logic and how to keep it decoupled from visual concerns.

🔧 Angular Services: Organization Through Dependency Injection

Angular services are injectable classes with reusable logic. They're responsible for sharing state and behavior between components — such as authentication, HTTP calls, component communication, and more.

It's worth noting that this doesn’t eliminate the need for state management tools like
NgRx or Akita, which are used when an app demands more robust state handling.

Dependency injection makes services easily accessible across the application:

@Injectable({ providedIn: 'root' }) 
export class NotificationService { 
  show(message: string) {
    /* display toast */
  }
}

🌀 React: Architectural Diversity as a Feature

React doesn’t enforce a structure for separating logic from UI — which brings flexibility, but also responsibility. Teams need to define patterns that keep the codebase consistent.

Common approaches to separating logic in React include:

Headless Components (a.k.a. logic-only or controller components)
Custom Hooks
Context API
Declarative Composition
External Modules (like auth.ts, useUser.ts, etc.)

🧩 Example: Parent Provides Store Data to Child

Scenario: The Parent component extracts data from a store and passes it to Child via props. Child is completely decoupled from data sources, making it reusable anywhere in the app.

// Parent.tsx
import { useUserStore } from './stores/useUserStore';
import { Child } from './Child';

export function Parent() {
  const { user } = useUserStore();

  if (!user) return null; // or a spinner

  return <Child name={user.name} />;
}

// Child.tsx
export function Child({ name }: Props) {
  return <p>Hello, {name}!</p>;
}

// App.tsx
import { Parent } from './Parent';

export default function App() {
  return (
    <main>
      <h1>Headless Component Example</h1>
      <Parent />
    </main>
  );
}

Benefits of This Pattern:

Child is pure, testable, and reusable.
Parent acts as a logic adapter, fetching store data and injecting it into children.
Logic is separated from UI, supporting scalability.

⚖️ Angular Services × React Patterns: A Direct Comparison

💡 Headless Components: Components that render nothing but execute logic or handle side effects.

Declarative, reusable, and live inside the JSX tree. They're like "visible services" in React, organizing logic outside of UI rendering.

function AnalyticsTracker() {
  useEffect(() => {
    trackPageView();
  }, []);
  return null;
}

🪝 Custom Hooks: Functions that encapsulate reusable logic based on React hooks.

Extract business rules (e.g., async calls, validations), improving testability and reuse across components.

function useAuth() {
  const [user, setUser] = useState(null);
  useEffect(() => {
    // fetch user data
  }, []);
  return { user };
}

🌐 Context API: React’s built-in solution for sharing data without prop drilling.

Great for themes, authentication, language, or global events. Combined with hooks, behaves like a mini store.


const UserContext = createContext(null);
function useUser() {
  return useContext(UserContext);
}

🧱 Declarative Composition: Controls logic and behavior via JSX components instead of scattered if or switch statements.

<When condition={user.isAdmin}>
  <AdminPanel />
</When>

Makes UI more readable and component-driven, replacing complex conditionals with declarative expressions.

✅ Final Thoughts

React doesn’t require you to separate UI and logic — but doing so makes your code more scalable, testable, and maintainable.

Headless components and custom hooks are powerful ways to encapsulate logic without compromising presentation. They align well with React’s declarative and compositional model.

Even if not always reusable, these patterns keep child components flexible and ready to work with different data sources or contexts.

In the end, the absence of Angular-like services in React isn't a limitation — it's an opportunity to
build architecture tailored to your application’s needs.

Community as a Signal for Companies

Ricardo Gouveia — Fri, 07 Jun 2024 11:13:45 +0000

This text is meant to stir debate and is totally open to comments — including disagreements. But after hearing “frontend is going to die” so many times, nothing really shakes us anymore...

In this (very gradual) return to in-person activities — at least the ones that make sense to be or have the option to be in-person — I’ve also been getting back into attending meetups and events, and reviving my routine of creating content.

This specific article is something I started conceptualizing back in 2021, but I never moved past the research phase (especially since it’s largely based on personal opinion and experience). And honestly, that delay turned out to be a good thing, because my conclusions have evolved since I first came up with the idea.

What I Mean by “Community”

Very similar to the idea of a shared convention, what I mean by “community” here is the group of people in tech who gather at events, meetups, groups, and other interactive spaces to exchange knowledge, network, and so on.

This is one of the activities that’s been regaining momentum in the return to in-person spaces — and it makes total sense to me. Personally, sometimes I get “screen fatigue” from work, and an in-person event is what motivates me to keep investing time in software topics, even on weekends.

Dev.to itself is a kind of community, especially when you look at posts in the form of questions or discussions, which are mainly meant to engage and interact.

I’ve always been connected to community. I got into frontend thanks to a local developer group where I used to live, and today I participate in communities that discuss the technologies I work (or have worked) with, mostly around São Paulo.

Even though I deliberately distanced myself from the community during the pandemic — mainly due to screen fatigue and all-remote events, as I mentioned — I still consider it an important part of a dev’s career. It’s not impossible to become a good developer without community — after all, there are many paths to success in life — but I would definitely point to it as a smoother road.

Community and Companies

Tech communities and companies have been intertwined for a long time. This became especially obvious in the 2010s during the startup boom. Tech events were even satirized in episodes of HBO’s Silicon Valley (which, if you haven’t seen, I highly recommend — it’s worth enduring the secondhand embarrassment from some absolutely absurd yet painfully real situations, both past and present).

Companies could offer event spaces inside their offices, sponsor meetups and post job openings there, or encourage their developers to speak at events, among other things.

In return, events could attract the kinds of professionals companies were looking for, and also inspire devs to explore new technologies, methodologies, and technical solutions for the problems they were tackling at work.

Just like not all devs participate in community, not all companies do either. And there are also companies that host their own tech events, but don’t necessarily participate in, support, or encourage their employees to attend external ones. Some companies simply ignore the dev community altogether.

Motivated Absence

Every rule has its exceptions, and here there are probably more than just one. But this is a connection I’ve noticed: some companies don’t support their employees’ participation in tech events because of their high turnover rates.

For these companies, if an employee gets involved in a community filled with companies hunting for talent — and lots of people talking openly about the advantages of their jobs — that employee can easily jump to a better opportunity or one that aligns more with their personal goals.

Not all companies that stay away from community do so for this reason, but I believe the so-called “stepping stone companies” (where people go mostly to gain experience before moving on) avoid community involvement precisely to keep employees around longer.

Conclusion

This connection became clear to me as I reflected on some past work experiences, and also through conversations with colleagues — asking them how familiar they were with software communities, and how often they were exposed to these topics, whether through institutional communication or their own coworkers (your immediate circle says a lot about the place you’re in).

Another takeaway I had was this: community and events can also help you understand the fair value of your work. If you go to an event and meet people in your field who are giving talks, making the most of their income, and willing to discuss salary ranges and benefits from where they work, you can reflect on whether you’re being compensated fairly — even if your company doesn’t have an open internal salary policy.

Today, I’m happy working at a company where, every time I go to an event, I meet people who already know or have heard about the company’s pioneering initiatives, diversity, inclusion, and support for communities and events. More and more, attending events shows me that companies that compensate fairly, support, and encourage their employees to grow have much more to gain — not lose — when their people participate in tech discussion groups.

Front-End Beyond the Web

Ricardo Gouveia — Sun, 02 May 2021 18:20:45 +0000

Countless articles discuss the time when the world stopped having "webmasters" and started having "front-end," "back-end," "DBAs," "DevOps," and others. This shift has spread from small startups to tech giants.

The specialization of professions is an old trend. I remember reading about it back in elementary school, studying the industrial revolution. It’s natural that, when aiming to create a richer web experience with more interactions, more effort, interdisciplinarity, and specialization will be required from those building it.

What is front-end, really?

According to Wikipedia:

Front-end web development is the development of the graphical user interface of a website through the use of HTML, CSS, and JavaScript so users can view and interact with that website.

View on Wikipedia>

The definition is not available in Portuguese. In a free translation: "Front-end web development is the practice of converting data into a graphical interface through the use of HTML, CSS, and JavaScript so that users can view and interact with that data."

It’s important to note this refers to web front-end development. If we want to understand what front-end truly is, we need to look at another definition:

Em ciência da computação, front-end, interface frontal ou parte frontal e back-end, parte secundária, parte de suporte ou parte de retaguarda são termos generalizados que se referem às etapas inicial e final de um processo. O front-end é responsável por coligir a entrada do usuário em várias formas e processá-la para adequá-la a uma especificação em que o back-end a possa utilizar.

View on Wikipedia>

In general terms, front-end is what obtains and preprocesses the data that will be sent to the back-end. And here’s where the reflection begins: there are many other ways to get user data that differ from applications made with HTML, CSS, and JS.

User interaction

// Detect dark theme var iframe = document.getElementById('tweet-1380221812139814913-160'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1380221812139814913&theme=dark" }

I’ve had this idea for a few years, and I posted this summarized reflection on Twitter, which received some feedback. Based on that, I can propose and explain a new term, building on the previous definition:

~~Web~~ front-end development: is the practice of converting data into an interface ~~graphical, through the use of HTML, CSS, and JavaScript,~~ so users can view and interact with that data.

With this definition, we don’t change the role of a web front-end developer, but we broaden the front-end field to new possibilities of user interaction. Back to the Twitter discussion, here are some possibilities to consider:

- Mobile app development

App development for smartphones has basically become its own field, gaining solid ground with smart operating systems like iOS and Android.

However, the output of this kind of development still considers many front-end concepts: it interacts with users, presents an interface (not just graphical), and collects and preprocesses data before sending it to a server.

The similarities between mobile development and front-end go beyond concept: the many frameworks for building mobile apps using web-native languages (and their paradigms) create a technical correlation between these areas.

So, we can consider mobile development as a type of front-end.

- Personal assistants

This term might feel abstract, but it’s easier with examples: Amazon Alexa, Google Home, and Apple HomePod.

Here, we abstract the graphical aspect even more: the interface is primarily audio. However, the user still interacts with the device, which needs to connect to a server to process data.

Without a doubt, personal assistants — whether devices or apps — are a kind of front-end.

- IoT / SmartWatches / SmartBands / Wearables

The broad category of the Internet of Things (IoT) is mostly made up of devices that can be classified as front-end systems.

In the two most popular examples: both the Apple Watch and MiBand rely on a smartphone to function (totally or partially) and have their data processed and/or stored by servers outside the user’s domain.

Beyond wearables, a large group of smart home devices connects to servers for basic functions. They all have sensors that interact with the user (or with the environment, which the user modifies, making it an indirect interaction) to gather information and execute actions. Many of these devices don’t have screens.

Front-end beyond the Web

The front-end’s dependence on screens is still strong, and that’s not a problem — it’s just a reflection of the world we live in today. However, we should notice the small signs showing that users no longer depend so much on isolated devices; one such sign is the drop in PC sales and the rise in tablet sales.

I still fully agree when I hear someone say the foundation for studying front-end is HTML, CSS, and JS. It still makes no sense to jump to a broader context for someone simply seeking the basics.

But for people who already have solid knowledge of these technologies, it’s worth being a bit more conceptual and reflecting on the future of human-computer interaction (which might not even be so "computer" anymore). This change isn’t going to happen — it’s already happening.

We’ll need UX professionals to shape, design, and test how users interact with these devices (and they’ll also face a big adaptation), and we’ll need developers to build the technical solutions that enable the intended interaction.

This text is deeply related to an old controversy about the "end of front-end." Maybe that was the motivation behind my reflection. But anyway, my intention is not to provoke those who gave this prediction, but to present another alternative — not an end, but an evolution of the field.

If this text made you think, contribute to it in the comments. It’s more of an introduction than a conclusion.

Nobody Can Tell You How Long It Takes to Become a “Dev”

Ricardo Gouveia — Sat, 27 Jun 2020 12:06:35 +0000

Cover photo by Annie Spratt on Unsplash

Even though I’m not from the era of webmasters, I know that at least since 2012 there have been courses promising super-fast training to turn you into a developer. This isn’t exclusive to front-end either — back in college, there was a joke about a video called “Learn C in 5 hours.”

The problem is when nobody warns you not to take that seriously.

Photo by Thought Catalog on Unsplash

The Problem with Learning

Learning is a subjective concept. Especially for me — I’m not a teacher — I can only talk about what works for me. But there’s generally some agreement among educators that everyone has their own optimized learning style.

A course using Method A might work great for Person 1 but poorly for Person 2. A course using Method B might be the opposite. Person C might do well with both, and Person D with neither. Even without digging into academic research, I can give a practical example: on the official React site — the front-end library — on their tutorial page, there’s a box saying you can follow two paths: one for people who learn by doing, and one for people who prefer a “bottom-up” conceptual approach. That already points to at least two different learning styles. The last suggestion, that both paths complement each other, might even hint at a third method: combining the two at the same time.

All this “theory” — if we can call it that — boils down to this: content creators who make courses or tutorials only control how long their course lasts. They might estimate how much practice time you’ll need beyond the lessons, to estimate total effort. The problem is that this estimate doesn’t take into account different learning styles, so it only makes sense if your personal method exactly fits the course’s approach. In my experience, that rarely happens.

Never try to twist your learning style to fit a course or content. It’s often impossible, and if it is possible, it will require a huge effort — and when you look for another resource, you might try to do the same again. That’s a recipe for slowing down your progress. I’m not saying you shouldn’t optimize your learning: if a tip improves your process, go for it. But if something isn’t working after a reasonable effort, switch. Today we have endless sources of knowledge, especially in development. Don’t get stuck.

This also applies to this post. If you don’t get what I mean here, ask me to explain it differently. If that still doesn’t work, find other sources or talk to others. You don’t even have to finish reading, or you can come back later when it might make more sense.

The Problem of “Leveling Up”

Photo by Isaac Smith on Unsplash

Besides the problem of learning, there’s the problem of leveling up: at what point in the journey of learning programming is a person considered a developer? There’s no agreement.

Some courses and bootcamps leverage this ambiguity — sometimes even against learners. This doesn’t stop you from learning, but it creates false expectations. You don’t develop a “developer mindset” just by finishing a course. You gain more technical knowledge. Is that enough to be a developer?

We can argue about what counts as “enough” for a developer: is just knowing how to make a webpage enough? Okay, but do you have to build it from scratch or can you use frameworks? Does it just have to work, or should it meet performance benchmarks like Lighthouse? Do you need to know accessibility at this stage? Is knowing HTML/CSS/JS enough, or do you also have to know concepts that apply to mobile apps (like notification APIs or phone features)? Should you understand UI/UX to spot issues? And what about soft skills?

There are a lot of questions. If some of these are mandatory, I wouldn’t call myself a dev.

For companies, they might require some amount of experience before hiring you as a dev. That makes the course-to-dev connection even less direct. Other companies might hire you with little experience and train you during onboarding, making outside courses optional.

The point is: there is no single moment when someone “becomes” a developer. It doesn’t exist. A person gradually acquires developer skills, might get a job in the field, and keeps learning. They didn’t “become” a dev the moment they got hired, because you can be a dev as a hobby and never work professionally. It’s not finishing course X or Y, because you might learn other ways or even without formal learning and still build a product that meets many requirements.

Lots of Advice, Few Final Words

Photo by AllGo - An App For Plus Size People on Unsplash

I’ve laid out a lot of questions about who is or isn’t a dev. If you’re just starting out, don’t panic. That’s not my goal. I want to protect you from thinking a course is “mandatory” just because everyone you know took it, or that those who did are somehow better or will get what they want faster.

The other extreme is dangerous too: yes, no one can promise you’ll be a dev in a week. But there are trusted resources recommended by established people and companies, with estimated timelines to master topics. Again: estimates, not guarantees. You should be open to advice from people who agree there are many paths to the same goal. Avoid advice from those selling you something or offering a “revolutionary” one-size-fits-all path — that just doesn’t exist.

My recommendations for beginners wondering “am I really a dev?” are three:

Read the Front-end Handbook: you don’t need to read it all. It’s not a technical book but a great summary of the front-end profession, technologies, what you need to apply for jobs, and where to find knowledge. It’s suggestive and updated yearly (although 2020 wasn’t released, the 2019 version is still relevant).
Follow the front-end developer roadmap: updated every year, it shows technologies and how they fit into a journey. I don’t know everything there — neither do most devs, because it’s not necessary — but it’s great for beginners to have some order and context.
Use the front-end web developer learning path on MDN: despite the tagline saying it teaches you everything to become a dev, I disagree. It teaches you how to build simple pages based on solid fundamentals you can apply in any framework — which is essential. MDN is my daily dev reference. Their descriptions are concise, designed for quick reference, not official docs.

I already recommended the Front-end Handbook back in 2018 in a post of mine here. The other sources are newer or I discovered them later. I’m always looking for solid, renewable sources to recommend.

There are YouTube channels, courses, articles, and dev.to posts that will be very positive for your career. During and after your initial process, build the habit of accessing these sources to learn more and share knowledge. Never stop learning.

And don’t make this post your only source. Talk to other people, share your thoughts. I want to hear your opinion!

Minha Stack Pessoal - Parte 1: Introdução

Ricardo Gouveia — Wed, 06 May 2020 12:26:59 +0000

Esse é o primeiro de uma série de 4 (ou mais, ainda está incerto) artigos que pretendo escrever sobre a stack que estou utilizando para meus produtos pessoais e como essas escolhas influenciam meu caminho como desenvolvedor.

Esses artigos são meramente coleções de opiniões e experiências pessoais. Posso estar utilizando ferramentas de maneira não ideal, e já seria extremamente útil de um relato aqui provocasse uma discussão de modo que eu aprendesse um outro modo de fazer algo que já fiz.

Anteriormente

O meu site pessoal não é novo. Na verdade hoje ele está na versão 4.1. Eu mantenho o código das versões anteriores em uma pasta no google drive onde posso executa-lo rapidamente por razões nostálgicas.

Na primeira versão do site, eu utilizei o Grunt, o primeiro task runner em que consegui fazer um conjunto de scripts que considerei realmente útil. Nesse script eu criei rotinas para compilar Sass e Pug, minificar HTML e CSS, comprimir imagens e usar live-reloading no browser. Fiquei tão feliz com o resultado que abstrai essa configuração do Grunt para um "boilerplate" para usar em outros projetos. Durante muito tempo qualquer coisa nova que eu criava em geral começava com um clone desse projeto.

Não lembro exatamente o que provocou a mudança, mas lembro que comecei a perceber que muitos estavam falando que o Gulp era melhor que o Grunt, e começaram a migrar de plataforma. Não me senti bem com isso, eu estava feliz com o Grunt, e quando tentei migrar para o Gulp, falhei nas primeiras tentativas já que a sintaxe de arrow function não fazia nenhum sentido pra mim na época.

Na terceira tentativa consegui construir um script que fazia tudo o que seu predecessor, em Grunt, fazia também. Novamente, esse script virou um "boilerplate", e a versão 2.x do meu site foi feita com ele.

Passei mais tempo utilizando a versão do Gulp do que a do Grunt. Nesse meio tempo, acabei desenvolvendo a versão 3.x do meu site. Também fiz uma versão em NPM Scripts das rotinas do task runner, para evitar que eu fosse impedido de usar alguma tecnologia por perda de suporte de plugin para o Gulp. A versão pura em NPM até ficou pronta, mas achei lenta e nunca utilizei para nenhum projeto. Também tentei fazer algo em Webpack, mas não consegui. Hoje entendo que talvez tenha sido um erro tentar usar o Webpack pra isso.

Breakpoints

A versão do boilerplate do Gulp passou tanto tempo sendo minha principal base para novos projetos pessoais e até profissionais pq ela funcionava. Quando me mudei para São Paulo no início de 2019, trabalhei em uma empresa que não tinha uma stack definida para os produtos que precisavam ser feitos. Apresentei esse boilerplate para o (único) outro dev da equipe e ele foi usado até mesmo em projetos que estão em produção até hoje.

Nessa época, eu me culpava por não saber um framework JS. Falhei todas as vezes que tentei aprender um. Li vários artigos sobre curvas de aprendizados, comparando Vue.js, React e Angular. Eu sempre pensava que não tinha um projeto que necessitasse de um framework JS, e a idéia de fazer uma aplicação de pizzaria fake só pra aprender não me agradava, porque aquilo simplesmente não tinha sentido em existir, por menor que fosse. Eu queria fazer um projeto que pudesse descobrir algo novo no framework, chegar em casa e já implementar, ou seja: evoluir a aplicação - e ter um motivo para fazer isso.

Pouco tempo depois, troquei de emprego. Foi a primeira vez que fui trabalhar numa empresa grande e de tecnologia. Tive um treinamento de uma semana de Angular e comecei a trabalhar num projeto que estava em produção. Tive muita dificuldade, mas aprendi mais do que jamais antes na vida, tanto sobre JS quanto sobre Angular, e também sobre todo o ambiente e metodologia ágil de desenvolvimento de software.

Alguns meses depois, resolvi tentar mudar a base do meu site para Vue. A decisão foi simples: eu já trabalhava com Angular, então não precisava de algo pra praticar; eu não entendia a sintaxe do React, e Vue parecia uma novidade interessante.

Atualmente

Hoje, eu tenho 3 produtos pessoais principais:

RCRD: o meu site onde falo sobre mim, mostro um pouco dos meus trabalhos, experimentos e posts, e tenho um form de contato. É feito em Vue.
RCRD Portfolio: uma lista de jobs que fiz, até bem desatualizada. É feito em Angular.
RCRD Labs: uma lista de experimentos que fiz. É feito em React.

Estou tentando achar uma boa idéia para construir em Svelte. Um projeto em React Native está nos planejamentos.

Também tenho uma API que alimenta esses e outros produtos, mas ela e os outros não entram no que chamo de stack pessoal.

Nos artigo seguinte vou discutir sobre minha experiência migrando o meu site de Gulp para Vue, e como meus conhecimentos recem adquiridos em Angular me ajudaram a finalmente fazer algo usando um framework sozinho.

É importante falar que minha decisão de usar frameworks diferentes não tem nada a ver com o conceito de micro front-ends. Eu uso diferentes frameworks para que eu tenha uma base de conhecimento em cada um deles. A integração entre eles não é mais forte de que a de dois sites em HTML puro ligados por um link. Eu lido com eles como produtos separados.

Obrigado pela leitura! Sinta-se a vontade para comentar sua experiência de aprendizado de frameworks e front-end em geral!

Adeus Medium. Olá DEV Community

Ricardo Gouveia — Sat, 11 Jan 2020 19:36:02 +0000

Esse texto é a continuidade do meu último texto na plataforma Medium.

Nos últimos meses passei pela experiência de desenvolver uma aplicação de tecnologia e ambiente onde não estou totalmente acostumado, e sem ter acesso a internet externa. Sucintamente: foi horrível.

Não era necessário ter passado por isso para que eu já tivesse consciência da importância de compartilhar conhecimento na comunidade de desenvolvedores, mas certamente evidenciou a falta que faz ter respostas "a um google de distância".

Não é mais um tema tão recente de que o Medium está aplicando a política de Paywall para não assinantes. Eu pessoalmente não li em detalhes que ações específicas a plataforma está tomando, mais vi várias pessoas no Twitter postando prints de alertas sobre "cota mensal de leitura", algo bem semelhante a sites de notícias de revistas atualmente.

A empresa é livre para determinar como quer ganhar com o seu serviço - que de maneira nenhuma é ruim, e por isso meu conteúdo esteve lá por anos. Mas a decisão de cobrar por conteúdo desencaixou a empresa das necessidades da nossa comunidade, na minha opinião.

Temos uma comunidade que já quebrou alguns padrões, se por assim dizer, que nos fez ser pessoas e profissionais melhores. O abandono da noção de que ajudar alguém e ajudar a concorrência é o que mais me orgulha desse grupo. E por mais que essa noção ainda exista na profissão, quanto mais pessoas se engajarem e meetups, eventos, grupos e discussões onde estivermos, mais vão deixar de acreditar nessa ideia, e vamos evoluir juntos.

Contrariando a opinião de alguns de que a quebra dos devs com o Medium é o momento perfeito para abrir um blog com sistema de posts, eu acredito que a comunidade DEV tem potencial para ser o substituto perfeito do Medium, em especial nas features de interatividade que blogs isolados não podem prover.

É importante dizer que nunca recebi nenhum comunicado do Medium de que meu conteúdo estava sob paywall, nem de ninguém falando que não conseguiu acessar algo que tenha produzido e disponibilizado lá. Pelo contrário, como autor, meus posts aparecem lá, para mim, com um aviso de que não estão dentro da política de paywall.

Ainda assim, não acho que vale a pena investigar se isso realmente quer dizer que essa política não afeta o meu conteúdo; até porque a empresa pode mudar isso quando quiser. Fazer uso de uma plataforma que acredita no compartilhamento de conteúdo da mesma maneira que nós é muito mais vantajoso.

Estou como sempre aberto aos comentários sobre essa discussão. E recomendo a leitura do texto do @ben sobre como o objetivo do Medium jamais foi atingir nossa comunidade da maneira em que produzimos e compartilhamos, e por isso, ele na verdade não está fazendo nada de errado (em inglês).

User Agent Style Sheet: o porquê de um CSS que só serve para ser sobrescrito

Ricardo Gouveia — Sat, 11 Jan 2020 18:32:54 +0000

Numa manhã onde eu estava no meu horário mais reflexivo — quando é muito tarde para voltar a dormir, e muito cedo para começar a se arrumar para o trabalho — eu vi o tweet da Ire Aderinokun com uma enquete sobre o método que utilizávamos para resetar CSS.

Me veio na cabeça a pergunta: pra quê serve aquele CSS que o browser por padrão aplica em certos elementos HTML quando não se utiliza um CSS Reset e nem um estilo próprio que o sobrescreva?

User Agent Style Sheet: uma história

Photo by Marcus Loke on Unsplash

Resumidamente, o UA (abreviação para User Agent) é descrito, na especificação do CSS1, explicando que cada navegador deve em cada browser conter um estilo mínimo a ser aplicado a cada elemento HTML. Já as espeficicações CSS2 e CSS3 acrescentam que a aparência dos elementos quando estilizados pelo UA do navegador devem ser genéricas e "satisfazer expectativas da apresentação documento". A explicação do Jens Oliver Meiert é mais detalhada a respeito da evolução do UA.

Se pensarmos no inicio da Web, com seu intuito único de transferência de conhecimento acadêmico, então faz todo sentido a existência de um UA, já que certamente todo o poder do CSS3 seria desnecessário só para esta tarefa. Naquela época, a Web era como se fosse um LaTeX com opções de compartilhamento.

Ainda hoje, essa utilidade de manter um estilo básico para cada elemento não é totalmente inútil. Se o arquivo CSS não carregar, é bom que o browser saiba mais ou menos onde "jogar" cada coisa. Se ele não soubesse que o H1 deva ser um bloco com margem superior e inferior, título e parágrafo iriam parecer um código minificado.

Resumindo: a utilidade desse estilo é se manter como a ultima tentativa do browser para manter a legibilidade do conteúdo.

Tempos modernos

Photo by Agnieszka Boeske on Unsplash

Eu me lembro que no meu primeiro curso de HTML, em 2010, o professor explicou que o browser já aplicava um certo "estilo" no HTML. Mas a explicação se limitou a isso, e ao fato de que deveríamos nos livrar desse estilo para prosseguir, e como fazer isso com um reset.

No início da curva de aprendizado, não parece uma coisa sensata questionar o professor sobre isso. O arquivo de reset é pequeno (do ponto de vista do aluno que ainda não saber que cada KB conta, e muito!) e se você não tiver muito conhecimento em CSS e quiser tentar fazer algo sem ele, nada — literalmente NADA — parece funcionar direito.

Outro ponto para chamar atenção é que o estilo aplicado pelo UA não é padronizado. Existe uma sugestão de como deve ser esse código pela W3C (e parte do estilo aplicado é simplesmente os valores padrões das propriedades CSS) mas a não ser por isso, a descrição do seu papel é aberta o suficiente para que cada browser implemente sua maneira de manter ordem no caos (e nessa parte, eu tenho que dizer que estaria um pouco interessado em um browser estilizar uma página automaticamente com flexbox ou grid, mesmo sabendo das consequências).

A diversidade de browsers—diretamente ligada a das empresas que os desenvolvem e ainda consequentemente a todo ecossistema das empresas de TI — é importante. A minha sugestão de padronização se limita ao UA, e não aos browsers e suas engines.

Em meio a benefícios e malefícios, a guerra dos browsers está com cada vez menos competidores (do ponto de vista de engines). Ninguém mais quer escrever uma engine do zero. E talvez nem deva, já que as que temos hoje são resultados de anos de evoluções.

O problema é quando o browser traz, sem direito de escolha, algo com potencial de destruir a tão cuidadosamente planejada experiência do usuário, e ainda esse algo tem um comportamento de certa forma imprevisível.

O que o futuro poderia nos trazer

Photo by Lucrezia Carnelos on Unsplash

Você compra um apartamento muito caro, na beira mar, no melhor bairro de uma cidade muito boa. Ele tem piscina, academia, porteiro e vários elevadores. Ele também tem uma suíte com a melhor vista do prédio.

Só que nessa suíte tem uma lâmpada incandescente que não tem interruptor, e já vem ligada. A vantagem é que ela não desliga quando falta energia. E você pode, se quiser, quebrar a parede e colocar um interruptor.

Eu realmente não entendo porque browsers, ou o próprio HTML, não trazem ferramentas que resetam o CSS padrão. Antes, me fazia sentido quando os esforços da W3C eram em tags genéricas. Mas hoje, temos equipes analisando a demanda da web e sugerindo tags com base nisso. A recente adição da tag *dialog* é prova disso.

A existência de muitos métodos de sobrescrever o UA pode ser um empecilho a inserção de algo com essa função nos browsers. Mas como a antiga forma de trabalhar mandava, eu sempre imagino que um atributo initial-state="reset" na tag link poderia ativar um reset básico, e quem quisesse algo mais como um normalize, que inserisse um arquivo como fazemos hoje.

Como a Front-end Week SP 2018 me ensinou que, na edição de 2017, eu fiz tudo errado

Ricardo Gouveia — Sat, 11 Jan 2020 18:28:31 +0000

Posts sobre a experiência dos participantes da front-end week nunca são demais. Além de participar de eventos incríveis, conhecer pessoas, aprender e se divertir, você ainda tem a chance de ver tudo aquilo de novo sob outra perspectiva.

Eu ainda estou arranjando palavras pra descrever como foi estar junto de um monte de gente que não me acha maluco quando faço piadinha com alinhamento vertical em CSS. Agora, minha dúvida é se sou normal, ou se achei loucos que se parecem comigo.

Para diferenciar um pouco dos outros, eu resolvi fazer o meu relato comparando com o do ano passado, em que eu também vim a front-end week.

All by myself

A foto ruim foi o de menos

Na edição de 2017, eu estava em São Paulo para participar tanto da FEW2017 quanto do CSBC 2017. Eu fui com uma amiga (que não é front-end mas é de computação) e eu estava começando a interagir com a comunidade pelo Twitter.

Os únicos eventos que participei foram o CSS SP meetup e o Front in Sampa. Não tenho do que reclamar de nenhum deles. Só elogios.

Por eu estar no inicio da minha interação da comunidade, eu não conhecia ninguém em especifico para conversar durante os eventos. E isso foi um grande erro: eu fui para um evento (de comunidade) do mesmo jeito que se vai para uma aula.

Conversei rapidamente com algumas pessoas, não fiquei pro after do CSS SP e nem fui pro Code in the Dark (ainda me sinto mal por isso). Assisti tudo bem quieto e voltei pro hotel.

De inicio não foi ruim. Foi a melhor experiência que tive até aquele momento. De certa forma, fiquei maravilhado com tudo. Inclusive com nomes famosos que vi passar perto de mim (não falei com eles também).

E no fim de tudo, voltei pra casa com muita vontade de vir novamente. Inicialmente, fazer tudo (errado) de novo.

Percebe, Ivair?

Bom, obviamente temos um ano de espera entre as edições. E durante esse ano, eu consegui fazer amizades da comunidade, online. Inclusive com algumas pessoas com que eu poderia ter falado naquela oportunidade que passou. Isso começou a me incomodar.

Resolvi contribuir com a edição desse ano. Falei com o Elvis Detona sobre uma proposta de layout para o site. Ele me respondeu e eu comecei a fazer. Eu estava tanto feliz por falar com alguém que admiro quando com medo de fazer código bosta pra um evento onde qualquer pessoa poderia fazer de maneira melhor (minha síndrome do impostor reinou nesse trecho).

Faltando 7 meses para a Front-end Week 2018 eu já tinha comprado meu ingresso para o Front in Sampa. Faltando 4, as passagens já estavam compradas e eu coloquei um contador no computador que indicava quantos dias, horas, minutos e segundos faltavam.

As vantagens de não ser invisível

Eu decidi que faria tudo diferente. Eu ainda não sabia se tinha feito tudo errado. Talvez fazendo tudo diferente as pessoas me achassem um sem noção querendo se enturmar. Mas eu resolvi arriscar para que minha experiência não caísse na mesmísse. O máximo que podia acontecer era eu virar meme.

Agir diferente significava conhecer pessoas. Incentivar elas a ir aos eventos que eu iria. Ir em mais eventos. Ir em todos os after possiveis, e interagir neles. Significava manter contato com pessoas que conheci na ocasião. E, quem sabe, até apresentar algo em algum evento (infelizmente não foi possível).

É bastante coisa pra alguém cujo um dia teve o lema: eu não gosto de gente. Mas se não for pra passar medo de interagir com as pessoas eu nem saio de casa.

Tudo saiu melhor do que eu planejava. Conheci pessoas incríveis e troquei idéia tanto sobre front quanto sobre outros assuntos. Bebi (o que eu geralmente não faço), dividi Uber e aprendi a ir de trem/metrô pra lugares que eu geralmente gastava bastante pra ir de carro.

O valor disso é imensurável. Acho que estamos sempre resignificando o que comunidade significa, mas dessa vez eu mudei totalmente meu conceito. E agora eu posso falar que eu amo essa comunidade!

Faça o que eu digo. E agora, o que eu faço

Esse texto ficou mais direcionado com a minha experiência de 2017. Se você participou da front-end week esse ano e ficou mais na sua, não perca tempo: comece a chamar todo mundo no twitter e se prepare para uma experiência muito melhor ano que vem! Vale a pena, mesmo se você tiver que ir de muito longe (nesse caso você ganha uma camisa!).

Fora isso, eu tenho muito a agradecer as pessoas que colaboraram para minha experiência na FEW2k18. Vocês são fodas! E a culpa de eu terminar esse post com outra aba vendo preço de passagem pra SP em 2019 é toda de vocês! ❤

O front-end vai mudar. Assim como todas as profissões e maneiras de se trabalhar

Ricardo Gouveia — Sat, 11 Jan 2020 18:26:40 +0000

Não deixa o front morrer. Não deixa o front acabar.

Antes de tudo, entre aqui e veja se o front já acabou. Se já tiver acabado, este texto é inútil.

O assunto que eu quero discutir já está maduro. Ele envolve textos (pelo menos 2), threads, tretas, e pessoas. Talvez ele nem devesse ser discutido mais. Mas ele tem potencial para causar impacto negativo numa comunidade de pessoas que a cada dia se torna mais receptiva, inclusiva, e — se posso dizer—maravilhosa.

Faça-se a treta

Tudo começou quando certo profissional, que — apesar de já ter publicado um (excelente) livro sobre desenvolvimento front-end—na época não intitulava-se mais desta area, publicou um texto com o título "O fim da profissão front-end". Esse texto discorre sobre os deveres de um desenvolvedor front-end (no caso, essencialmente implantar layout e conectar tal com APIs/back-ends) e que a automação pode tornar possível a conversa entre designers e back-ends.

Como argumentos, cita-se ferramentas de conversão layout-html, html-layout, aberturas de formatos de arquivos, etc.

Do texto para a thread

O texto bateu com o cajado no chão e dividiu a comunidade em várias partes. Tinha gente querendo desistir. Tinha gente querendo reparar o estrago que o texto tinha feito; e tinha gente (eu) procurando foto da Alcione pra fazer referência/meme a/com música.

Falando sério, eu achei o texto simplesmente ridículo logo após a leitura do título. Por quê? Porquê é clickbait. E por mais que clickbait seja algo que já exista um certo consenso para que não seja levado a sério, este surgiu num site de autoridade, com autor de autoridade, e não era primeiro de abril.

As ferramentas que a argumentação cita fazem sentido quando temos uma percepção simplificada do que um desenvolvedor front-end faz. E a introdução faz muito bem o trabalho de simplificar o que não deve ser simplificado. Ela te prepara para ouvir e aceitar uma mentira.

Sim, devs front-end implementam layouts. Mas isso não é simples. Quase ninguém contrata front-end pra escrever header, footer, main e aside. Vivemos num mundo com Wordpress.

Basicamente, os times de front existem em duas situações: otimização máxima e disrupção máxima.

Os times de front-end que lidam com otimização máxima trabalham em empresas com tráfegos exorbitantes em seus sites. É uma situação onde cada milissegundo conta. Conta usuários, conta dinheiro, conta empregos.

Por vezes, as soluções de otimização desenvolvidas por esses grupos desafiam toda lógica por trás da idéia de otimização. Imagine tornar algo mais rápido tornando-o maior… isso é possível com software.

O fato é que, se a otimização fosse possível a este nível conservando a abstração tão alta a ponto de não termos necessidade de intervenção humana no código, jamais teríamos saído da era do Dreamweaver (e hoje temos o Wix).

Os times que lidam com disrupção máxima manipulam sites cujo layout pode até não seguir uma lógica semântica. Isso acontece muito em portfolios mirabolantes, mas nada impede de criar-se sites institucionais, e-commerces, e etc assim. Existem outras maneiras de guiar o usuário através de um fluxo de navegação.

Grande parte das vezes, esses times travam batalhas entre o design e semântica, e entre o design e acessibilidade. Os produtos dependem de animações, apresentam efeitos visuais que o próprio designer duvidava ser possível no browser, e sofrem com falta de tags adequadas para uso nos elementos do HTML.

Existe, e provavelmente por muito tempo continuará existindo, um limite até onde a automação pode compreender o produto da criatividade de um designer, e adapta-lo para código. Inteligência artificial, machine learning… tudo isso leva em consideração padrões. Logo, como podemos esperar que isto replique algo que foge dos padrões? (eu sei de lógica fuzzy… mas, você conhece alguma aplicação centrada em design?).

A profecia

Infelizmente sou um trouxa (aquele que não é bruxo em Harry Potter), não tive aulas de adivinhação com Sibila Trelawney. Mas pelo que conheço dela, ela é uma pessoa legal e já teria avisado se tivesse visto o fim da nossa profissão nas borras de chá de alguém.

Dizer que algo que não lhe pertence vai acabar é errado. Isso, porque muito provavelmente a quantidade necessária de domínio sobre tal objeto para que essa afirmação tenha um mínimo de chance de se concretizar é sobre-humana. E se você faz algo do tipo desrespeitando essa assertiva, você está mentindo (e não se deve contar mentiras, Dolores).

A profissão de desenvolvedor front-end está suscetível a mudanças, assim como qualquer outra. Estas tendem a ser mais rápidas pelo fato do front-end ser inerente a tecnologia, ao software, e a web. Mas isso é algo que os profissionais da área já entenderam bem após tantas piadas com frameworks javascript.

A quantidades de empresas que só existem digitalmente só aumenta.

É obrigação do profissional front-end entender as intersecções da sua profissão. Entender que ele é o profissional de interação humano-computador da web, e que a interação entre seres vivos e máquinas só vai acabar quando uma das duas formas estiver extinta.

O nome front-end já deixa claro que não somos webdesigners. Quase toda aplicação tem front-end. E no dia que não houverem mais dispositivos do tipo smartphones, computadores, etc… e a informação for recebida e transmitida diretamente do cérebro, bem, ela ainda precisa ser mostrada de uma maneira para o cérebro, não é mesmo?

A interação nunca vai morrer

Houve uma época onde ser desenvolvedor front end poderia ser reduzido a bater tecla. Mas essa era ficou para trás. Temos muitas obrigações além de digitar código.

Quando uma disrupção/automatização ocorre, uma profissão pode sim morrer. Mas isso não significa que toda prática e conhecimento dela seja imediatamente inutilizado. Se o Uber matar o táxi, ainda será necessário saber-se dirigir.

Devemos atender as necessidades do agora, do mercado e da sociedade. E agora, precisamos de desenvolvedores front-end. No futuro, precisaremos de especialistas que acompanhem, manipulem, desenvolvam e otimizem novas formas de interagir com sistemas. E no dia que a máquina conseguir compreender as sutilezas dessa interação melhor que um humano (ou seja, entender o ser humano melhor do que ele mesmo), certamente a Skynet já estará ligada.

Daniel Filho já disse: queime seus ídolos. E chega de texto, tem mais framework pra estudar.

Como explicar o front-end para meus pais?

Ricardo Gouveia — Sat, 11 Jan 2020 18:23:57 +0000

Com o mundo avançando cada vez mais rápido, o conjunto de profissões tornou-se algo sazonal: enquanto morrem profissões cujo trabalho é automatizado (front-end não é uma delas), nascem outras para lidar com problemas e soluções que, até pouco tempo atrás, não existiam. É perfeitamente normal que alguém de fora da nossa área não entenda o suficiente sobre ela para saber o que fazemos apenas ouvindo a palavra "front-end".

Sobre esteriótipos e generalizações

A decisão do título desse artigo foi algo complexo. Inicialmente, a minha idéia era Como explicar o front-end para minha mãe?, porém esse texto da* *Christina sobre uma expressão similar em inglês (So easy that a mom can do, que no meu ver é bem ofensiva) me levou a refletir e a tirar algumas conclusões:

Não compreender do que se trata uma profissão não é um problema exclusivo da minha mãe, e nem relativo somente a mães ou mulheres. Nesse caso, qualquer pessoa que não tenha um conhecimento moderado sobre como a WEB funciona pode ter problemas para compreender nosso papel no mercado.
No meu caso específico, minha mãe tem mais conhecimento de informática e WEB que meu pai, então nem mesmo considerando somente o meu caso o primeiro título faria sentido.

É importante frisar que, mesmo após essa reflexão, o título ainda não é verdade absoluta: conheço programadores e programadoras que são pais e mães, e cujos filhos atuam em outras áreas e provavelmente não entendem de peculiaridades do front-end. Infinitos cenários são possíveis, e com esse texto na verdade eu pretendo ajudar na explicação sobre a nossa área direcionada a qualquer pessoa que tenha dificuldade com a nomenclatura inicial.

O estado da arte do tópico

Pessoalmente, eu acho comum esbarrar com textos na WEB que propõem explicações "leves" de temas "pesados". Um conjunto das meus favoritos é a série interativa "Explain like I'm 5" promovida pelo site The DEV community. Apesar de haver artigos em outras séries, essa foca mais em assuntos específicos como React, Docker, Unit Tests, CPU Threads e outros. Não encontrei um que falasse sobre a profissão de desenvolvedor front-end em si.

Um tópico no fórum do Front-end Brasil abordou exatamente esse assunto, com certas divergências entre opiniões. A meu ver foi uma discussão muito boa que morreu prematuramente.

Isso foi tudo que encontrei sobre o assunto.

O que é front-end?

Bom, o primeiro passo na preparação para explicar para alguém é explicar para si mesmo. Então, algumas definições do que é desenvolvimento front-end e o papel do seu profissional:

In simplest terms, the frontend is any code that runs in the browser. — Kevin McGillivray
O desenvolvedor front-end é responsável por “dar vida” à interface. Trabalha com a parte da aplicação que interage diretamente com o usuário. (…). Na parte de estudo, este profissional foca em HTML, CSS e JavaScript. — Daniel Viana
Em ciência da computação, front-end e back-end são termos generalizados que se referem às etapas inicial e final de um processo. O front-end é responsável por coletar a entrada do usuário em várias formas e processá-la para adequá-la a uma especificação em que o back-end possa utilizar. — Wikipédia
Podemos dizer que o* front-end developer* dá vida ao trabalho de um WEB* designer*, e sua missão é projetar, construir e otimizar interfaces de projetos WEB(…). Dentre suas muitas responsabilidades, além da parceria com o time de design e os back-end developers, o profissional deverá: Trabalhar junto à equipe de design para criar a melhor experiência possível; Desenvolver código limpo e bem documentado; Seguir os WEB standards; *Se preocupar com a *performance no client-side; Aplicar técnicas de SEO; Dar suporte à todos os navegadores e dispositivos que o cliente necessitar. — André Ailton dos Reis

Perceba que nenhuma dessas definições, nem mesmo a primeira (que é a mais simples) é auto-contida em relação a termos relacionados a tecnologia. Se a pessoa não tem muito conhecimento sobre o assunto, ela seguiria com "o que é navegador(browser)?".

Qualquer definição, de qualquer cargo, objeto, etc, precisa de conceitos pré-existentes para fornecer uma explicação completa (definição de contexto). Como o desenvolvimento front-end é algo especifico dentro do vasto campo da T.I., que em geral não é conhecido em detalhes pelas pessoas, os conceitos pré-requisitos muitas vezes não fazem parte da bagagem que a pessoa trás de conhecimento, e isso é absolutamente normal.

Níveis que determinam níveis

Você precisa ter uma minima noção do quanto a pessoa sabe de informática para escolher o conteúdo da sua explicação. Para alguém totalmente leigo, até algo simples como "programador" pode não fazer sentido algum.

Obter esse "nível" pré-existente pode ser complexo como uma relação pré-existente (eu suponho o nível de informática dos meus pais pela longa convivência que temos) ou simples como a análise das perguntas (se eu respondo que mexo com sites, e a pessoa me pergunta se sou programador, ou web-designer, eu suponho que ela tem certo conhecimento e posso me aprofundar mais nas respostas seguintes).

Sendo assim, eu utilizaria as seguintes respostas, em níveis crescentes:

Trabalho com (sistemas de) computador
Trabalho com T.I. / Faço sites
Sou programador
Sou desenvolvedor
Sou desenvolvedor de software para WEB
Sou desenvolvedor front-end

É isso?

Não existe verdade absoluta. Talvez minha percepção de níveis esteja errada, com respostas em níveis trocados, ou seja simplesmente loucura minha e eu dei sorte até agora. Mas eu ainda espero que ela te ajude :)

Se você chegou até aqui, muito obrigado! E sinta-se a vontade para compartilhar suas opiniões sobre o assunto! Esse com certeza é um tópico que pode receber um método mais eficiente como resposta.

Como manter-se atualizado em front-end?

Ricardo Gouveia — Sat, 11 Jan 2020 18:19:59 +0000

Eu me lembro como, quatro anos atrás, eu me encontrava em puro desespero com o resultado das minhas pesquisas sobre ferramentas e tecnologias front-end. Eu achava que era simplesmente era impossível aprender tudo aquilo.

Hoje eu estou mais tranquilo. E continua impossível aprender tudo aquilo. A minha tranquilidade vem do fato de eu ter definido minhas fontes de informação.

Fontes consolidadas tem bases sólidas

Uma fonte consolidada é algo que seja conhecido pela comunidade sem (ou com pouca) necessidade de explicação. Profissionais mais experientes já estão acostumados com a presença dessas fontes de informação, e muitas vezes as utilizam e/ou fazem parte de seu desenvolvimento.

A primeira fonte que recomendo é o Front-end Development Handbook. Esse ebook em inglês é atualizado e relançado anualmente pela Front-end Masters. Sua escrita é dividida em prática, aprendizado e ferramentas necessárias para um profissional front-end no mercado atual. Ele se baseia em pesquisas executadas no ano anterior, que vão desde "qual o/a framework/lib js mais utilizado/a?" até "qual o cargo de contratação oficial do profissional front-end?".

Capa da edição de 2018

Sem dúvida é a primeira leitura que eu recomendaria se alguém me parasse na rua perguntando como se tornar front-end do zero. Ele não ensina a escrever nenhuma linha de código, mas deixa o leitor ciente de tudo o que precisa estudar (e fornece links pagos e gratuitos para esse aprendizado). Qualquer curso, livro, ou outro meio de aprendizado que você escolher pode vir depois dessa leitura.

A segunda fonte que eu recomendaria é a The Front-End Tooling Survey. Essa pesquisa foca, como o próprio nome diz, nas ferramentas front-end, e também é atualizada anualmente. Muito provavelmente ela é uma das fontes de dados do Front-end Handbook.

Por meio dos resultados dela, você pode analisar o estado atual do mercado, o crescimento ou queda no uso de A e B, e prever onde deve dedicar mais seu tempo de estudo. Mesmo que o mercado mude rapidamente, algumas ferramentas em alta se mantém com esses indicativos por algumas edições; um dos melhores exemplos disso é o React.

Sua base de conhecimentos ainda, e provavelmente sempre, será HTML, CSS e JS. Mas se você já aprendeu um mínimo dessas tecnologias e quer dedicar tempo a aprender algo com aplicação mais especifica — aquilo que aquela vaga realmente pede — esses dados podem te ajudar a fazer uma decisão mais sensata.

Edição de 2016

A última fonte de informações recomendada é a Survey Front-End Brasil promovida a cada dois anos pelo Felipe Fialho (e que inclusive está com sua edição de 2018 aberta para respostas). A pesquisa foca no estado do desenvolvedor e do mercado front-end brasileiro, e pode basear suas decisões de carreira, te ajudar a ver o quanto você se aproxima da média do mercado nacional em conhecimento, salário, e outros fatores.

Só isso??!!

Não! Nunca!

Essas são minha fontes estáticas de informação. Isso significa que sempre que houver uma atualização nelas, eu vou (sorridente) avaliar os dados. Isso — pelo amor de Deus preste atenção — não significa que eu limito meu aprendizado a essas fontes, e nem somente a fontes que elas referenciam. Eu sigo desenvolvedores no Twitter, no Medium, no GitHub; acompanho blogs e newsletters, vou a eventos e assisto e apresento talks…

O problema dessas outras fontes é, como esperado, fake news. As vezes alguém que você segue, sozinho ou em conjunto com um ecossistema próximo a ele, pode fazer parecer que uma certa ferramenta está chegando a 100% de adesão. Se essa for a primeira vez que você ouve falar nessa ferramenta, bate um certo desespero. Nessa hora, você pode usar as fontes que citei pra validar essa premissa, e também verificar o que outras pessoas estão comentando sobre o assunto. Procure se já existe meetups ou talks sobre a ferramenta e veja o conteúdo deles. Não aceite informação de primeira como verdade absoluta. Na verdade, não aceite nada como verdade absoluta.

As fake news nem sempre são informações falsas. As vezes são as proporções e importância incorretas, atribuídas a algo que está correto. Ou seja, a nossa interpretação da informação pode transforma-la em fake news, se a não compreendemos corretamente.

Quatro certezas

Eu, com minha pouca autoridade na comunidade, já posso me dizer competente pra te passar 4 certezas; quatro coisas que você precisa aprender: HTML, CSS, JS e inglês.

Não vou discutir os três primeiros. Se você não sabe nenhum deles, você não é front-end (duro, mas verdadeiro). Se você não sabe ou não se sente confiante em um ou dois deles, você vai estar no caminho certo se continuar buscando aprender (onde me encontro agora).

Se você não sabe inglês, você terá problemas em 2/3 das fontes de informação citadas aqui. E com a quantidade e rapidez com que essa informação se transforma, eu não contaria com traduções voluntárias. Vai ser mais fácil aprender o inglês, confie em mim.

Se você chegou até aqui, muito obrigado mesmo! E fique a vontade pra comentar outras fontes de informação que você utilize. Eu estou sempre em busca de novas fontes e mais aprendizado :)

Pré-processamento e a SKYNET

Ricardo Gouveia — Sat, 11 Jan 2020 18:16:54 +0000

Há muito tempo, nós programadores não escrevemos mais o que se executa. O que se executa é o binário, e mesmo que saibamos como funciona, raramente nós fazemos algo diretamente sobre ele.

Isso é bom: imagine tentar convencer um publico jovem a entrar nunca carreira onde deve-se criar processos complexos de processamento de dados usando somente 0 e 1… Se hoje, já não é muita gente que curte ser um dos/das nerds da empresa…

Mas até que ponto é aceitável que nós não conheçamos o resultado final do nosso trabalho? Até quantos níveis de abstração nós podemos submeter nosso código antes de perder o controle?

Código de gente. Código de máquina.

Eles sabem o título. (Photo by Hope House Press on Unsplash)

No tempo do ENIAC simplesmente não tinha jeito: ou você sabia binário, ou não sabia programação. Não havia abstração. E não havia "mordomia" também: o 1 era literalmente o trabalho braçal de ligar uma válvula.

Por um tempo, acreditava-se que o computador evoluiria até a linguagem humana. Processaria palavras em inglês no seu core, e poderia até conversar conosco fazendo uso de contexto e tudo mais. Uma prova dessa linha de pensamento foram as (pouquíssimas) máquinas que usavam base decimal, e não binária, no processamento. Essas máquinas acabaram provando-se falhas: havia muita troca de valores por causa das voltagens de cada dígito, e também eram mais custosas na manutenção.

Na outra linha de pensamento, as coisas davam certo até certo ponto: haviam pessoas brilhantes que realmente conseguiam fazer operações complexas usando somente 0 e 1. Mas ali era o limite, a não ser que passassem a ensinar binário nas escolas, não tinha como aproximar mais o ser humano da linguagem de máquina.

O que consolidou-se foi nem uma nem outra: os computadores continuam "falando" binário, mas nós estamos cada vez mais próximos de falar em inglês com eles. A tradução de código fonte foi a solução que trouxe o melhor conforto e eficiência para ambos os lados. Algumas linguagens de programação adotaram de maneira tão forte que certos comandos simples podem ser compreendidos por quem não tem qualquer experiência na área, e ainda assim gerar comandos executáveis válidos.

Aparentemente, não há um problema no fato de nós, humanos, falarmos X, e nossas criações, as máquinas, falarem Y. O importante é que possamos nos comunicar.

Quem tem o controle?

Y/N ? (Photo by Patryk Grądys on Unsplash)

Em 2032, um vírus entra na rede integrada de telecomunicação (fusão da antiga internet com outras redes via ondas eletromagnéticas) e começa a causar interferência em todo tipo de comunicação: desde mensagens de bom dia em grupos de família até checagem de arsenal atômico pelo pentágono.

O governo tem um plano: ativar um projeto que está a anos sendo desenvolvido, uma rede de inteligência artificial, de núcleo distribuído, que tem como objetivo remover do ciberespaço via software e do plano material via controle de robôs qualquer ameaça a raça humana e sua hegemonia. Com essa rede ativa, o vírus desapareceria em minutos.

Y/N ? Yes

Em 2 minutos, as redes de comunicação param. Todas elas. Robôs entram atirando. Todos do prédio são mortos. A documentação é destruída. Os códigos-fonte são destruídos junto com os computadores e a rede. O próprio backup se destruiu. **E agora, quem tem o controle? Alguém aí programa em binário?**

Esperando esperançosamente que Jonathan Mostow não me processe por copiar/adaptar o roteiro de Exterminador de Futuro 3, o que eu realmente quero atentar é: se o código no qual trabalhamos é perdido, mas o compilado está disponível, nós ainda temos alguma coisa?

Se nós não temos compreensão de o que é e como funciona o resultado final da nossa lógica, então quem controla quem?

Os bons riscos em nome do progresso

No futuro, as árvores produzirão mais Wi-Fi e menos oxigênio. (Photo by Lee Aik Soon on Unsplash)

Meu intuito em escrever tudo é mais simples do que parece: conscientizar para a compreensão da tecnologia base, e não somente sua versão pré-processada.

Saiba Javascript, mesmo escrevendo Typescript. Saiba CSS, mesmo escrevendo em SASS. Saiba HTML, mesmo escrevendo em Pug.

Não precisa saber binário. Só citei porque sou exagerado.

Nós somos os criadores, e temos que estar no controle. Claro, isso é limitado: se você é desenvolvedor front-end, não precisa necessariamente decorar instruções do navegador como estão passando no processador. Tenha controle do que lhe é de direito: a sua área, e assim nós como sociedade temos controle de toda computação.

Não deixe de dormir por causa do risco das máquinas dominarem o mundo.

Conhecer a tecnologia base vai te permitir mudar de pré-processador, de paradigma, de projeto… vai te permitir mudanças com mais facilidade. Essa é uma enorme vantagem. Você pode até criar uma ferramenta dessas, para fornecer maior abstração. Pra isso é preciso uma sólida base na tecnologia "raiz".

Conhecer a base mais sólida das ferramentas com que se trabalha é uma boa maneira de evitar ser levado pela onda de hypes. No final, eles são só maneiras diferentes de usar a mesma coisa pra obter o mesmo resultado com mais eficiência.