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

61–70 of 75 posts

Re: Interview with Senior JavaScript Developer 2024 [video]

#61

Post by jacobsimon »

egeozcan wrote: post #58
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.

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

Thanks this is really close to what I was imagining, but looks like it’s been inactive for a long time.

Re: Interview with Senior JavaScript Developer 2024 [video]

#62

Post by Maxion »

edem wrote: post #23

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

I'm stealing this.

Re: Interview with Senior JavaScript Developer 2024 [video]

#63

Post by egeozcan »

nextworddev wrote: post #31
egeozcan wrote: post #13

Earlier quoted context omitted.

Those are actually easy. The ones using the first versions of React with custom state management and weird conventions however, are a different story. 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 compl…

JqueryUI… that’s a blast from the past. I’m guessing it’s still used out there.

Yes. Perhaps not in the public web but there are so many internal tools using it. It has a lot of issues but the average jQuery UI project is so old that some users will actually complain if you fix bugs because it breaks their workflow (speaking from personal experience)(there was an xkcd for this I think).

Re: Interview with Senior JavaScript Developer 2024 [video]

#64

Post by akira2501 »

jwells89 wrote: post #24
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…

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…

You have the history state API and Custom Elements. Are these not adequate?

Re: Interview with Senior JavaScript Developer 2024 [video]

#65

Post by bornfreddy »

Xeronate wrote: post #46
hu3 wrote: post #8

Earlier quoted context omitted.

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.

The same as in other languages. Avoid dependencies whenever you can, and only add them when really needed. And only if you are fairly certain that the dependency a) will still be there in a few years time and b) developers take backwards compatibility seriously.

Re: Interview with Senior JavaScript Developer 2024 [video]

#66

Post by egeozcan »

jacobsimon wrote: post #61
egeozcan wrote: post #58

Earlier quoted context omitted.

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

Thanks this is really close to what I was imagining, but looks like it’s been inactive for a long time.

Yes, the reactions to it were not very enthusiastic as you'd expect. Also it did have a11y issues.

There are a lot of interesting renderers for react, some of them are even maintained: https://github.com/chentsulin/awesome-react-renderer

Re: Interview with Senior JavaScript Developer 2024 [video]

#67

Post by jwells89 »

akira2501 wrote: post #64
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…

You have the history state API and Custom Elements. Are these not adequate?

Not really. These APIs are useful, but they’re still too primitive to make a dent in library usage. To do that you need things like highly capable “batteries included” (yet easily customizable) widgets and the more generally applicable parts of React (or similar) implemented as browser APIs, so for the majority use case few or no third party libraries or layers are necessary.

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.

Re: Interview with Senior JavaScript Developer 2024 [video]

#68

Post by ccorcos »

I thought he was making stuff up - "t3 stack vs t4 stack". But about 2 minutes in, I realized that I'd heard of a few things that he's talking about so I looked it up and they're real!

I think it's possible everything he's saying is true, more or less. LOL

t3: https://create.t3.gg

t4: https://t4stack.com

Re: Interview with Senior JavaScript Developer 2024 [video]

#70

Post by eyelidlessness »

eyelidlessness wrote: post #49
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…

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…

I’m amused trying to guess whether this was downvoted because someone disagrees with the factual claim about React’s origins, or with the point that criticism shouldn’t be based on falsehoods about the object of that criticism.
Post reply on HN