> we ship on save
is a great line
Interview with Senior JavaScript Developer 2024 [video]
41–50 of 75 posts
Re: Interview with Senior JavaScript Developer 2024 [video]
#42I couldn’t make it through. It’s funny but also stressed me out. 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…
From my point of view, a lot of trouble could be saved if it were a priority in browser development to reduce the number of libraries and layers necessary to build things like SPAs. 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 primiti…
Agreed. I’ll take a more controversial stance that I’ve said here before: CSS/HTML are part of the problem and the community should have invested in proper UI/rendering frameworks a long time ago that weren’t designed around the quirks of HTML and CSS. Building an accessible canvas-based UI with a React-like API would make a lot more sense for SPAs, and maybe other types of websites too.
Re: Interview with Senior JavaScript Developer 2024 [video]
#43I do trunk based development. i have a script named "c" that does `git add --all && git commit -m "progress" && git push` and another one named "p" that does `git push prod`. apart from that i use effect-ts and express with kita.js and a few small libs and do persistence with pg. the rest is written by me and somehow i don't feel the need to add anything to it. not everybody needs k8s, microservices, and all that cra…
Looks good to me.
Re: Interview with Senior JavaScript Developer 2024 [video]
#44I couldn’t make it through. It’s funny but also stressed me out. 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…
Even if react is made for SPAs (which is a murky definition anyway) there are many parts of react that make general website development better. For example dependency management is way easier and maintainable with npm/react than manually importing scripts in the right order the traditional way. Achieving high levels of interactivity is also much easier for the same reason.
Just because react was built for one things doesn't inherently mean its wrong to use it for other things.
Re: Interview with Senior JavaScript Developer 2024 [video]
#45I couldn’t make it through. It’s funny but also stressed me out. 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 have been complaining about this since at least 2015
And the complaints hold less and less water each year.
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.
Re: Interview with Senior JavaScript Developer 2024 [video]
#46Who here wants to work on a minimally-maintained PHP project from 2011? 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.
The future is already here. As a tech lead, consulting for one of my clients, I have to oversee the maintenance of three JS-heavy projects (backend too) that are imploding under their own weight of technical debt. And a good part of that are dependencies.
What is the alternative to dependencies if you are making a highly interactive web app? Large/old apps being a pain to maintain isn't something unique to javascript.
Re: Interview with Senior JavaScript Developer 2024 [video]
#47It's scary how much of that I understood. smh
Re: Interview with Senior JavaScript Developer 2024 [video]
#48I couldn’t make it through. It’s funny but also stressed me out. 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…
>that people were using React to build websites, when React wasn’t designed for that problem. It was designed for SPAs. 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 integratio…
It’s not making up history. There is a documentary[0] on the history of React where the people involved in its creation and use at Facebook described it this way:
> 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.
Re: Interview with Senior JavaScript Developer 2024 [video]
#49I couldn’t make it through. It’s funny but also stressed me out. 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…
React wasn’t designed for SPAs. It was, in fact, originally derived from server-side technology. And whatever criticism is due both Next and RSC, solving “React for websites” isn’t one of them. Both are targeting highly dynamic web applications in which both the server and the client are implicated in that dynamism—and in which a high degree of sharing between them is beneficial.
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.
Re: Interview with Senior JavaScript Developer 2024 [video]
#50I couldn’t make it through. It’s funny but also stressed me out. 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…
It’s not the same as the microservicesageddon (and yeah we were part of that too). 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 j…
If you could pre-sign the queries to prevent abuse (user edits to queries making them potentially slow) then IMHO it would be a nice idea in a load of cases. Datasette actually does this, though that’s aimed at a very specific subset of cases.