I've been working on an iOS app to help my mom keep track of major awards and film festivals: https://awardedapp.com
I had this project for a while in the back burner, and like many of you over the holiday I went back to it with the help of Claude Code... it's been a lot of fun.
I agree with you completely. I am confident on my ability to work in both JS and TS (or PHP, or Ruby, or [insert language here]), in the end they are tools, and what defines the quality of a candidate is much more broad and sometimes nuanced.
I'd love to get the perspective of someone hiring for roles where TS-experience is a strong requirement, especially if they ever had experience hiring devs with JS-only experience for senior roles.
I'd like to get excited about WebGPU as well, but I am lacking enough imagination here. Games? 3D animations? What else beyond these obvious applications?
Those who are excited about it: why? what are you planning to build with it?
We use rrweb as a DOM-recorder in our extension, and it does come with some limitations. Taken from our docs:
- DOM recording has the fundamental trait that nothing outside the DOM can be recorded. This latter limitation means that only content on the specific page is recorded: Data in popup dialogs or other tabs is not recorded, neither is anything outside the HTML document like native MacOS/Windows menus shown for native HTML selects.
- On top of that, some embeddable elements like <canvas> are not recorded (e.g. Google Maps, Figma).
- When playing back DOM recordings, there can be visual glitches, like duplicate elements being shown. Even when there’s no obvious glitches, a DOM recording is unlikely to look exactly like the page as experienced by the session reported.
- Security configuration like CORS on the recorded site’s hosting, and Bird’s own CSP policy can prevent the loading and rendering of embedded elements, like the original page’s font.
- Because DOM recordings don’t include all information (e.g. image files are only linked to), DOM recordings can drift apart from the time of the recording in fidelity over time, if the content of the asset behind the URL changes, or even degrade, or when the assets are no longer accessible at all at the URL.
Having said that, we found that rrweb is quite reliable on most situations and works well for most of our users.
Replay.io is a different beast altogether. They implement their tooling on their own browser (Chromium-based), so they have access to much more precise data than a JS-library like rrweb does. More info here: https://blog.replay.io/how-replay-works
After nearly a decade working in architecture (buildings, not software!), and having reached quite a comfortable position and salary within my company, I decided I wanted more flexibility in my life.
I threw ideas for 80% work time, or 1-day work-from-home (pre-pandemic), to my boss at the time, but was always met with resistance (“architects cannot work from home!” or “you are too important and need to be around all times!”).
I quickly realized my future there was “either accept it or leave it”. So I left and after some months trying to figure out my next move, I decided to take my chances in tech on a remote job (had extensive experience coding throughout my life as a hobby).
My first job in tech, 4 years ago, paid me half of what I was making in architecture. I never looked back. Got a dog, went traveling around while working, made my own schedule, never felt more free or happier.
Today, I am making more than my last salary in architecture and can never imagine working 9-5 in an office again in my life.
I had this project for a while in the back burner, and like many of you over the holiday I went back to it with the help of Claude Code... it's been a lot of fun.