Interview with Senior JavaScript Developer 2024 [video]
youtube.com
youtube.com
I feel like the front end web dev community is going through its equivalent of the microservices/kubernetes madness that overtook the server devs in the past few years and they’re making everything 10x more complex than it needs to be.
Like, server side React frameworks like Nextjs solve a problem that never should have existed in the first place — that people were using React to build websites, when React wasn’t designed for that problem. It was designed for SPAs. And so with server components and Nextjs they’ve reinvented PHP. It’s like, we could have skipped a five year step and used PHP/Rails/whatever.
There’s been a lot of movement in this direction for CSS which is great, but it needs to happen in HTML and JavaScript too. Just a few cycles of implementing popular libraries as base browser functionality and adding better widget primitives would do wonders to reduce complexity and bloat.
https://github.com/Flipboard/react-canvas
React is the Simpsons of web tech (Referring to the "Simpsons did it meme" if that wasn't clear).
There are a lot of interesting renderers for react, some of them are even maintained: https://github.com/chentsulin/awesome-react-renderer
But this is the antithesis of FE culture. When FE culture spun up there was a lot of mocking of javascript devs as not "real" devs. I think they felt the need to reinvent CS so that they could show they were legitimate. They never really recovered from that.
The end goal here would be to have a basic reactive UI development toolkit complete with a full spread of ready to use widgets with nothing but a plain text editor and a browser.
That won’t meet everybody’s needs of course, but even those still using third party libs would benefit since things like React could be lightweight “sugar” libraries built on the browser APIs instead of hulking behemoths with a fractal spiral of dependencies.
React generated HTML on the server from the very start with Node.js. You always had some form of hydration, even before there was an explicit API and process for it.
It was built by Facebook... to build a highly utilized and extremely popular website. React had pretty popular examples and integration with RoR and Python, and of course PHP.
Why are you just making up history to fit preconceived notions?
> Bolt [a predecessor of React] was basically more or less Facebook's implementation of a client-side MVC. [It was] not a tool belt, it was truly an application development framework. Something designed and meant to build complicated interactive rich apps and was being used to build pretty complicated very real products at Facebook at the time. […] As the product itself got more complex and as we added more engineers to the team, we didn't hit a wall but it started to get really, really hard to make changes. And that was around the time that Jordan [Walke, creator of React] was on the ads team and he's like ‘I wonder, there's got to be a better way’. […] Jordan was a product engineer at the time, working on ads, and ads has one of the most complicated pieces of UI across all of Facebook at the moment. On the ads team they were hitting the limits of what you can do without React complexity wise. […] Jordan had a lot of very interesting ideas around how you could take what we had done in Bolt and make it easier for it to scale with people's ability to understand large applications.
As the GP said, React was explicitly designed to solve the problem of having many engineers writing large, complex, client-side applications. It was not designed for building simple web sites.
Here's Pete Hunt talking about static webpages with React, in a best practices talk from 2013: https://youtu.be/x7cQ3mrcKaY?t=1528
There is no need to imbue meaning into quotes or history when there is a clear, well defined timeline with striking examples of how React was used to generate static website all the way from its initial release.
It's responding concisely to the point OP was trying to make. Their "point" or perspective is not accurate and it's certainly disingenuous.
>To the point that it is now molding js development in general.
I'm not following this statement. Can you expound on this?
You might also object to that being a problem which should exist, but it’s a distinctly different problem to discuss. And in discussing it, the “React to build websites”criticism is mostly meaningless.
Except worse. There will be PHP-7 monoliths out there running on Apache until the heat death of the universe. Try updating a Node project that hasn't been touched in two years.
That being said, just installing old Node.js projects can be painful, unfortunately. It's got a lot better with newer NPM versions that use lock files by default, but it still leaves a lot to be desired. Often updating the Node project is the only way to get it running, because somewhere in the stack someone broke semver, or your OS is newer and some native extension does not compile on the new version, or you need to use an ancient Node.js to run it because it depended on some behavior that was deprecated and removed in the 5 Node.js versions released since the project was written.
A particularly notable thing recently is that newer Node.js doesn't support older crypto types, breaking most dev servers built for older Node versions. This has been a pain lately.
What I’ve been noticing is backend becoming incredibly slow and kludgy and there’s a want for FE for work around it. Since you can’t bleed a rock, we’re creating these incredible and evil machinations across everything but the server->db layer in order to get the page to load as quickly and efficiently as possible.
Frankly, we should just dump the servers and let the FE query the db directly. We’d probably do it fucking better anyway.
Solutions like Firebase that do exactly what you are describing are extremely expensive and just as limited in terms of functionality, and properly designing security for them is quite difficult. For quite awhile I was on that train until I just couldn't justify the price and limitations, and my frontend stack to deal with those problems became excessively complex.
The weird cuts are part of the gimmick. I think part of the joke is how stressful it is to listen to.
In 2015, people were still complaining about trying to build stable layouts using CSS. Congratulations, we now have Grid and Flexbox (and subgrids just stabilized!) but they still complain. They complain about having to write custom Javascript (which is slow and has to be maintained) so functionality gets pushed into CSS and they complain that CSS is getting too complicated.
There were people complaining about the "Javascript framework of the week". Then React took over the space, and now they complain about how everything's written for React and we should just use htmx and Svelte. I thought we didn't want something new every week!
There were people complaining that Webpack was slow and required too much up-front configuration. Then Vite came out (which is fast and only requires minimal configuration) and they went back to complaining about having to learn new things.
The best explanation I can come up with is that most organizations must just treat FE as an afterthought and assign people to do that work who have no experience or interest in it.
Just because react was built for one things doesn't inherently mean its wrong to use it for other things.
I think it's possible everything he's saying is true, more or less. LOL
Similar video. I've seen their channel described as "the best workplace videos I can never show my coworkers."
Nobody?
In 10 years from now, this JavaScript crap will be just like that PHP project is perceived today. Except it will be much worse, because the PHP project didn’t have dependency hell like this. At least the PHP project wasn’t also your phone app.
Those, and debugging jQuery UI problems.
I digress but in my career of using every technology possible, the pain I had debugging a huge (HUGE) jQuery UI project could perhaps only be matched by trying to make NHibernate (Hibernate ORM but for .NET) behave in some complicated (but CRUD after all) data-heavy projects.
In a more serious note: I don't think the language matters that much when working in legacy codebases. What matters the most is the (usually undocumented) business logic that one needs to decipher based on the code. I'll take any day of the week a documented PHP project from 2011 than any Go/Rust/TS/Kotlin undocumented project of 2024.
What surprises me most is that we have tried so many things, except most apps are a handful of bundles, and even more wildly, almost all work happens on the main thread still! React's vdom has given us a very nice & performant Immediate Rendering (vs Retained Rendering) view, and we've dabbled with unidirectional data flow, signals, whatever graphql is, and other abstractions, but the core "where and how does work happen" model hasn't been much iterated on.
Now we are very busy figuring out React Server Components and doing other page rehydration works, which indeed can shift much of the work out of main thread. But the client has been somewhat stuck, somewhat patterned into monolithic main thread patterns forever, and few have tried to push beyond that. Even with wasm happening, it still seems like few are using web workers to divide up where the work happens, which feels like it could be such a giant win for keeping the page crisp & responsive, for thickening the client effectively.
is a great line
It's actually valibot. Unwatchable.
turned out to be prophetically true in many many ways.
must have missed that joke