Hacker News new | ask | show | jobs
by newshorts 1735 days ago
Been interviewing for a few roles lately and finding the new “react dev” eerily similar to those relying on jQuery back in the day.

I ask vanilla js and low level layout/styling questions in my interviews (not gotcha questions, but instead what I consider to be fundamental skills indicative of experience) and am consistently met with confusion.

Maybe I’m too old for this game and front end devs will never again need to know about addEventListener?

6 comments

What are you trying to measure by asking a low level question about say addEventListener? The people who give the best answer will be the people who most recently used that low level api and are good at sharing their knowledge about it. A better way to measure that would be to ask them to tell a story about something then if they mention say debugging an Event Listener then such a question is fair game to understand how they deep dive a topic.

An FEEs job is 90% combine components from the design system with apis from the backend team to implement a UX from the design team (and obviously debugging, deploying, etc.). For this I only care that you know what an Event Listener is or what Flexbox is or what the Box model is I don’t really care whether you know some of the low level details off hand (unless you reference it in a story).

Maybe I am not the only person on the planet who still uses Vanilla JS and plain Node.js.

I mean I have a lot of experience with various front end component systems on desktop on the web, including Microsoft stuff and in the browser some Angular, React and Vue. But for my current project which is a little bit involved, I decided to skip React. It is actually working out fine. I assume React devs who see it will suggest that it's time to take me out behind the barn and put me out of my misery though.

I've built a few small projects with just backend rendered views in Node.js, and then did all the dynamic "SPA" like features with Unpoly. Turned out a lot better than I thought. Things such as authentication being a lot easier and not having to build an API really helped speeding up things.
I remember interviewing people for a front-end role as well, and when asked how they would decide between traditional HTML rendered on the server, or a framework like react/vue. Some flat-out couldn't even comprehend what I meant. I honestly feel like this is becoming a problem, where junior devs don't even know how to build anything without react/vue (or the likes).
Good! We need to get back to the basics and stop shoehorning React into every application.

I regret that my post is yet another React promotion. Not intended: architecture depends on use-case. I’m hoping to write more soon about selecting tools appropriately, which probably doesn’t mean React in many cases.

Just wait till HTML is rediscovered. "Hey, look, my content page is 2KB instead of 8MB"
Senior Frontend Dev:

HTML was never gone :) I have and still working on big e-commerce websites.

For example, Ikea for product lists sends mini chunks of simple HTML. No JS involved.

What I see is the problem that people think that "Frontend development is easier than backend development".

For me, they have different challenges and different ways of thinking. Getting a good full stack developer is kind of getting a good doctor, which has at least to specialities.

> Frontend development is easier than backend development

This always amuses me when it comes from junior front-end devs who are scared to touch the backend because they've never done it before. I always tell them not to worry: the backend is much simpler.

> What I see is the problem that people think that "Frontend development is easier than backend development".

I hate that statement so much. Even had some serious arguments with "back-end developers" who were constantly mocking HTML/CSS/JS. Turned out that when pushed to do it, they just couldn't do anything and had to ask for help.

Writing proper reusable HTML/JS isn't easy, it also requires thinking on how to structure and split up things. Especially when you throw some CSS into it.

I've been a backend developer for many years, and for the last 6 years I've been doing frontend.

I can assure you those developers mocking frontend devs can't even do backend if taken outside their big ass framework (django, rails, symfony,etc etc), because they believe everyhing is as easy as those frameworks put it to them. Somebody that had to work outside of that where you have to take many decisions and make tons of trade offs and find how to organize code and manage dependencies, etc will understand better how difficult frontend is. True we sometimes overcomplicate things more than needed (redux, rxjs, etc...) but even when we do not, this is still freakin difficult to get right.

For example, Ikea for product lists sends mini chunks of simple HTML. No JS involved.

Can you elaborate how? like some turbolinks thing?

The back-end can render that content when requested, adding very little overhead to an AJAX request just returning the raw data, and it can pre-render and/or cache objects as well. Both Facebook and Reddit do similar when loading extra content into an existing page - they embed HTML content in the JSON response for things like profile popovers or when loading more comments. Saves the front-end from having to render a template (takes time to load the template beforehand and time to render it, maybe for many items) or build it programmatically. Directly using AJHX to get HTML is the same when there's just a chunk of HTML with no metadata.
I don't work for Ikea so I don't know how it is implemented.

What you can see in the Network tab is that you get chunks of html from the backend which have all the markup

Other e-commerce stores do that too.

Sometimes these chunks also have js in them.

“Hey look, the browser loads each new page one at a time instead of loading them all in the initial load.”
typical interviewer bias - you are looking for a candidates that look exactly like interviewer does, and possesses the same knowledge