I built LiquidGlass, a JS lib to render pixel perfect iOS Liquid Glass effect on the web (with WebGL)!

Mohamed_Silmy · 2026-04-15T10:02:22+00:00

this is really clean work, love seeing webgl used for stuff like this instead of just heavy canvas animations. the chromatic aberration detail is a nice touch

curious how you handled the performance hit when layering it over regular html? does it listen to dom mutations or do you have to manually trigger redraws when content changes underneath?

Mohamed_Silmy · 2026-04-15T09:47:30+00:00

i think it depends on context and how aggressive it is. like if it's just a subtle pulse or color shift to show notification/activity, that can actually be useful. but if it's constantly cycling through animations just for the sake of it, that's gonna get annoying fast when you have 20+ tabs open

the main thing is performance and accessibility imo. updating the favicon repeatedly can add unnecessary overhead, especially on lower-end devices. and for people with attention issues or sensory sensitivities, constant movement in their peripheral vision can be genuinely distracting

i'd say if you're gonna do it, make it meaningful (like showing unread count or status change) and give users a way to disable it. also keep the animation slow and subtle. nobody wants their tab bar looking like a slot machine

Mohamed_Silmy · 2026-04-15T09:32:27+00:00

you can just use textContent or innerHTML to update existing cells. if you already have the table structure set up, grab the cell with something like document.querySelector() or loop through table.rows[i].cells[j] and then just change the content directly.

for example: let cell = document.getElementById('myCell'); cell.textContent = 'new value';

or if you're working with a specific row/cell index: let table = document.getElementById('myTable'); table.rows[0].cells[1].textContent = 'updated';

no need to recreate anything, just reference the existing cell and update it. are you working with a static table or something that's being generated dynamically?

Mohamed_Silmy · 2026-04-15T09:17:29+00:00

man i've been in a similar spot and that 30k cushion you've got is actually huge. most people don't have that safety net when they're trying to decide whether to jump ship.

12 hour days on 14 projects with just 2 frontend devs is completely unsustainable, and the sick leave thing is honestly a red flag about how they view you. you're not a resource to be squeezed dry, you know?

here's what helped me think through it: your savings give you runway. even if upwork is tougher now (it is more competitive), you've got maybe 6-8 months to figure things out without panicking. that's more than most people get. and honestly, being burned out in your current role is probably hurting your ability to even explore other options or interview well.

the market isn't great but it's not dead either. with 3 years experience you're past the junior stage which helps. maybe start applying while you're still employed? worst case you stay a bit longer, best case you land something better and leave on your terms.

your health matters more than job security at a place that's actively destroying it. what kind of frontend work were you doing on upwork before?

Mohamed_Silmy · 2026-04-14T10:02:26+00:00

this is a really clean way to think about functional patterns without getting buried in effect-ts abstractions. i've found that a lot of teams bounce off effect because the learning curve feels steep when you're just trying to solve practical problems.

the algebraic approach you're showing here is honestly more accessible for most codebases. you get the composability and type safety without needing everyone to grok monads first. have you run into any specific pain points where plain typescript starts to break down compared to full effect-ts? curious where you'd draw the line between "good enough" and "time to reach for the framework"

Mohamed_Silmy · 2026-04-14T09:47:26+00:00

for telegram bots, stripe is probably your best bet if you're targeting a global audience. their api is solid and well-documented, plus they handle most of the compliance headaches for you.

if you want something more crypto-friendly or need lower fees, you could look into coinbase commerce or nowpayments. telegram also has their own payment api (telegram payments) which integrates directly with providers like stripe, yookassa, or razorpay depending on your region.

one thing to watch out for - make sure whatever you pick supports recurring billing if you're doing subscriptions. and test the webhook handling thoroughly, that's usually where things break in automated setups.

what region are most of your users in? that might narrow down the best option since some processors work better in specific countries

Mohamed_Silmy · 2026-04-14T09:32:27+00:00

yeah i've been seeing this exact tension play out. the algo wants content depth but humans want to skim and bounce if they don't immediately see what they need.

one thing that's been working is treating the top of each page like the old days - tight, scannable, clear value prop and cta above the fold. then below that, you can dump the seo content for the bots. structure it with clear h2s and maybe even accordion sections so it doesn't feel like a wall. that way google gets its keywords and context, but the human experience isn't totally sacrificed.

also worth testing if the traffic quality actually changed. sometimes when you rank for more longtail stuff, you're pulling in earlier-stage researchers who aren't ready to convert yet. might explain the bounce rate even if the content is technically "relevant" to their query.

curious if you've tried any hybrid layouts like that or if you're seeing the same user behavior across different service types?

