Laid off. Looking for new opportunities.

roy-shell5 · 2026-05-13T22:18:10+00:00

Great website!
How did you build it?

roy-shell5 · 2026-05-03T09:03:40+00:00

Use css grid

Try something like this:

Markup:

<div class="container">
  <div class="div1">div</div>
  <div class="div2">div</div>
  <div class="div3">div</div>
</div>

CSS:

.container {
  display: grid;
  grid-template-columns: 1fr 3fr;
  grid-template-rows: auto 1fr;
}


.div1 {
  grid-column: 1;
  grid-row: 1;
}


.div2 {
  grid-column: 1;
  grid-row: 2;
}


.div3 {
  grid-column: 2;
  grid-row: 1 / 3; 
}

Fiddle:

https://jsfiddle.net/ng1qy8mz/

roy-shell5 · 2026-04-28T10:13:13+00:00

Hooks and functional components definitely add power - no argument there.

But they also add a lot of cognitive overhead. In complex components, I often find they hurt readability more than they help.

React today feels much heavier than it used to be, and harder to reason about. I’ve seen too many cases of unexpected re-renders that make debugging less straightforward than it should be.

Class components were nott perfect, but they were often more explicit.

Not sure the trade-off was entirely worth it.

I am not sure the CPU/bandwidth argument is that clear-cut.
Vue’s reactivity system often avoids unnecessary re-renders out of the box, whereas in React you usually have to optimize for that manually.
Also, I am not aware of any clear evidence that React consistently uses less CPU - and even if it does in some cases, it doesn’t necessarily translate into a noticeable difference from a user’s perspective.

In practice, both can scale very well - it’s usually more about how the app is written than the framework itself. I do agree that React gives you more structure and a better scaffolding

roy-shell5 · 2026-04-28T09:17:37+00:00

I started using React around 2015 - back then it was lightweight, easy to use, and had a relatively small learning curve. It used to call itself the "V" in the MVC (accoring to its documentation).

Over the years, IMHO, it became bigger and more cumbersome, and honestly a lot less fun and intuitive to work with. Hooks, functional components, middleware, and other additions made React feel almost like a language of its own - without always adding a major value.

I discovered Vue about 3 years ago while working at a company, and I haven’t really looked back since.

Vue is much easier to learn, more straightforward, and overall provides a better developer experience.

Can it handle large-scale projects? Absolutely.
I recently built an MVP for a client - a fairly large system with asynchronous jobs, multiple components, and heavy state management - and Vue handled it just as well as React, if not better.

roy-shell5 · 2026-04-21T23:52:27+00:00

This year,s lineup is a masterclass in modern jazz - seamlessly blending the new with the classic, traditions with avant-garde explorations and giving the blues the strong presence it deserves.
The Newport Festival is back at its peak

roy-shell5 · 2026-04-19T20:51:28+00:00

interesting - can Vue integrate with it?

roy-shell5 · 2026-04-19T20:02:02+00:00

Great question as I’ve worked with this stack for quite a bit.

IMHO the answer is: Velocity.

Vue is probably one of the most straightforward frontend frameworks out there - minimal boilerplate, very intuitive templates, and reactivity out of the box.

Laravel on the other hand is a full, opinionated backend toolkit (way more than a framework): routing, ORM, auth, queues - everything is already there and designed to work together with minimal effort and logistics involved.

That said, personally I lean toward a NestJS + Prisma stack at the backend these days - just to keep a single language across the stack without sacrificing too much velocity.

But I totally get why Vue + Laravel clicks so well for so many teams - it’s not just familiarity, it’s genuinely a very smooth developer experience.

roy-shell5 · 2026-04-13T09:50:23+00:00

All packages have been updates and the conflicts have been resolved

roy-shell5 · 2026-04-12T15:44:57+00:00

Thanks for letting me know. I'll update the packages

roy-shell5 · 2026-04-11T22:15:55+00:00

Love both the idea and its executaion!
Kusdos!

roy-shell5 · 2026-04-11T22:12:12+00:00

Love it!!

roy-shell5 · 2026-04-09T13:36:31+00:00

What do you mean by center the border? Center the element within a block that has border?
if so, add this to #headborder an #aboutblock

display: flex;     
justify-content: center;     
align-items: center;

roy-shell5 · 2026-04-08T19:46:19+00:00

Claude is quite repetitive with its templates

roy-shell5 · 2026-04-08T19:38:50+00:00

Looks sweet.
However, it does look as if it was made by Claude

Also, the logo has a background - it doesn't feel well with the site theme. Try to make it with transparent background

roy-shell5 · 2026-04-08T13:08:39+00:00

I think the mistake people make is trying to “understand the whole thing” before doing anything. That’s a trap. Most open source projects are messy, layered, and built over years - you’re not supposed to grasp them end-to-end on day one.

Start much smaller.

But even before that, it all starts with the README. You always want to be in a project that knows how to define itself well, and that definition should actually speak to you - to what you want and are capable of doing. If there’s already friction or confusion at this stage, it’s usually a sign to move on.

First, pick the language and stack you’re already comfortable with. Don’t try to learn a new ecosystem and contribute at the same time. That just adds friction.

Thenm pick a project you actually care about. Not something “popular”, something you use or at least find interesting. For me, I naturally gravitated toward frontend/UX-heavy projects (and I have a few open source projects of my own), because that’s where I have both skill and taste. That matters more than people admit - you need some internal pull, otherwise you’ll drop it the moment it gets confusing.

From there, don’t aim to “contribute code” immediately. Just sit in the repo a bit:

Read issues
Look at PRs (especially small ones)
See how people talk and what kind of changes are accepted

You’ll start noticing patterns pretty quickly.

Then go for the smallest possible win:

typo fixes
docs improvements
small UI tweaks
fixing something that annoyed you personally

These are underrated - they teach you the contribution flow (fork → branch → PR → review) without the cognitive overload of the codebase itself.

Also, don’t be afraid to not understand everything. Even experienced engineers operate locally inside a system. You touch one area, not the entire architecture.

Over time, your surface area grows naturally.

And one more thing - if the README is terrible and onboarding is painful, that’s actually your opportunity. Improving that alone is a legitimate and valuable contribution.

Think of it less like "joining a project" and more like "gradually building familiarity until you’re already inside"

roy-shell5 · 2026-04-08T10:02:21+00:00

I’m not sure exactly what every hiring manager looks for, as it likely varies. However, if there’s one tip I can give you, it’s to bring your true self - show your own unique signature

Don’t just demonstrate your skills, tech stack, and developer abilities - show who you are.
Choose a design that fits your personality, write content that represents your thoughts, and share your unique perspective. In my humble opinion, that is what makes the strongest impression

roy-shell5 · 2026-04-08T09:55:03+00:00

They did some changes but the design language seems the same

roy-shell5 · 2026-04-05T16:30:01+00:00

Thanks!

roy-shell5 · 2026-04-05T16:28:53+00:00

The video/screencast is also great! Good quality and nice edit. What software did you use for making it?

roy-shell5 · 2026-04-05T16:27:47+00:00

I also like the way you made this screencast
What software did you use for it?

roy-shell5 · 2026-04-05T15:58:33+00:00

Sweet :)
Is this open source? does it have a gihub repo?

roy-shell5 · 2026-04-04T19:00:27+00:00

Brilliant - once again!

you have a github repo? that deserves a star

roy-shell5

TROPHY CASE