Hello! I am a software developer with eight years of experience developing software on both the back and front ends. Check out my linked resume for a short list of my primary accomplishments and I hope to hear from you soon!
Brave is a solid option if you don't want to leave the underlying Chromium and it's extension ecosystem but still have privacy capabilities that Google is axing with Manifest v3.
Firefox is also a solid option. Firefox is one of the few stable options remaining to use a non-Chromium based browser. Most popular Chrome extensions have Firefox releases as well so you may not even lose that functionality in a switch.
Advocates for Firefox frequently point out that part of how we got here with the Manifest v3 issues is by consolidating browser technologies. Chrome, Brave, Edge, etc all use the Chromium core which is part of what gives Google such a strong ability to influence web technology developments to their advantage and our detriment. If this is something you care about then it may be worth voting with your feet and giving Firefox a chance.
The new DDG browser may be interesting in this regard. It uses WebKit at least on Mac, but we'll see how their Windows version ends up like. Could very well be Edge WebView2.
> But we understand some folks want to continue using third-party password management across browsers and devices. So, we’ve teamed up with Bitwarden, the accessible open-source password manager, in the first of what we hope to be several similar integrations. In the coming weeks, Bitwarden users will be able to activate this seamless two-way integration in their browser settings.
We've got AI assisted rotoscoping already and while it looks a bit janky at times its still a whole lot faster than doing it all by hand. https://www.youtube.com/watch?v=tq_KOmXyVDo
Interesting - is it still faster when the artist endeavors to correct the AI jankiness where it occurs? Or at the present day is it more trouble than it's worth?
I disagree that TypeScript comes with only a marginal upside. In my experience TypeScript projects are much more approachable for contributors.
For example, I once was debugging an issue in a JS framework and while I knew what was wrong and where I could fix it I didn’t have any idea what existing tools I had available in that context to fix it. Having type definitions would have made that work much simpler by increasing the accessibility of the code base.
It’s experiences like this that have convinced me that if I’m writing code that any one will possibly read or need to modify later (including if it is just me) then I should be writing TypeScript instead of JavaScript. Or, more generally, that it should be typed.
Raw JavaScript in any production app is an abomination. Constant issues because one of the variables had a errant character. Countless bugs because of the same or it not being defined. On top of all that how in the hell am I supposed to know what a parameter or return value is supposed to look like? I have other things to worry about. I think these type annotations would make everyone happy. The IDE can navigate and inform but the objects will still need to be defined somewhere. I assume we can define a custom type with these annotations?
You and OP are both right, because it really depends on what you're doing.
At the scale I operate, it would be corporate suicide to try and write this code in straight JavaScript without type support. But for smaller teams, more focused teams, and teams that use a heavy testing discipline or enforced naming conventions that supplement the lack of static typing, it's not a problem.
Your basic disagreement here feels like it would be obviated by the parents "I hope this makes its way into the ECMAscript spec"? I.e., you would get typing without any of the tooling Typescript requires; the parent's point was JS + typing would be a pure benefit compared to Typescript, and you've said nothing to disagree with that.
So while you technically are disagreeing with the parent, it's on the smallest of points, and completely disregarding the main one the parent offered (which, fair enough, but wanted to point that out)
What does "while I knew what was wrong and where I could fix it I didn’t have any idea what existing tools I had available in that context to fix it" mean?
I couldn't disagree more with you... All i see when working with different levels of experienced contributors is param:any any[]. Even more when you want to interact directly with DOM instead of using an opinionated framework.
This is either just code that is too complicated or devs that aren't doing a good job of type hinting.
Everytime there is an any, it means that each developer reading or modifying this code has to find it out for themselves - every single time. Why not just type hint it correctly in the first place.
I'm one of those `any` developers, and can attest to the first scenario. Had a client ask me to fix a bug in a repo that I wasn't familiar with. I spin it up, start looking through the code, and it's this massively over-engineered beast. 27K lines of Angular code to support a 2 page SPA that's basically just a note taking app.
Anyways, it's TS, and I don't know TS but I know how typing works so I can make my way around. I need to alter an interface to fix the bug, but with all the code it's very difficult to tell whether the change will break something either in the compiler or at runtime. To add on top of all that, the client needed the change to go out that day.
So guess what's going to happen? I'm using fucking `any` and I don't care.
Ultimately, this is why I don't like TS. I think it's a great idea, but if you look at all the energy that has been spent moving code over to TS from JS, and all the type definitions that were written into existing NPM packages, I have to ask myself why we don't just pursue making types native to JS? I don't want to write a secondary language that compiles to JS.
> Anyways, it's TS, and I don't know TS but I know how typing works so I can make my way around. I need to alter an interface to fix the bug, but with all the code it's very difficult to tell whether the change will break something either in the compiler or at runtime. To add on top of all that, the client needed the change to go out that day.
It is massively easier to make change to large TS codebase. Just because you never bothered to learn TS and you rush feature at cost to maintenance, do not mean it is TS fault.
> Ultimately, this is why I don't like TS. I think it's a great idea, but if you look at all the energy that has been spent moving code over to TS from JS, and all the type definitions that were written into existing NPM packages, I have to ask myself why we don't just pursue making types native to JS? I don't want to write a secondary language that compiles to JS.
Because native types would create even more fragmentation while being less powerful than TS. JS was never intended for application development, we either embrace compilers or move away from language that have pathetic standard library, dynamic and complex type coercion rules, no stable module system, lack of strong leadership and legacy of supporting IE.
As an aside, I’m increasingly convinced that Fedora is probably the best Linux distro around right now for both enthusiasts and beginners.
Great stability. Close to the edge of progress. And they focus on delivering real unique value on top of what others have created as opposed to reskinning and hacking Gnome.
I’ve never used Fedora but I’m keen on moving over my personal desktop the next time I have a couple of days to mess around with it.
The “users voted with wallets” / “free market decided” line often ignores how consumers are not choosing in a vacuum or choosing simple things or sometimes not choosing at all.
Often choices are made for short term benefits that come with a long term negative trade off. ie choosing features like a phone camera even though the device also disregards the user’s privacy.
In other cases, choices aren’t even made by consumers directly. Like when a company acquires potential competition before they’re able to grow into a threat. Or even a company uses their growing economic power and position for regulatory capture.
Sometimes a company just breaks away from their competition and end up the only competitive choice in the market and are able To cement their position through the means above.
Especially following the previous cases, users sometimes don’t choose at all because there remain no meaningful choices in the ecosystem they purchase in.
I'm 100% with you on the "not even sure what spiritual means as I've never heard a coherent definition". If anyone is interested, this position is known as theological non-cognitivism, ignosticism, or igtheism
> Theological noncognitivism is the non-theist position that religious language, particularly theological terminology such as "God", is not intelligible or meaningful, and thus sentences like "God exists" are cognitively meaningless.
> Ignosticism or igtheism is the idea that the question of the existence of God is meaningless because the word "God" has no coherent and unambiguous definition.
Remote: Yes (Hybrid maybe)
Willing to relocate: No
Technologies: TypeScript/JavaScript, NodeJS, Deno, npm, Microservices, React, Docker, Kubernetes, SQL, CI/CD, Neovim, bash, automated testing, API design, developer tooling design
Résumé/CV: https://keithwade.com/about/
Email: hello@keithwade.com
Hello! I am a software developer with eight years of experience developing software on both the back and front ends. Check out my linked resume for a short list of my primary accomplishments and I hope to hear from you soon!