[ Removed by Reddit ]
[ Removed by Reddit on account of violating the content policy. ]
[link] [comments]
[ Removed by Reddit on account of violating the content policy. ]
| Hey. I added two pictures of a UI. Ignore all the stuff other than inputs and buttons, the other elements are just there to give you a feeling as if its baked into a UI. My question is, if you like the 36px-version (tinier first one) more or the 40px-version (bigger second one). Im thinking of migrating my package from 40px to 36px. [link] [comments] |
Just curious how you guys do it because I've definitely been in a place where the client took advantage of certain things which were not mentioned.
Are you guys using any software or something?
Hey everyone, I am a developer and I have faced this problem many time which is even when i give ai proper context, the small changes can get annoying. move this text a little, make that image smaller, fix the spacing... sometimes it doesn't understand what i mean or does something different from what i wanted. then it's more explaining, more prompts, more tokens burned.
so i started building this. what if ai creates the website, and we just adjust the little things ourselves?
you click something on your website, move it, resize it, edit the text or change an image, and it saves that change directly into your code. no digging through files and tweaking margin and padding values just to see whether it looks right.
you can also preview desktop, tablet, and mobile together and see how things look across them. for supported changes, you choose whether to change only that screen size or apply it everywhere. so adjusting something on mobile doesn't have to mess up your desktop layout, it depends on what you choose.
right now it has:
- drag, resize, and text editing
- image and background changes, including uploads from your device
- movable device previews with canvas zoom
- controls for selecting a whole container or individual things inside it
- edit history and undo/redo
- HTML support, with experimental React and Next.js support
the video shows where it's at. it's still in the initial stage, and there's a lot to fix and refine, including expanding which edits can be made separately for each screen size.
honestly, idk if other people need this, but making the change i'm picturing instead of explaining it again feels useful to me.
would you use something like this? and should i open-source it so we can build it together, or would you rather just use it once it's more polished?
Also any ideas to add then feel free to say.
| A browser-side chaos-testing tool that installs a Service Worker to intercept requests across every controlled tab and apply latency, failures, throttling, rate limits, and mock responses without changing app fetch calls (similar to MSW). It uses the same middleware configuration model as chaos-fetch, so you can test real frontend behavior under degraded network conditions without rewriting the app to use a special client wrapper. [link] [comments] |
I'm tired of building complex filter UIs just for users to ignore them, type "shirt" into the search bar, get 400 results, and instantly bounce. our backend retrieval is actually really fast, but the human query formulation is awful.
Instead of writing 500 lines of custom debounced react filters to try and force them into categories, I'm looking at intercepting the keystrokes with an intent layer on the frontend. basically an ai-autocomplete that formats their vague text into a structured JSON payload before it ever hits the API.
Has anyone used frontend intent layers to fix vague search? looking at commandbar vs just dropping in a lighter ai-autocomplete hook.
Hey. Currently working on a DateRangePicker and need your opinions. Do you think the second-date-invalidity I show currently by making the second selection-cell red with an icon is good or do you think i should just mark all invalid fields as disabled after the first date is selected?
I have been reached out for the Frontend SWE l4 role at Google, can someone share with me what kind of questions to expect in the frontend interview also where to prepare it from, i have worked on frontend but I dont think i know it in depth specially now when most of the work is AI led, so any resources to prepare would be helpful. Also there is supposed to be 2 dsa rounds later afaik, does anyone know what level of questions to expect in that. Also how long do you think they provide to prepare for these, i dont want to take too long but i also dont want to be underprepared. I have searched alot regarding Frontend l4 interviews at Google but i didnt really find much data, so if anyone can help that would be great.
Feels like well over half my week now is reading through components and styles a model generated and deciding what to keep. Reviewing's a real skill, fine, but the tooling is rough, I'm scanning a wall of JSX and CSS trying to spot what changed, with no clean way to accept this chunk and throw out that one. Is anyone on a review loop that feels like a real diff for generated UI, or are you all just eyeballing the whole component every time?
Building Cashvelope was a massive personal challenge. I wanted a true envelope budgeting app that put data control back in the user's hands.
Working on this late at night after my main work hours meant dealing with severe burnout, redesigning local data structures three times, and fighting through backend edge cases solo. Building a app end-to-end alone is a completely different beast than writing code for a client.
To fellow devs who built and released your own side projects:
How do you balance feature scope creep with actually getting the app across the finish line?
hi! I didn't think I'll need that in my life, but I very need to know how to use CSS properly. I mean what are the differences between one thing and another, what's more popular to use etc. So, I'm trying to relearn CSS.
For the context: I learned CSS in 2022 only to pass the exams and that's all, and then I was like "yahoo! I won't return to the web design ever again!". So, I can use the atributes with classes, id etc, but I can't understand what are the important things to properly use them. I didn't think I'll need to program projects related to web programming. I find JS and PHP quite easily to understand, bcz every thing has one meaning there. It was a bit hard to understand HTML for the first time, bcz I thought every tag has its own function, but when I understood that plenty of tags are semantical and I can just use <div> and <span> if I want, I started to use the semantical tags properly. CSS is the hardest part in Front-End for me, bcz Idk if plenty of things are similar to the HTML ones(an atribute is optional and it depends on you if you want/need to use that) or the programming languages(1 thing = 1 meaning).
Here are my questions about CSS to understand it better:
I hope I didn't forget anything, but if I did, I'll make a new post about them
Edit: I can't change the title, but I meant questionS*
we went from a small team to 20+ and release QA scaled worst. more devs shipping more Al-generated code meant more flows to re-verify before each release. it ate real hours. my weekends too. adding people didn't help. the verify work grew faster than the team.
we put the verify step inside the agent loop using testsprite CLI. the agent runs a real session against the live app. when something breaks it gets a failure bundle it can act on and rerun. cloud account was a mild pain to sort out. passing checks pile up into a suite that sticks around so coverage builds as we ship.
people still own the judgment calls and the fuzzy edge cases. moving the routine verify work into the loop stopped release QA from tracking headcount. how are other founders keeping QA cost flat while the team grows?
| We've been heads-down on SvGrid for a while and it's finally at the point where we want it in front of people who actually ship Svelte apps. It's written for Svelte 5 directly. Runes, no wrapper around a framework-agnostic core, no adapter layer. That was the whole reason to start. Every capability is off by default, so a bare Underneath: virtualized both directions so a million rows scrolls fine, Excel-style filter menus, inline editing, grouping with aggregation, tree data, pivot, and a server-side row model that pushes sort/filter/group down to your backend instead of pretending your dataset fits in memory. SSR renders the header plus a viewport window of rows. About 2 KB gzipped for the headless core, 77 KB for the full render component, 9 KB CSS. The part we didn't plan. A grid needs cell editors. Cell editors need date pickers, comboboxes, tag inputs. Those need a popover layer and focus management. We looked up and had 84 components. You can poke at any of them without making a project first: That caches a tiny Vite sandbox and opens your browser, with a theme picker so you can see it in whatever you're actually using. Licensing, since it always comes up. The grid, the UI components, the web component build and the MCP server are MIT with nothing gated. No license key, no watermark, no row cap, no console nag. We charge for Excel/PDF export, Excel import, print, and the Kanban and scheduler renderers. OSS projects get those free, just send us a repo URL. Where it's weak. The grid has been in production a while. The UI components are much newer and haven't been beaten on anywhere near as hard. If you find something broken we'd rather hear about it than not. Context on us: we're the jQWidgets team and we've been shipping UI components since 2011. This is the first thing we've built Svelte-first rather than framework-agnostic, and that bet is what I'd most like opinions on. Going deep on one framework buys you a much smaller API, but you'll never see us in a React thread. Two things I'd take from this thread:
https://i.redd.it/bni8lzz54xmh1.gif Repo: github.com/sv-grid/sv-grid [link] [comments] |
i’m working on a scraper for several sites and the current proxy pool gets flagged pretty quickly, looking for a residential setup with reliable ip rotation, what are you guys using for larger scraping projects?
| The UI stays unobtrusive while we treat accessibility as non-negotiable. There is no bail-out, because we believe that software should be available to everyone. There has been done a lot of work in fully supporting WCAG 2.2, and I'm really proud of the result. The grid is now one of the most performant, most accessible enterprise type DOM based grids on the planet, supporting a ton of opt-in features, and it's MIT licensed. [link] [comments] |
Hello, so im going over an old website I made back when I first started developing, and silly me decided to build the entire thing with "position: relative, right: -233px" 😭
Am I going to have to redo the entire site CSS to flexbox so it doesnt move about on different screen sizes, or is there an easier way to save this site?