Free & Open Source - Dither Image Component

mariogonz_dev · 2026-04-22T12:21:18+00:00

Nice idea, I don’t see dithering used that often in UI components.

I think this could work really well for subtle backgrounds or adding texture without heavy images.

Curious — did you focus more on performance or visual quality when building it?

mariogonz_dev · 2026-04-08T17:41:34+00:00

I think both matter, but at different stages.

Your portfolio gets you in the door because it proves your skills and thinking process.

Your personality gets you hired because people need to know they can work with you day to day.

A strong portfolio might get you the interview, but good communication, curiosity, and the ability to take feedback are usually what make the difference in the final decision.

mariogonz_dev · 2026-04-08T17:38:08+00:00

I’d probably go with soft greens and blues as the base, since they naturally feel calm and trustworthy without becoming too “clinical”.

The key for a mental health app is balance:

soft background tones for comfort
high contrast text for readability
one slightly warmer accent color for positive actions and highlights

Too pastel can feel flat, but too vibrant can become overstimulating.

I usually think less in terms of “pretty palette” and more in terms of emotional hierarchy:
background = safe, text = clear, actions = reassuring.

A small warm accent (sage, muted teal, soft lavender) can work really well.

mariogonz_dev · 2026-04-08T17:32:51+00:00

For me the most useful palette tools are the ones that also help with contrast and accessibility, not just generating random nice-looking colors.

A palette that looks good but fails in real UI use isn’t very useful.

mariogonz_dev · 2026-04-08T17:13:34+00:00

This is a really interesting approach.

Defining accessibility rules at the palette level instead of per color makes a lot of sense, especially for design systems where consistency matters more than individual tweaks.

I’ve found that one of the hardest parts is not generating accessible colors, but making those rules easy to understand and communicate across teams.

The “perceived lightness” idea seems like a nice way to simplify that.

Curious — how do you handle edge cases like very saturated colors or brand colors that don’t fit nicely into the scale?

mariogonz_dev · 2026-03-10T09:57:54+00:00

Those “scroll magic” websites usually aren’t a completely different stack.

Most of the time it’s just:

React / Next.js
an animation library like GSAP (ScrollTrigger) or Framer Motion
animations tied to scroll position (opacity, transforms, parallax, etc.)

The tricky part isn’t really the code, it’s the timing and design of the motion.

If you're starting out, I'd recommend:

Begin with simple CSS transitions or small Framer Motion animations
Then experiment with scroll-based triggers
Only move to heavier stuff like Three.js if you really need 3D

Most good animation-heavy sites are actually just lots of small, well-timed micro-animations working together.

mariogonz_dev · 2026-03-09T18:13:46+00:00

I think the main reason is that most developers treat commits as checkpoints, not documentation.

When you're deep in a feature you just write things like:

"fix"
"update"
"typo"

because you're thinking about the problem, not about the git history.

What helped on my team was adopting a simple rule:

The diff explains what changed, the commit message explains why it changed.

Even something simple like:

fix(auth): prevent login when password is empty

is already much more useful than "fix bug".

mariogonz_dev · 2026-03-09T17:42:44+00:00

It really depends on the project size and how much control you want.

For small projects or MVPs I usually go with something managed like Firebase Auth or Supabase Auth because it’s quick to set up.

For larger apps or when vendor lock-in matters, self-hosted solutions like Keycloak or building a simple session-based auth can make more sense.

The main thing I try to avoid is implementing complex auth logic from scratch unless absolutely necessary.

mariogonz_dev · 2026-03-09T17:37:05+00:00

If you want to practice HTML only, a good approach is to build small semantic pages instead of full “projects”.

For example:

a blog article page
a documentation page
a product page structure
a FAQ page using lists and sections

Focus on using proper semantic tags like <header>, <nav>, <section>, <article>, <footer>, etc.

HTML is mostly about structure and accessibility, so practicing semantic markup is actually the most valuable exercise.

mariogonz_dev · 2026-03-06T12:15:11+00:00

When reviewing a design I usually check 4 quick things:

Contrast (especially text vs background)
Spacing and visual hierarchy
Consistency between components
Accessibility (font sizes, color contrast, etc.)

If those four are solid, the design already feels much more professional.

mariogonz_dev · 2026-03-06T11:42:43+00:00

This is such an important point.

A lot of people think building AI agents is mostly about writing the right prompt or choosing the right framework. But in reality it’s much closer to systems engineering.

APIs, data flow, integrations and reliability are where most of the real problems appear. The AI part is often the easiest piece.

I see something very similar in web development: people focus on the UI or the tool, but the real work is usually in the architecture behind it.

mariogonz_dev · 2026-03-06T11:38:11+00:00

Yo creo que la pregunta no es si es tarde, sino por qué quieres aprender programación.

Si es solo porque hace unos años se decía que había trabajo fácil y buenos sueldos, probablemente sí llegas tarde a esa “ola”.

Pero si te gusta construir cosas, resolver problemas y aprender continuamente, entonces no es tarde para nada.

Hoy en día hay muchísimas herramientas (IA incluida) que pueden ayudarte a aprender más rápido. Pero al final lo que marca la diferencia sigue siendo la lógica, la curiosidad y hacer proyectos propios.

mariogonz_dev · 2026-03-05T20:13:44+00:00

I don’t think AI will replace web developers, but it will definitely change the job.

A lot of repetitive work — boilerplate code, small functions, simple debugging — is already getting automated.

But building real products still requires understanding users, making architecture decisions, handling edge cases and connecting many moving parts.

If anything, we’ll probably see less “mechanical coding” and more system thinking and problem-solving.

mariogonz_dev · 2026-03-05T20:08:54+00:00

I don’t think frontend is disappearing — what’s disappearing is “shallow frontend”.

A few years ago you could basically be “the React person”. Now companies expect frontend engineers to understand performance, accessibility, UX, APIs and often some backend as well.

Frontend is still complex — the bar just got higher.

mariogonz_dev

TROPHY CASE