Szymon Chudy

Thanks for sharing your perspective. Another big issue is i18n in SSR, but that's for another discussion :)

@tomaszgil.me Out of your experience, how do you feel about the "rule of thumb" of abstracting text in an i18n way even for unilanguage apps? Of course, it depends on the scale (e.g., I wouldn't do that for my personal blog), but in general, how does this sound to you?

Thanks for feedback Tomasz, appreciated! 🙏

I believe this becomes particularly noticeable when working with a 3rd party translator. This is the point when you realize how it can reduce the effectiveness of the whole workflow. In such cases, concatenated strings are likely to result in bug tickets.

Building for the World: A Developer’s Guide to Internationalization and Localization _ by Szymon Chudy Practical introduction to internationalization (i18n) and localization (l10n) – from a developer’s point of view.

🌍 #i18n may be for you – even if your app supports just one language.

It’s not just about translation – it’s about clean, resilient UI.

7 golden #frontend i18n rules, ICU → Intl → Temporal → layout tips, and more! chudy.me/blog/buildin...

Do you have it deployed somewhere or is it just local for now?

I would like more people to learn that Sometimes You Need to Save Even Valid Criticism for Later When Your House is Literally Burning Down

Everyone focuses on the "technical" part of technical interviews, but another important thing being evaluated is communication. If you can share your thought process and walk the interviewer through your reasoning, you might pass the interview even if you can’t solve the problem!

For quite some time I was looking for a solution to improve my personal project’s productivity. I was reluctant to try all those corporate-targeted apps as they felt to complex for my needs. However, after your recommendation I’ll give it a try. Thank you 😊

Thank you!

I'm considering a modular (or "composable") approach to create feature variants without needing an API to customize every potential scenario, which would become a maintenance nightmare.

Thank you for the article. It was delightful to read!

I finally managed to read the article, and it actually fits my current challenges. While gathering new requirements for the piece of the app I own, I've noticed that if we keep making it generic like we do now, we'll end up with a legacy-like spaghetti code despite the fact it has just 18 months.

Sounds cool! By join you mean sharing the posts/articles we discussed or some dev work as well? Is this something we can discuss on your Discord?

Thank you! I've already done that to some extent. I'm curious about how one develops into a regular contributor. Does it happen organically through consistent contributions, or should I proactively reach out to the maintainers? Perhaps it's a combination of both? Sorry for these basic questions! 😅

What would you recommend to someone who would love to start contributing to #OSS regularly, but struggle to understand where to start?

Tagging some of the best contributors I have in my network hoping to get some advices 🤞
@tkdodo.eu @crutchcorn.dev @graphieros.com @danabra.mov @tannerlinsley.com

💡 Looking ahead, I foresee the evolution of frontend developers into technical user experience advocates, actively shaping product discovery, design, implementation, and performance strategies.

Let me know If you'd be interested in a post on how to approach these exams efficiently 🙌

➡️ Delving into AWS has broadened my understanding of software engineering, highlighting the importance of a more comprehensive approach in our roles as developers.

➡️ Certifications serve mainly as important milestones, delineating specific knowledge boundaries and guiding our learning paths.

➡️ Nowadays, "just building working #React components" is no longer sufficient for career growth. A deeper understanding of general infrastructure aspects, including cloud services like AWS, is becoming increasingly essential.

➡️ As frontend developers, we often underestimate the extent to which we interact with cloud services on a daily basis. Services like S3, CloudFront, EC2, Route53, ECR/ECS, are impacting our work more than we realize. More so, many 3rd party services we use are built on top of AWS.

From Zero to AWS Solutions Architect Professional In 7 Months: A Frontend Perspective _ by Szymon Chudy Navigating the AWS console was intimidating for me, but in just 7 months, I earned my Pro certificate and 3 Associates. Was it worth it for a frontend dev?

Navigating the #AWS console was always intimidating for me. So how did I end up with their Pro certificate and all three Associates in just 7 months? More importantly, was it worth it for a #frontend dev?

You can read the full post here: chudy.me/blog/from-ze...

And here are some key highlights 🧵

Just upgraded my first site to @tailwindcss.com v4, and oh boy, it's so fast! It took me a while to fully migrate to the CSS-only config, but it gives that feeling of "this is exactly how it should be."

Amazing work, #tailwind Team!

The modern way to write JavaScript servers The Request/Response-API is not just faster, but also makes writing tests easier.

Wrote a short article on why the modern Request/Response API is so much better compared to node:http .

marvinh.dev/blog/modern-...

"The fact that two components look or behave similarly (or even the same) doesn’t automatically make them good candidates for abstraction."

Damn right. Great post from @chudy.me 👏

Thanks you so much! Saving this one to read on the weekend.

Thanks! Just Astro with some simple vanilla JS for theme and animation.

Good luck 🤞 my blog for now is framework free but I plan to play with islands as well. Let’s see where it takes us.

What are you cooking? Moving blog?

Thanks! My initial idea behind it was to practice writing subjectively on frontend and software engineering but maybe overtime I’ll expand the approach a little bit.

But thank you for mentioning that. I assumed no one will read that to be honest and that was a nice surprise 😅

Frontend Developer: Do Repeat Yourself _ by Szymon Chudy "Don't Repeat Yourself", also known as DRY, is a foundational principle in software development, often learned early in a developer’s journey. At first glance it sounds simple and straightforward. But...

Don’t Repeat Yourself, also known as DRY, is a foundational principle in #software development, often learned early in a developer’s journey. At first glance it sounds simple and straightforward. But can it be misapplied?

Let’s explore it from the #frontend perspective:
chudy.me/blog/fronten...

Like for real? 😅 I have videos too, just saying 😉

Damn, writing those blog posts takes time 😅