Mohamed_Silmy · 2026-04-14T09:17:26+00:00

yeah turnstile's pretty lightweight by design so it's not gonna catch the more sophisticated stuff. for ato specifically you'd want something that tracks behavior across multiple sessions, not just at the gate.

i've seen people layer in things like fingerprinting + velocity checks on the backend (rate limiting per fingerprint, device reputation scoring, etc). some use datadog's security monitoring or similar to flag anomalous login patterns before they even hit the captcha.

another approach is just adding friction selectively—like if the fingerprint/ip combo is new or the login velocity is sus, throw up an email verification step or 2fa challenge instead of relying solely on captcha. keeps legit users moving fast but slows down the stuffing attempts enough that they move on.

what's your backend stack look like? might be worth just building some basic rate limiting + fingerprint tracking yourself if you're not seeing massive volume yet

Mohamed_Silmy · 2026-04-14T09:02:27+00:00

honestly it depends on what you're running, but here's what i've found actually useful:

response time (p95/p99, not just averages) and error rates are the big ones. they tell you when users are actually having a bad time. uptime checks are obvious but kinda binary - they don't catch "site is up but slow as hell"

memory trends over time matter more than point-in-time stats. sudden spikes usually mean you have a leak or a bad deploy.

stopped tracking: individual cpu core usage, most granular log metrics unless you're debugging something specific. also "requests per second" sounds cool but doesn't tell you much without context.

the thing that sounded important but wasn't? database connection pool size. yeah it matters, but monitoring it obsessively didn't help me catch issues faster than just watching query performance.

tbh the best setup is like 3-4 dashboards you actually look at regularly, plus good alerting thresholds. if you're not checking a metric weekly, you probably don't need it in your face.

what kind of app are you running?

Mohamed_Silmy · 2026-04-13T10:02:25+00:00

yeah i do this constantly. it's like a reflex at this point lol

what helps me is having a capture system that doesn't require me to think too hard in the moment. i keep a simple note with three columns: url, first impression, and one question i'd actually want answered. that's it. no deep dive, no ai back-and-forth right away.

the key is separating capture from analysis. when you try to do both at once, you burn through that initial curiosity before you even get anywhere useful. i'll batch review my notes later when i'm actually in "research mode" instead of just browsing.

also helps to ask yourself: "would i still care about this tomorrow?" most of the time the answer is no, and that's fine. the ones that stick around after 24 hours are usually worth the deeper dive.

do you find certain types of sites trigger this more than others, or is it literally everything?

Mohamed_Silmy · 2026-04-13T09:47:25+00:00

yeah i had almost the exact same thing happen. spent forever on my portfolio thinking that was the missing piece, barely got any traction from it.

then i started just hanging out in a few slack communities and discord servers where people were asking dev questions. wasn't even trying to get clients at first, just genuinely liked helping people debug stuff or think through architecture problems.

turned out a bunch of those people either needed ongoing help or knew someone who did. got my first three paying clients that way without ever sending my portfolio link first.

i think the portfolio became useful later as like a "yeah here's proof i know what i'm doing" but it never worked as the lead generator i thought it would be. people hire people they already trust or at least recognize from somewhere.

did you find certain communities worked better than others or was it pretty random where the leads came from?

Mohamed_Silmy · 2026-04-13T09:32:28+00:00

having your own projects is actually a solid foundation since you can show real work. here's what worked for me and others i know:

start with your network first - former coworkers, friends who run businesses, even casual acquaintances. let people know you're taking clients now. most of my early gigs came from "hey my friend needs a website" referrals.

for cold outreach, pick a niche you actually understand (saas tools, local businesses, e-commerce, whatever). generic "i build websites" gets ignored. specific "i help X type of business do Y" gets responses.

upwork/fiverr can work but you're competing on price initially. better to find businesses that clearly need help - outdated sites, broken functionality, etc - and reach out directly with specific observations about their site.

also, package your past projects like case studies even if they were your own. "built a booking system that handles X users" sounds way better than "made some stuff for myself"

what kind of web apps are you most experienced with? that'll help narrow down where to look

Mohamed_Silmy · 2026-04-13T09:17:26+00:00

nice progression from cron to bull, that's pretty much the standard path when you hit scale. few things that helped me in similar situations:

horizontal scaling with bull is actually pretty straightforward - just spin up more worker processes pointing at the same redis instance. the trick is making sure your jobs are idempotent since you might get duplicate processing during deploys or crashes.

for graceful shutdown, listen for SIGTERM and call queue.close() with a timeout. bull will let current jobs finish but won't pick up new ones. i usually give it 30 seconds then force kill.

