The new #github based on #react is an abject failure to improve the user experience. On every count it is objectively worse than previous iterations.
Page load time is poor, interactivity is gated seemingly on very large JS loads. Initial page layout is broken on mobile and randomly resizes the width of the viewport after loading. The number of micro-annoyances seem to be adding up daily.
This is like an object lesson in what not to do to your successful webapp.
I'm currently available for code reviews, technical advisory roles and consultancy work.
I've lead development on countless products & services; I'm most experienced in javascript/typescript & node.js but can also advise on general technical strategy.
By hiring me for short contracts, you'll help me to keep working on Fediverse trust & safety!
I’m on the market for a staff/principal role. I have a passion for #SoftwareArchitecture, Developer Experience, community, mentoring, #performance, and interacting with business and domain experts.
I've been in this industry long enough to see things constantly come & go. #React is no different - it'll be replaced by other frameworks soon & those will be hot for a bit. Then that one will be replaced & so on. Learn your basics! #HTML#CSS, plain#JS. Those are the only things that don't come & go & will take you through your entire career, regardless of what's cool right now. Will I still be coding #WordPress in 10 years? Who knows! But my knowledge of #PHP will carry me on.
If anyone's hiring a mid-level or associate software engineer (react / node.js / solid) remote (Germany), I highly encourage you to get in contact with @yesvirginia, who's just parted ways with Inrupt, where we worked together.
She's looking for her next role, must be remote, and minimum salary ~€75-80k.
She's not just a talented developer, but also a huge people person, often driving positive change, and is running for the Chair of the Solid CG.
even though React has been my bread and butter for the last 5-6 years—and will continue to pay my bills for a long time—i wouldn't recommend starting a greenfield frontend project with in 2024.
the framework now has too many bugs, too much legacy, too many fundamental design flaws (e.g hooks), and is growing in a direction that nobody except Vercel cares about. the core team doesn't care about real-world scenarios, and is focused on building a product that's too clever for its own good.
i don't know what the alternative to React is, yet. but there's one thing i can say confidently: invest in HTML, vanilla JS, Web Components, and plain old CSS. they will outlast every frontend framework in existence.
Is anyone looking for a little extra development help? I've been struggling to find projects lately.
I've been building Web sites & UIs since the early 00s. I worked back through the stack with PHP & Node. I use NextJS, React, Laravel, some Vue. I'm learning Qwik.
I’m UK-based, experienced at remote. I can mentor/advise or be a CTO sounding board. I'm open to one-off, short or long term projects.
#react: Ok, so you probably don't just start with React. You want Next, or maybe Remix, for starters. After that, you're gonna want Tailwind, which means you'll probably want classnames or tailwind-merge...maybe both. Or you could just go with styledComponents. Anyway, be sure to have Redux, along with Redux toolkit, and React Query. After that, it's just a matter of micromanaging the framework for desired performance!
#svelte: Go with SvelteKit. It has everything you need. Have fun!
My engineering team inside the WP Engine marketing department is looking for another dev to join us! Someone into modern #WordPress dev, but also knows their way around #React, with a can-do attitude in a fast paced environment. Who's interested?
Once again I get foiled by switching languages. :blobcatfacepalm2:
In Javascript, you have to compare strings with ===, not ==, or else you'll run into type coercion problems, because Javascript thinks 1 == "1" is a totally fine thing to be true. (it's not)
But in Kotlin, === compares identity not equality for strings. But in the JVM, string values are aggressively cached, so === actually does what you want most of the time. Unless your strings come from weird places, like JNI code. Then you get awful non-deterministic behavior that's incredibly hard to debug, but it totally goes away when you use the correct comparison operator == for strings.
sigh I'm not really as good at this whole programming thing as I should be by now.