Web Development

cross-posted from: https://lemmy.bestiver.se/post/992456

Comments

Have you ever opened an old project and thought, “Why on earth was this done like this?”

And then… a few minutes later… realized you were the one who wrote it?

I ran into this while digging through an old Node.js app. One small bug led to another, and suddenly I was tracing through layers of “quick fixes”.. little patches that made sense in the moment but now feel like a house of cards.

It got me thinking... Adding a quick fix just to move on, knowing it wasn’t the “right” solution?

We all do it, right? Deadlines are tight, specs aren’t clear, and you just need things to work. But then…

What would you do if that same fix came back six months later as a critical bug?

Would you even remember why it was written that way?

Sometimes I feel like these fixes aren’t really about code.. they’re about pressure. Ship now. Clean later. Except…

When was the last time “later” actually happened?

And here’s another one: Do you think quick fixes are always bad, or do they have a place if used carefully?

Lately I’ve been trying to catch myself in that moment.. when a “5-minute fix” starts turning into something messier.

Do you stop and rethink at that point, or just push through and hope for the best?

I’ve started asking myself: “Would I understand this in 3 months?” If the answer is no, I try (try being the key word) to slow down a bit.

How do you feel about that approach? Too idealistic, or actually practical?

TLDR; I’ve been experimenting with react-like jsx-syntax with webcomponents to see if I could theoretically replace React in one of my projects. It is not ready for production use, but rather an exploration into CustomElements and modern browser capabilities.

https://github.com/positive-intentions/dim

The goal was to build functional Web Components that handle state management and DOM updates without the overhead of a massive JavaScript framework. By leveraging standard Web APIs and Proxy objects, I’ve managed to create a reactive programming model that feels familiar—using JSX—but stays much closer to the browser platform.

I wanted to see how far i could take web components before the architecture broke down. If you’re interested in frontend software engineering or web standards, you might find the logic behind the updates (which avoid a traditional virtual DOM) interesting.

Full technical tutorial and deep dive: https://positive-intentions.com/docs/research/Tutorials/dim/dim-functional-webcomponents

Disclaimer: This project is not ready for production use. In fact, this project may be getting deprecated soon, but I’m sharing it because the unique details into custom elements and modern JavaScript performance might be interesting or educational for others exploring the web platform.

I've tried the opposite approach. When a client mentions the chatbot, I'll sometimes open a few smolweb sites, fast, minimal, readable, calm. No pop-ups. No blinking corners. Just content, clear and immediate.

Their eyes change. "Oh, that loads fast." "That's easy to read." "I like that."

Not my project, but this was recently released and I thought it was really cool. It's only 5KB when compressed and feels a bit simpler/more automatic than HTMX.

Also natively handles prefetching on hovering links, has transitions, and comes with a loading bar.

Hi all, I wrote an article based on my (rather messy) experience setting up isso comments on my blog. It's also a casual look at how to set up any hosted service on hardware you control. If you're interested in self-hosting and such it may be helpful. Enjoy!

You know how this goes.

Three weeks on the portfolio. Rewrote the case study twice. Rebuilt the layout because something felt off at midnight on a Wednesday. Sent it to two designer friends who said it was strong. Found the right contact on LinkedIn, personalized the message, attached the link.

Three days later: automated rejection. No subject line variation. Thank you for applying.

Different company, same month. A referral came through – someone you’d worked with two years ago, mentioned your name in a Slack message to someone they knew. You sent a portfolio link you hadn’t touched in weeks.

First-round interview confirmed within 48 hours.

cross-posted from: https://lemmy.bestiver.se/post/972299

Comments

I tested what happens when you paste code into popular online developer tools. Some sites contact 96 external domains, set 540 cookies, and run real-time ad auctions on your data. Here is everything I found.

The goal is to write small, clean, accessible HTML that works on any device, any browser, any screen, even without CSS or JavaScript. A smolwebsite should load on a smartphone from 2010, work in a text browser like Lynx, and be readable on a Braille display. Not because those are common cases, but because if your page works there, it works everywhere.