Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API

From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "mobile responsiveness"
-
Manager: What’s taking so long on that PR?? It’s just some small styling adjustments
Dev: No it’s not you added an entire new calendar module that doesn’t work
Manager: Ok but besides that it’s just a small couple of css edits
Dev: You made styling changes in 50 files, half of which break our mobile responsiveness
Manager: Well then STOP talking to me and FIX IT if you’re so smart.
Dev: You also added a series of filters on a table in this same PR that cause th—
Manager: OK SO I GOT A BIT DISTRACTED THE FACT IS IT ALL NEEDS TO GET DONE SO IT DOESN’T MATTER IF IT’S ALL ON ONE PR SPLITTING THINGS UP INTO SMALL UPDATES IS JUST UNNECESSARY BUREAUCRACY AND IF YOU LIKE THAT THEN GO. WORK. FOR. THE GOVERNMENT!!!
Dev: …10 -
It's enough. I have to quit my job.
December last year I've started working for a company doing finance. Since it was a serious-sounding field, I tought I'd be better off than with my previous employer. Which was kinda the family-agency where you can do pretty much anything you want without any real concequences, nor structures. I liked it, but the professionalism was missing.
Turns out, they do operate more professionally, but the intern mood and commitment is awful. They all pretty much bash on eachother. And the root cause of this and why it will stay like this is simply the Project Lead.
The plan was that I was positioned as glue between Design/UX and Backend to then make the best Frontend for the situation. Since that is somewhat new and has the most potential to get better. Beside, this is what the customer sees everyday.
After just two months, an retrospective and a hell lot of communication with co-workers, I've decided that there is no other way other than to leave.
I had a weekly productivity of 60h+ (work and private, sometimes up to 80h). I had no problems with that, I was happy to work, but since working in this company, my weekly productivity dropped to 25~30h. Not only can I not work for a whole proper work-week, this time still includes private projects. So in hindsight, I efficiently work less than 20h for my actual job.
The Product lead just wants feature on top of feature, our customers don't want to pay concepts, but also won't give us exact specifications on what they want.
Refactoring is forbidden since we get to many issues/bugs on a daily basis so we won't get time.
An re-design is forbidden because that would mean that all Screens have to be re-designed.
The product should be responsive, but none of the components feel finished on Desktop - don't talk about mobile, it doesn't exist.
The Designer next to me has to make 200+ Screens for Desktop and Mobile JUST so we can change the primary colors for an potential new customer, nothing more. Remember that we don't have responsiveness? Guess what, that should be purposely included on the Designs (and it looks awful).
I may hate PHP, but I can still work with it. But not here, this is worse then any ecommerce. I have to fix legacy backend code that has no test coverage. But I haven't touched php for 4 years, letalone wrote sql (I hate it). There should be no reason whatsoever to let me do this kind of work, as FRONTEND ARCHITECT.
After an (short) analysis of the Frontend, I conclude that it is required to be rewritten to 90%. There have been no performance checks for the Client/UI, therefor not only the components behave badly, but the whole system is slow as FUCK! Back in my days I wrote jQuery, but even that shit was faster than the architecuture of this React Multi-instance app. Nothing is shared, most of the AppState correlate to other instances.
The Backend. Oh boy. Not only do we use an shitty outated open-source project with tons of XSS possibillities as base, no we clone that shit and COPY OUR SOURCES ON TOP. But since these people also don't want to write SQL, they tought using Symfony as base on top of the base would be an good idea.
Generally speaking (and done right), this is true. but not then there will be no time and not properly checked. As I said I'm working on Legacy code. And the more I look into it, the more Bugs I find. Nothing too bad, but it's still a bad sign why the webservices are buggy in general. And therefor, the buggyness has to travel into the frontend.
And now the last goodies:
- Composer itself is commited to the repo (the fucking .phar!)
- Deployments never work and every release is done manually
- We commit an "_TRASH" folder
- There is an secret ongoing refactoring in the root of the Project called "_REFACTORING" (right, no branches)
- I cannot test locally, nor have just the Frontend locally connected to the Staging webservices
- I am required to upload my sources I write to an in-house server that get's shared with the other coworkers
- This is the only Linux server here and all of the permissions are fucked up
- We don't have versions, nor builds, we use the current Date as build number, but nothing simple to read, nonono. It's has to be an german Date, with only numbers and has always to end with "00"
- They take security "super serious" but disable the abillity to unlock your device with your fingerprint sensor ON PURPOSE
My brain hurts, maybe I'll post more on this shit fucking cuntfuck company. Sorry to be rude, but this triggers me sooo much!2 -
On my first week in the internship, I have to create a small website and it has to be finished ASAP. So I used Bootstrap.
After finishing I tested the website in chrome debugger tools for every screen size (design responsiveness), it was working fine. My stupidity was that I haven't tested on actual mobile/tablet.
The site was live, I send the link to one of my friends and he said "why everything is so small? looks like I'm browsing on PC". I quickly grab my phone and visited the site and it was not responsive on mobile. Started to check the code again, tested again on chrome tools it was working. But not on mobile. Changed the bootstrap file but no fucking changes on mobile.
After few moments of thinking, I realized that I haven't included the "meta viewport" tag. I felt so stupid and it was kind of embarrassing for me.
Now I first include meta tags before working on new project.5 -
<meta name="viewport" content="width=device-width, initial-scale=1">
After trying to figure out why the examples were working on the site, but not on my page, finding out this was the problem left me with one reaction:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH1 -
Going through site after senior dev asked front end dev to go through it and tweak it for design and better responsiveness(he and I are back end oriented and have no design skillz).
Things are breaking visually on almost all devices.
Client sends an email saying it suddenly looks terrible on mobile and wants to know what happened. I let him know we were actively working on things and it should be good in a few minutes.
Looking over CSS...there are "!important" tags EVERYWHERE, media queries are in the wrong order and have "!important" attached to almost everything so the largest screen size settings win.
Why do I even bother?2 -
To my client who wants a two-column formatted email built with tables in Constant Contact to appear in the same two-column format on mobile devices: You're lying when you say your previous developer achieved a legible, mobile, tiny screen email this way. I know because I can see the previous email formatting. In fact, I cloned that exact email and merely swapped out the content. You really do not understand what you're asking for.4
-
Lol. Of all the dev social media, like Dev.to, Hashnode, stack overflow etc .. I find that the most help I get is RIGHT FUCKING HERE BABY. So I'm at it again, asking for help in the form of a question. I'm still looking to get a frontend job. My question is, is a short and sweet e-commerce website, mostly showcasing the ability to code a design, so not fully functional but has great JavaScript and React features in it, like mobile responsiveness, slide nav, item filter, sale price, add to cart animation, pagination, etc..a good resume project that can get you hired? I'm having a hard time finding which if my projects are good, or embarrassing to recruiters.7
-
🚀 “I Wanted GitHub Copilot in My Pocket — So I Built It Myself”
For years, I’ve had this weird habit of coding from random places — cafés, buses, hospital waiting rooms, you name it. But every time inspiration hit, I found myself thinking the same thing:
“Man, I wish I could just use Copilot on my phone.”
It’s 2025. We’ve got AI writing novels, generating music, and summarizing 500-page research papers in 2 seconds — yet somehow, GitHub Copilot still refuses to leave the comfort of VS Code on desktop.
So I decided to fix that.
💡 The Idea
It started as frustration — a “wouldn’t it be cool if” moment. I was halfway through an idea for a small project on a train, and my brain screamed:
“Why can’t I just ask Copilot to finish this function right now?”
VS Code was sitting at home, my laptop was dead, and all I had was my phone.
That night, I scribbled this into my notes app:
“Bridge Copilot from VS Code → phone → secure channel → no cloud.”
At the time, it sounded insane. Who even wants to make their life harder by reverse-engineering Copilot responses and piping them into React Native?
Apparently — me.
🧩 The Architecture (aka “How to Lose Sleep in 4 Easy Steps”)
The system ended up like this:
VS Code Extension <-> WebSocket <-> Discovery API (Go + Redis) <-> React Native App
Here’s how it works:
The VS Code extension runs locally, listening to Copilot’s output stream.
A Go backend acts as a matchmaker — helping my phone and PC find each other securely.
The mobile app connects via WebSocket and authenticates with a 6-digit pairing code.
Once paired, they talk directly. No repo data leaves your machine.
It’s like a tiny encrypted tunnel between your phone and VS Code — only it’s not VPN magic, just some careful WebSocket dancing and token rotation.
🛠️ The Stack
Frontend (Mobile): React Native (Expo)
Backend: Go + Redis for connection brokering
VS Code Extension: TypeScript
Security: JWT + rotating session keys
AI Layer: GitHub Copilot (local interface)
🧠 The Challenges
There’s a difference between an “idea” and a “12-hour debugging nightmare that makes you question your life choices.”
Cross-Network Discovery:
How to connect phone and desktop on different networks?
→ A lightweight Redis broker that just handles handshakes.
Security:
I wasn’t making a mini TeamViewer for hackers.
→ Added expiring pairing codes, user-approval dialogs, and local-only token storage.
Copilot Response Streaming:
Copilot doesn’t have a nice public API.
→ Hooked into VS Code’s Copilot output and streamed it over WebSocket.
(Yes, 2% genius and 98% madness.)
UX:
The first version had a 10-second delay.
After optimizing WebSocket batching and Redis latency, it’s now near-instant.
🤯 The “Holy Sh*t, It Works” Moment
The first time my phone sent a prompt — and my VS Code actually answered with Copilot’s suggestion — I legit screamed.
Like, full-on victory dance in the middle of the night.
There’s something surreal about watching your phone chat with your desktop like they’re old coding buddies.
Now I can literally say:
“Copilot, write me a REST API,”
and my phone responds with fully generated code pulled from my local VS Code instance.
No VPN. No cloud syncing. Just pure, geeky magic.
⚡ The Lessons
The hardest problems aren’t technical — they’re psychological.
Fighting “this is impossible” is the real challenge.
Speed matters more than perfection.
Devs don’t want beauty; they want responsiveness. Anything over 1s feels broken.
Security must never be an afterthought.
I treated this like a bank tunnel between devices, not a toy.
Build for yourself first.
I didn’t make this for investors or glory — I made it because I wanted it.
That’s the best reason to build anything.
🧭 The Future
Now that it’s working, I’m turning this experiment into something shareable.
The dream: an app that lets every developer carry Copilot wherever they go — safely and instantly.
Imagine debugging on your couch, or editing code in bed, or just whispering to your AI assistant while waiting for coffee.
Phones today are more powerful than early NASA computers.
Why shouldn’t they also be your code editor sidekick?
So yeah, that’s my story.
I built VSCoder Copilot — because I wanted to code from anywhere, and I refused to wait for permission.
If you’ve ever built something just to scratch your own itch, you already know this feeling.
That mix of frustration, caffeine, and late-night triumph that reminds you why you fell in love with coding in the first place.
Because at the end of the day, that’s what we do:
We make ideas real — one ridiculous hack at a time. 💻🔥9