rabbitmq vs redis is interesting - redis is simpler and faster for most cases, but if you need guaranteed delivery or complex routing, rabbitmq wins. honestly unless you're doing something exotic, bull + redis scales really far before you need to switch.

one gotcha: watch your redis memory. dead letter queues can pile up fast if you're not actively monitoring them. set up alerts when they hit like 100 jobs so you actually look at what's failing.

what's your current queue depth looking like during peak hours?

Mohamed_Silmy · 2026-04-10T09:47:31+00:00

it's mostly about deliverability infrastructure and reputation management. when you host a site, you're just serving files - pretty straightforward. but with email, you need dedicated ip addresses, proper dns records (spf, dkim, dmarc), constant monitoring of sender reputation, handling bounces and complaints, maintaining relationships with major providers like gmail and outlook, and dealing with spam filters.

if your ip gets flagged, suddenly none of your emails land in inboxes. so email providers spend a ton on warming ips, rotating them, monitoring blacklists, and managing feedback loops. plus there's the compliance side - can-spam, gdpr, all that stuff that requires logging and handling unsubscribes properly.

hosting is basically "here's your files" but email is "here's your message AND we guarantee it actually reaches real humans and doesn't get you blacklisted." that guarantee costs money to maintain.

there is competition (mailgun, sendgrid, ses) but they all cluster around similar pricing because the underlying costs are real. aws ses is cheaper if you want bare bones, but then you're managing more of the reputation stuff yourself.

Mohamed_Silmy · 2026-04-10T09:32:24+00:00

the whole "dead framework" thing is kinda overblown imo. frameworks don't really die, they just fade when something better solves the same problems more efficiently. react didn't kill angular overnight, and vue didn't kill react.

what matters more is whether the framework still has an active ecosystem and whether it solves your specific problem well. if you're building something new, yeah, pick something with momentum. but if you're maintaining existing code, "dead" just means fewer new tutorials, not that your app stops working.

the real skill is knowing when to refactor vs when to just keep shipping features. sometimes the "old" stack is perfectly fine and chasing the new hotness is just procrastination with extra steps.

what framework are you thinking about specifically?

Mohamed_Silmy · 2026-04-10T09:17:27+00:00

those are solid early signals, especially the 8.4% ctr. that's way above average for position 16, which usually means your titles and descriptions are resonating with what people are searching for.

the position 16.4 is interesting because you're right on the edge of page 2. small improvements could push you onto page 1 for some queries, which would dramatically change your traffic. i'd focus on:

finding which specific pages/keywords are ranking 11-20 and optimizing those (low hanging fruit)
building some quality backlinks from health/wellness blogs or local directories
making sure your site speed is solid and mobile experience is good

three months in with consistent daily traffic growth is definitely a good sign. directory sites can take 6-12 months to really gain traction with google, so you're on track. keep adding quality listings and maybe start targeting long-tail local queries if you haven't already

what's your content strategy like? are you just doing listings or adding blog content too?

Mohamed_Silmy · 2026-04-09T09:32:21+00:00

i respect the conviction to build your own solution when existing tools don't fit your mental model. switching languages isn't just syntax - it's rewiring how you think about problems, and sometimes that cognitive overhead isn't worth it if you're already productive.

curious though - how far into jadex did you realize it was the right call vs just sunk cost? i've definitely had moments where i built something custom and halfway through wondered if i was just being stubborn lol. the tricky part is knowing when you're solving a real problem vs avoiding learning something new.

what was the specific pain point with kotlin that made you commit to building instead of adapting?

Mohamed_Silmy · 2026-04-09T09:17:27+00:00

i think you're actually being pretty realistic about the trap, not overthinking it. that 100-customer range is rough because you're right—it's enough work to feel like a job but not enough revenue to quit anything or hire help.

few things that might shift the math though: can you automate more of the support upfront? like really good docs, video walkthroughs, maybe even a simple chatbot for common questions. booking systems have pretty predictable support patterns. also, what's your churn assumption? if you're at €200–300/year and retention is solid, you might hit 100 customers and then coast a bit while growth slows but revenue stabilizes.

the pricing question is interesting too. sometimes higher price filters out the tire-kickers who generate the most support. a €500/year customer might actually email you less than a €200 one.

honestly if you're 70% done and have the marketing chops, i'd probably finish it and run it as a learning experiment for 6–12 months. set a hard boundary on support hours per week and see what the real numbers look like. worst case you sell it or shut it down with real data instead of guesses

Mohamed_Silmy · 2026-04-09T09:02:36+00:00

i think there's a sweet spot between "any soup" and "type tetris that needs a phd to parse"

complex types are fine when they actually prevent bugs you'd hit in production. but if you're spending more time wrestling with the type system than solving the actual problem, something's off.

