Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interview with Senior JavaScript Developer 2024 [video]

youtube.com

Post reply on HN
Print view View original

51–60 of 75 posts

Re: Interview with Senior JavaScript Developer 2024 [video]

#51

Post by beau_g »

dimal wrote: post #11

I 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…

I had an epiphany the other day experimenting with react-spring making some animations - Flash was much simpler, easier, and more performant in doing the exact same thing 30 years ago. The inevitable solution to the JS framework wars is the return of Flash.

Re: Interview with Senior JavaScript Developer 2024 [video]

#52

Post by whoknowsidont »

csnover wrote: post #48
whoknowsidont wrote: post #17

Earlier quoted context omitted.

>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 a…

Your quote doesn't state anything to support what the OP said. It doesn't even say what you said it says.

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.

Re: Interview with Senior JavaScript Developer 2024 [video]

#54

Post by stevenpetryk »

jacobsimon wrote: post #42
jwells89 wrote: post #24

Earlier quoted context omitted.

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.

Canvas is a blank slate to screen readers though.

Re: Interview with Senior JavaScript Developer 2024 [video]

#55

Post by jacobsimon »

stevenpetryk wrote: post #54
jacobsimon wrote: post #42

Earlier quoted context omitted.

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.

Canvas is a blank slate to screen readers though.

Yeah that’s what I meant by accessible, agree it’s a problem today

Re: Interview with Senior JavaScript Developer 2024 [video]

#57

Post by jauntywundrkind »

This was really fun. I dunno if t3/t4 are based in anything specific but most of this is surprisingly sharp, while also being ridiculous.

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.

Re: Interview with Senior JavaScript Developer 2024 [video]

#58

Post by egeozcan »

jacobsimon wrote: post #42
jwells89 wrote: post #24

Earlier quoted context omitted.

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.

> Building an accessible canvas-based UI with a React-like API would make a lot more sense for SPAs

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).

Re: Interview with Senior JavaScript Developer 2024 [video]

#59

Post by k__ »

dimal wrote: post #11

I 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…

Yes, I also have the impression that the whole SSR story is a step backwards. Especially with the prevalence of CDNs nowadays.
Post reply on HN