336 karma · joined March 29, 2023
Trying to decide between the two atm.
But yeah you need to make attempts to apply what you’re learning and answer questions on your own. You can’t simply watch problems being solved (whether by an AI or a person) and retain it.
Written specifications are being reduced in favor of these working prototypes, and now there’s this extra cognitive burden of reading the code and trying to determine what were the intended changes, and what’s the slop that needs to be tossed aside.
We also have to figure out, should we take over this generated PR and make any needed changes? Or do we start over from scratch? There’s often a sense of friction either way.
There have been times where a bunch of unintended changes were generated and I took time to port them over on my reimplementation, and then later on it’s “oops! Sorry! We didn’t mean to change that.”
I get it’s empowering but it does take away from some of the joy I used to find in my work and replaced it with some headaches.
For example on instagram you might click through to a post from the explore page or from someone sending it to you via DM. In either case pressing the back button rendered in the app, or swiping back, will take you back to where you came from. It feels natural and seamless. Although I guess there are other ways to skin that cat than history.back()
But I agree with you when there’s a clear hierarchy. Like on a job ad a “back” button should just be a normal link to the index of job openings.
The problem is that you cannot introspect the browser’s history with the history API. So you have to hack your way around that if you want the “go back in history if possible, otherwise navigate to fallback url” behavior. Which I guess is easier if you’re in a react SPA. Or if you’re fully a MPA and can just check document.referrer
There’s a brand new Navigation API that does let you introspect history entries from the same origin, which perfectly addresses the issue.
I wrote a polyfill in order to take advantage of the navigation API for this exact problem: https://github.com/kcrwfrd/navigation-ponyfill
The problem with just calling history.back() with no fallback is it will bounce users out of your app (back to Google or wherever they came from) and PMs won’t like that…
Compared to previous paradigms, React lets you compose complexity and rich interactivity really, really well. Even for all its flaws.
The ergonomics in my day to day work are quite nice. To me, the better boundary of abstraction shifted to components, rather than the html/css/js “separation of concerns” that some of the older folks still like to parrot.
However, take a look at the markup and styling for the https://maps.apple.com/ web property.
I can’t deny that it’s quite beautiful and easy to holistically understand. Especially when it comes to the responsive styling—which is when I tend to find tailwind most awkward.
It’s my favorite example of “traditional” CSS structure in recent memory that has given me some pause when it comes to Tailwind.
Boards of Canada
Mr. Robot Original Soundtrack
They used to have a “Dr. Paul's Raw Animal-Based Smoothie” that I looooved, but unfortunately they stopped making it. Still sad about that one :(
Yabai supports this perfectly (especially combined with instant, animation-free space switching) but it requires disabling system integrity protection--which is a non-starter on a work computer.
Aerospace solves it with their own spaces implementation.
I was able to put together a hammerspoon script that does the job decently enough for my purposes: https://gist.github.com/kcrwfrd/6f3dcaec0e08e0e77b2884588a34...
It looks like a nice display, but that’s a deal killer for me.
I like that I can have some vaults that sync to both my personal and work laptops and other vaults that only sync to one or the other.
It’s awfully convenient without any vendor lock in since I can just take my plain markdown files and leave anytime.
Along with syntax highlighting.
Now I’m entirely invested, what was the problem causing the crashes? How did they solve it?
I believe you can see it working on TikTok web as well.
You just can’t have the first video unmuted on initial load, although I wonder if this can be relaxed when user installs a PWA.
I am somewhat fearful of having created a monster, but at the same time I think it’s good to knock down barriers to knowledge and learning. All else equal, I think a designer or PM with some exposure to code is better than one without.
What I’m fearful of are 10k line PRs and pressure from product to “just ship it.” Past a certain threshold a PR will be really tough to review, to the point that it would be preferable for an engineer to have handled it from the start.
I think we will need deeper integration between figma and the codebase/storybook. Shared color palette definitions, integration of storybook components with figma components, stuff like that.
The Figma MCP that you can use to handover to your agent and simply say “implement this” is already pretty impressive.
Dead middle is decent too.
5120x3200 in 30” would be awesome.
I've been super hyped about it. My main goal at first was supporting `navigation.canGoBack` and the `currententrychange` event simply so that I could implement perfect back buttons with (almost) zero edge cases. This is surprisingly very tricky with the older History API.
Today I just opened a PR with support for `entries()` and `currentEntry`: https://github.com/kcrwfrd/navigation-ponyfill/pull/33
Once that lands I'll be able to start thinking about implementing full-blown navigations with it, with cool stuff like navigation interceptors and whatnot. That would actually enable framework router implementations wholly based off the Navigation API, rather than simply patching some enhanced capabilities for use with a router based on history.pushState / history.replaceState.