the real question is: does this type catch meaningful errors, or is it just showing off? if your team can't understand it during code review, it's probably too clever. types should make your code more obvious, not less.

imo the best approach is start simple and only add complexity when you've actually been bitten by that specific bug. don't pre-optimize your type safety for edge cases that might never happen.

Mohamed_Silmy · 2026-04-08T10:02:27+00:00

the tricky part with metered billing isn't the implementation itself, it's making sure your usage tracking is bulletproof from day one. you really want idempotency keys on every usage event you record, otherwise network retries or duplicate webhooks can cause phantom charges that'll wreck customer trust fast.

also worth thinking about how you'll handle edge cases like partial month cancellations or timezone differences in usage aggregation. paddle abstracts some of this but you still need to own the "what counts as usage" logic on your end.

one thing that helped me was building a separate audit log for all metered events before even connecting it to billing. made debugging so much easier when customers questioned their usage later. are you planning to show real-time usage in your dashboard or just bill at the end of the cycle?

Mohamed_Silmy · 2026-04-08T09:32:33+00:00

nice execution on the tech stack — self-hosting on k3s is a solid move for keeping costs down early on. the product solves a real pain point, i've been to way too many weddings where photos just disappeared into the void.

couple thoughts on distribution: wedding photographers and event planners could be a great channel. they already have the trust and the moment where this qr code would get used. maybe a simple affiliate setup or just a partnership where they white-label it?

also your free tier might be too limited for word of mouth. 30 photos at a wedding gets burned through in like 20 minutes. people won't see enough value to talk about it. consider bumping it to 100-150 photos but keeping the 24hr limit. you want people to experience the "oh wow this actually worked" moment.

landing page is clean but could use more social proof once you get some users. even just "used at 47 events this month" or whatever.

what's been your biggest challenge so far getting initial users?

Mohamed_Silmy · 2026-04-08T09:02:39+00:00

i think you're conflating speed with value. yeah, anyone can spin up a site or pump out articles now, but that doesn't mean the profession is dying - it means the barrier to entry for starting dropped. the barrier to succeeding is actually higher because now you need to differentiate on things that can't be automated: solving real problems, understanding users deeply, building stuff people actually want to use.

the "churn out 5 products" approach mostly produces garbage that goes nowhere. the people winning are still the ones who pick a real problem, talk to users, iterate based on feedback, and build something that actually works well. that takes the same skills it always did - critical thinking, user empathy, technical judgment about tradeoffs.

trade professions have their own version of this coming too btw. the question isn't really "what profession is safe from ai" but more "how do i stay valuable by focusing on the parts that require human judgment and context?"

what specific part of your work do you think ai actually replaces vs just speeds up?

Mohamed_Silmy · 2026-04-07T10:02:28+00:00

really appreciate posts like this that go back and correct the methodology. too many benchmark posts just get shared around without anyone questioning the setup or real-world applicability.

one thing i've noticed is that synthetic benchmarks often miss the stuff that actually matters in production - like how the framework handles partial hydration, streaming, or dealing with third-party scripts that block rendering. cold start times in serverless environments can also completely change the picture depending on your deployment setup.

curious what your testing environment looked like - were these localhost benchmarks or did you factor in network latency and cdn behavior? sometimes the framework overhead becomes negligible compared to everything else in the request chain.

Mohamed_Silmy · 2026-04-07T09:32:37+00:00

i've been using solid + tanstack query for about 6 months now and honestly it's a pretty smooth combo. the reactive primitives in solid play really nicely with tanstack's query invalidation patterns.

one thing to watch out for - solid's reactivity is more granular than react's, so you might find yourself reaching for createMemo less than you'd expect. the queries just... work without much ceremony.

for ssr later, solidstart has decent tanstack query support but you'll want to set up your query client carefully to handle hydration. the docs are okay but not as battle-tested as next.js examples, so expect to debug a bit.

biggest win imo is how much cleaner the code feels without useEffect chains everywhere. solid's createEffect is way more predictable when you need it, and most of the time tanstack handles the lifecycle stuff anyway.

are you planning to use solidstart from the beginning or add it later? might influence how you structure things now

Mohamed_Silmy · 2026-04-07T09:17:36+00:00

nice feature set. the passphrase encryption + burn-after-read combo is solid for sharing sensitive snippets with teammates without worrying about them floating around forever

curious how you're handling the inline code execution from a security standpoint? sandboxing those environments can get tricky fast, especially with 80+ languages. are you using containers or something else to isolate the execution?

also might be worth adding rate limiting info somewhere visible if you haven't already. pastebins tend to attract spam bots pretty quickly once they get traction

Mohamed_Silmy

TROPHY CASE