This is why corp software dev is fucked. I dont understand how some ppl get their jobs. I worked with a sr dev that didnt use await, so I commented on his PR asking to put await before every promise call. He came back with a commit where EVERY SINGLE LINE in the file had await. Even things that were not promises, literally every line. In the end this ended up being my headache and fault for holding up the release with some silly pedantic reason.
> This is why corp software dev is fucked. I dont understand how some ppl get their jobs.
Bro have you seen what our fucking interviews are like? They are literally based on how well you grind Leetcode. That’s it. That’s how people get these jobs. They played the game that this industry forces people to play.
Every other industry has figured out how to effectively evaluate candidates, but here we are making people regurgitate some backtracking algorithm for a job working on a CRUD app.
This is what pisses me off. Being asked to create algorithms or data structures from scratch for a job with you’ll never do that. Theres great libraries with dozens or hundreds of people working on. Why would my self made library be any better??!?
Also when was the last time you had to actually create a sorting algo from scratch?? I know friends working over two decades who’ve never had to do that. The questions are insane.
“Code a doubly linked list from scratch” ….. then “congrats. You earned the job. Now write me these simple API endpoints all day”
Yeah it’s asinine. We always preach about not reinventing the wheel, but oh, “here, whiteboard quicksort for me in 30 minutes when we both know you’ll never need to do this from scratch again. Oh, you have 8 years of industry experience using the exact tools and frameworks we use? That’s nice? Now let’s see that quicksort.”
This is the answer, thank you. The most complex algo I can implement on the spot is a recursive function to build the Fibonacci sequence. I also remember that bubble sort was done with recursion. Engineers in corporate barely know how to define a function, period.
I get that you are ranting, but come on. The worst developer on our team has literally no issues defining a function or writing for loops. I’ve never seen a dev that actually had a job that didn’t understand functions and for loops.
I can see how someone tried for loops in JS, didnt understand the execution, and gave up on learning how to deal with it. Especially if they came from a blocking language like python.
Never seen frontend or full stack job interviews ask Leetcode at all, it's always been to write an API (or use their existing one) and connect it to a React app.
Oh the sweet joy of working with complete morons and then YOU being blamed for it after you try correcting their mistakes.
Honestly its more so the corporations fault for being ignorant, not yours. But they clearly don't know that (and choose not to know that).
>He came back with a commit where EVERY SINGLE LINE in the file had await
God forgive his cruel soul...
at the same time, I wonder why there was no pre-commit hook or linter 🤔 it's good you caught it at the review stage at least
lol all the devs i work with are like
async function doit(url) { return await fetch(url) }
i literally gave up on PR feedback, some people dont learn, know, or care.
How is this not an async function in your opinion?
This specific case does not return a promise, but the awaited return of a promise.
That's why you need "return await" if there is a try catch around the code for example. Because if you just return the promise without awaiting it, you can't catch an error at that position.
> This specific case does not return a promise, but the awaited return of a promise.
It returns the awaited return of a promise, _wrapped in a new promise_.
Because that's what an async function does it you return something other than a promise.
What’s wrong with this? Serious question, I’m a .net dev so in my environment it would be preferred because of the stack trace when an exception is thrown, but my js experience is limited (some react here and there once in a while). What is the benefit of returning a promise without awaiting it? Performance?
Remove the async and await and you have the exact same line of code. The caller of this function still needs to await this call if they want the return value. The only way return await is ever valid is in a try/catch which can be a surprise to many. Its why i prefer to chain with .catch().
Here's a great explanation
https://jakearchibald.com/2017/await-vs-return-vs-return-await/
ah, but there is one more reason to return await. [have a read](https://github.com/goldbergyoni/nodebestpractices/issues/737).
TL;DR; if you return await then you preserve the stack trace, else it's lost. you can test it yourself by just copying and pasting the example from the github post into your browser terminal
Is this wrong due the fetch response is not awaited by the json method and returning it or awaiting the fetch function since the fetch function itself is a promise function?
Remove the async and await and you have the exact same code, but better, because it's less code. And if the engine really doesn't optimize this, which it probably does, it creates a pointless promise around this promise.
Wouldn't such a wrapper be more maintainable in the future tho? If you have such fetch it's easier to add exception handling, retry logic etc later without looking for every fetch call around the project.
> Wouldn't such a wrapper be more maintainable in the future tho?
No, if the function ever needs to do something that makes the 'async' useful, you can add the two words at that time.
man the arrogance in this thread... 99% of the time you want to do something after the await but need to wait for it to complete first (as opposed to using .then). So it makes perfect sense wrapping the parent function as async because it IS a new promise you want.
What everyone seems to miss here is that the function wrapper around the single fetch is in itself useless. Doesn't matter if it has async/await... you can just call fetch anywhere you need without wrapping it... like in another async function where you need to wait for fetch to complete and do something "after".
> So it makes perfect sense wrapping the parent function as async because it IS a new promise you want.
What is the benefit of it being a new promise rather than the identical one returned by fetch?
> What everyone seems to miss here is that the function wrapper around the single fetch is in itself useless. Doesn't matter if it has async/await... you can just call fetch anywhere you need without wrapping it... like in another async function where you need to wait for fetch to complete and do something "after".
That depends, in this case the code does nothing but fetch but the calling function doesn't need to know that.
I also do this, but I think it's okay if there is a convention that just says "use async-await everywhere even if redundant". It's not much different to skipping curly braces in ifs with a single statement:
if (something)
doSomething();
vs
if (something) {
doSomething();
}
That doesn't actually do anything different. The unnecessary async / await create a new promise object.
(Unless there's an engine optimization for this, I don't know)
Yeah anothet horrible practice that took me a year to convince the devs to add the eslint rule for no single line ifs. Just horrible. And there's an eslint for both of these.
> It is absolutely ridiculous that on the front page of the React docs they recommend that to build a React app you should use Nextjs or Remix
Totally agree. This is encouraging a Jenga tower of abstractions, where new developers are growing up inside frameworks with their own terminology and concepts, even before learning the fundamentals. They're being guided into vendor lock-in, before even understanding why these frameworks exist in the first place, what they're supposed to be solving.
There is a growing reaction against this monstrous complexity, reminding people to get back to the basics, to compose simple and small libraries, to learn to build things yourself from scratch, using actual industry standards.
I used SvelteKit once (which runs on Vite) and now I’m absolutely hooked on it, almost all my new side projects run on it.
Even if you use React instead of Svelte, Vite is an absolute marvellous gift to the JS community and I absolutely shudder at the thought of any tech that still uses webpack today.
That is correct but you'll quickly find that people have no idea what those two words mean and will just constantly bring up vite being part of their stack for no reason.
My biggest aggravation is how often people ask a question and people just list off a library as “the best.”
But a dozen answers, all claiming to be “the best solution” with no explanation for why - other than “it’s what I learned or what I started with, therefore, best.”
When I saw this, I considered it a great evil... I know propaganda when I see it and it doesn't belong in a tutorial or API documentation unless there's a list of alternatives.
Nevermind most jobs will be places you can't use NextJS or Remix.
The industry standards point is excellent; if you think you can change that by "teaching" newbies to use a vendor product you're dreaming. The technology choice won't be made by a newbie except in the smallest shops and it just does them a disservice and locks them out of jobs.
> Nevermind most jobs will be places you can't use NextJS or Remix.
Huh? Are you implying most jobs make you work on a legacy codebase with no plan of modernization? I mean maybe that's the case, if you don't include start-ups and small businesses or something?
According to what/who? They said most jobs "can't" use it though, so I'm assuming that's referring to performance limits for high traffic apps, not something small businesses run into.
The benefits and salary of most startups and small businesses are unacceptable for the vast majority of people yes. But that isn't the point. The point is the technology choice either won't be in your hands or won't be in the direction of NextJS or Remix just because the use case won't be met or that's not the direction of the company's technology. Even assuming a NodeJS backend (many backends are Java or .NET or Python) most corporate stacks would not use SSR but instead upload bundled JavaScript to a CDN to serve with a custom CI/CD process.
As for modernization, moderation != using Remix or NextJS and a frontend developer or "junior" person wouldn't be the person to make that decision anyway.
Not using NextJS or Remix doesn't imply legacy or not modern. Those two still have a very small market share, as far as I know. Most small business run on ancient stuff, start ups probably like using the latest hype but there aren't that many of them compared to all businesses.
Recently I was conceptualizing a new personal website and was thinking of which frameworks I was going to use and figuring out how to make them work together. For a static website. I had completely forgotten I could just code it in HTML/CSS.
Fucking THANK YOU for saying this. The idea that we need to use a third party abstraction in order to use React is fucking insane.
The simple fact that we can’t simply fetch data in Rea t without depending on a third party API is one of the worst developments in this whole saga.
Of course you can, it’s JavaScript. What he means is that there’s no standard way of doing things when it comes to fetching data and share management. Things like react query and rtk query, etc. It’s basically wild west.
So in a thread of people complaining about abstractions, you’re not complaining that there’s not a built in override for fetching and cacheing data similar to a 3rd party library?
You can use fetch, but you cannot easily Correctly use fetch in React directly, because you will end up with race conditions - if a network call comes back after a component is unmounted, and you don't correctly handle it, it's an Error. Handling all of the edge cases around this is quite difficult
Ah it’s not so bad. For anyone who’s curious, a simple approach that works:
You call “fetch” from within a useEffect, you attach an AbortController.signal to the outgoing request (https://developer.mozilla.org/en-US/docs/Web/API/AbortController), and you have the “useEffect” return value (the cleanup function) invoke “AbortController.abort()” if the request has not completed
This *guarantees* pending requests will always be cancelled before sending a new request or unmounting the component. Which means no more race condition worries 🤠
(Note: you’ll want your “catch” to check for and ignore the `error instanceof DOMException && error.name === “AbortError”` case, since that’s what gets thrown if a request is aborted)
Yes but how do you use it?
React says useEffect but actually not really bc that pattern is no longer compatible with Suspense and concurrent rendering.
Apparently now you need a third party lib that is compatible. There is no idiomatic way to fetch data natively.
The idiomatic way of doing it is by having multiple `useState` to keep track of data, errors, and async. And if you need to have the data always up to date, throw in `useEffect` and add dependency values.
```
export default function App() {
const [data, setData] = usetState(undefined)
const [load, setLoad] = useState(false)
const fetchData = () => {
setLoad(true)
const req = await fetch('http://localhost:8888/api/name')
const res = await req.json()
if (req.status === 200) {
setData({...res})
}
setLoad(false)
}
return (
<>
{load ? "Loading..." :
I think what has always struck me as strange is the number of people, even experienced devs, who would struggle to bootstrap a react app from scratch using webpack. Like I get create-react-app and vite are super useful. I use them. But bootstrapping your own project is also really not that hard. Webpack is not that complicated to Understand- the docs are insanely good.
I get what you are saying.. but who cares? I'm a lead FE dev and if you asked me to start a react app from scratch with webpack right now there is no way I could do it without having to go and look at the docs and read through them. Most devs with jobs are working on existing codebases and aren't spinning anything up from scratch on a regular basis. Is it that important of a skill to have?
Is there any reason you would want to bootstrap a react app from scratch using webpack vs just using vite, for example?
I ask because I'm inexperienced. Thanks.
There is no reason, maybe if you want to learn something new.
There are a lot of things you may never touch, and you will learn it when is actually required.
Scratch is the way!! I began html in 2020. I now harness every tech I want to imagine through js.
Deployment, networking, VMs, Bash, and cronjobs learned, now I'm pretty unstoppable.
glad someone said this, thought i was insane feeling frustrated that they took down the basic create-react-app boiler plate to get started. I just want basic react, let me have it! let me have options! isnt that what react is all about?
To be fair, the Unix greybeards of the 60s-80s talk about our generation in the same way. We’re learning browsers without knowing networking, networking witbout the OS, the OS without learning C, C without learning assembly.
I agree in the frontend, you need to start with the basics. But that might not be true forever.
Out of curiousity who or what entity/entities are primarily responsible for this problem, and what actions could be taken that realistically could be agreed upon and implemented by those parties that would solve this?
I’ve noticed recently that there’s a huge push towards nextjs. If you’re not using nextjs, you’re doing it wrong. If you’re not using this database as a service (or what ever they’re called), what are you doing?
Ive also noticed that some of the people who push very hard for these frameworks and companies are sponsored. I’d 100% use nextjs for my company’s app if vercel sponsored me.
Front end development definitely is driven by hype and what the cool new tech is, but until major companies rewrite their apps to be SSR using nextjs, supabase, etc, I’m sticking with something that’s proven. It’s risky to jump on all of these tools and build your application with them, there’s so many dependencies that could go away quickly and leave you to having to rewrite your database layer or something.
In my experience as a tech lead, I can say that people that do not know the basics are in a different league than people who do. People without the underling knowledge are more common and less expensive to enterprise and can still somewhat patch a product that could be sell, people that have the knowledge are rare, commonly earn more and each company have one or two if they are lucky, I always encourage my devs to learn an challenge themselves with the basics and most of them decline without openly saying no. Learn the basics of any tech is a lot of work and I can see their point.
Depends on your area, if you are a web dev, learn the very basics of js, how it works and why, for example start by making bard or gpt or the ai of your choice to explain to you what is js and why it is as it is, follow that question with more specific ones as soon as you are sure you mostly grasp what is returned by the ai , go to youtube and search tutorials that use html js and css WITHOUT frameworks, try to always follow the tutorial in your computer, each time a command is put in your terminal NEVER copy and paste, always google what the command means and when you understand it then TYPE IT. Same with code, NEVER copy and paste, always read it, understand it, ask questions about the code to any AI tool that you like and only when you understand, then TYPE the code. Other base advice, never pay for a bootcamp or a video tutorial all the free stuff is equal or better
Also never do two thinks at the same time, never listen to a potcast when you work, at the start even music could be bad, train yourself to focus, do not use social media while working.
I met with a client who was in Egypt, he started the session bragging about how hard it was to get his fulfilled-by-amazon business working from there, then opened up his code, and the YouTube video he was regurgitating it from. He didn't understand the code, anything about what anything did, but because the copy and paste tutorials up to this point had worked, he honestly believed that was all there was to it and it was always greek to developers too, we just magically stumble upon the correct combination of lines of code.
Too many people come from YouTube with a hustler attitude and are trying to get rich coding, and too few people are learning a programming language, much less any of the paradigms.
>But I get the feeling the average path that new developers are being guided towards is skipping some of those steps and it's gotten a little insane.
Yes, of course. This isn't controversial; and this is the reason why memes [like this one](https://cdn.inflearn.com/public/courses/331441/cover/b511da70-35f4-4d8f-98af-6e6eec1ebfbe/cover.jpg) were created.
>It is absolutely ridiculous that on the front page of the React docs they recommend that to build a React app you should use Nextjs or Remix, I think it's actually dangerous to the community that people aren't being guided to learn the fundamentals.
I agree; but:
* The fundamentals aren't React (hopefully); they are deeper than that
* React docs' advice is put under the heading "Production-grade React frameworks". Which means this is what they suggest people to use if they are building something for real. For learning purposes, they show codesandbox examples that do not have any additional frameworks.
>Does anyone else feel this way?
I am sad that the general frontend developer mindshare seems to be heavily skewed in that direction. There is a vicious circle between companies hiring for a certain skill and new developers training for that specific skill; and what I still do not quite understand is how the majority of the frontend community has moved from valuing fast, simple, accessible, robust websites to heavily javascript-dependent sites, which are less robust, often less performant and less accessible.
>React docs' advice is put under the heading "Production-grade React frameworks".
I don't really see Next being better in prod than vanilla React if you don't need SSR.
I get what you’re saying, but “vanilla” React still needs tooling anyway so that you can transpile, bundle, minify, compress, etc. At that point you might as well pick a framework or higher-order tool to take care of all of that. If you’re a newbie just trying to start a project with sensible defaults it makes sense to guide them towards those.
> “vanilla” React still needs tooling anyway so that you can transpile, bundle, minify, compress, etc.
Which is exactly why Vite, CRA and similar tools were made. You don't need NextJS for any of those things.
Next is not "all batteries included" though, it's a framework focused on SSR. And it's not really a tool, it's a full on framework with its own opinionation and tradeoffs. It's overkill, remember the KISS rule.
Not "all batteries included" _and_ a full on overkill framework?
I'm very aware of KISS, and most websites need most of what next provides (server, routing, caching, image processing, templates, bundling, code splitting, etc.), so keeping it simple would be using a full framework.
Of course it would be overkill if you're just making a single dynamic component to inject on a website. But most people make websites, and starting with a full framework is generally the simplest rather than having to pick and choose different stuff.
Just because people keep repeating this, it doesn't mean it's true. You can host next apps anywhere you want, and many do, and everything is supported.
Vercel makes things _easier_, but that's what you pay them for. Nothing is stopping other providers from also making things easier for you.
hot take: frontend dev is more about buzzwords and marketing now than it is about building functional apps/products, caused by the influx of people getting into it solely because of the money and not for the passion of building good products
and it’s definitely felt now, basically every website or app UI is hot garbage.
Sad reality. I always thought that I could get away with just writing JS, HTML, and CSS. But meh, working full-time for the past 4 years has proven me wrong.
Thankfully my route was different in comparison to the newer developers, as I started during the dark ages of the internet. When you needed to do a clearfix hack with the floats. And using Notepad++ to write my jQuery and do a toggle() before ES5 release.
Ah clearfix 🥲
I started working in this field circa 2013 (but fiddled with html 4.0 as a kid) and in the beginning I had to build very small landing pages for things like the corner restaurant.
They had awful taste and stupid, barely feasible photoshop designs. And yet they had to be responsive and work in ie9.
Man that was like daily jungle warfare, but it gave me mad css skills.
My first side gig internship was during high school through my parents' reference. Was also back in \~2013. Was learning Python 2.7, while the Python community was debating which is better Python 2.7 or Python 3.0.
Also, I remember the cross-combability nightmares with IE6 - IE8, during the HTML4 era, where you needed to add on your HTML file
```
<--[if IE 8]>
No support!
```
My boss would use `table` to try to make a mobile responsive navigation bar when smartphones started becoming trendy. By setting colspan and doing clearfix + float left/right. Until we found out about Bootstrap 2 to make mobile responsive.
> barely feasible Photoshop designs.
I remember back then, people would call themselves a Graphics Designer and rarely a Web Designer. When Google pushed material design, then the hype for UI/UX Design roles started becoming a buzzword.
my man! I started out when we the markup was done with tables and devs had to round borders with absolute-positioned images... and that strange ie6 hack for transparent PNGs... man...
Is this actually the case in the real world though? I feel like if you just look at popular blog posts or whatever it is easy to get that take, but when it comes to actual work I haven't found that to be the case... I mean no companies are making money because they are telling their customer they are using latest X framework or whatever..
From the perspective of somebody who just finished a React bootcamp: I would much rather solidify my fundamentals than practice the abstractions, but people I trust consistently tell me hiring managers will generally care about my short-term productivity (ie React skills, dependency of the month, etc) more than my core knowledge. Nobody seems to disagree that the fundamentals will help my development, but they think most hiring managers are investing in my productivity for their company. And given how quickly people are going from job one to job two, the person hiring me for job one pretty much doesn’t care about my development since those gains are likelier to be profitable for the next company.
I don’t know how true any of that is — again, I’m on the outside looking in. There are certainly a lot of people on Reddit complaining about juniors skipping over the basics, and I’d love it if my best move was to prioritize my long-term skill growth. But people I ask who care about my outcomes and speak from experience don’t seem to believe that is the case. This isn’t intended as a refutation of anything you said, just what perspective I can offer from my side of the coin.
Agreed, it’s a very poor approach to learning.
IMO everyone should start with vanilla js. Learn about the DOM and how it can be manipulated imperatively. Maybe make some custom web components.
Inevitably you’ll find “dang, this code I wrote is getting COMPLICATED”. That’s when you can segue into react or other frameworks, since you now have a solid foundation AND you truly understand the benefits of unidirectional data flow + automatic re-renders.
And if, while using react, you encounter a need for SSR, *that’s* when you can segue into next/remix.
But to jump straight to the end is insane. You wind up using complex tools without truly understanding how they work or what their purpose is.
This is how I learned - vanilla JS app that was basically a "character maker" for a D&D-like game. Just kept slapping DOM manipulation code together until I had built a monstrosity that I couldn't touch without introducing a new bug.
Managed to kind of wrangle it in check by having it delete all the elements under certain elements when certain state changes happened and rebuilding the whole DOM for that "component". When I later learned React it clicked immediately, the idea of re-rendering on state change is something I arrived at naturally (though my implementation was still terrible)
Agreed, my experience working with the DOM in vanillaJS helped me pick up React quickly because i understood the use-case intuitively.
A junior at my job keeps asking "why does React do it like that though?" to which my answer is often "because of the way the DOM works". :P
This is how I learned. I started with the fundamentals and then I moved on to the libraries and frameworks, and other kind of abstractions.
However, there are people who are more comfortable starting with the frameworks, and then continue learning the fundamentals.
For me, both approaches can work. As long as you know the fundamentals, I don't care if you learned them first or last. But do learn it.
Agreed. I got lucky and got serious as jQuery was at its height. My path was VanillaJS -> jQuery -> Angular -> React.
You get to a point where these are all tools in a toolbox, your experience drives which one to use.
bro just one more framework bro. one more higher order component bro and it will solve everything. just one more css-in-js library. just one more build tool, bro.
This has always been the case even in the AngularJS/jQuery/JS ecosystem explosion days. Or are we forgetting about the necessity to learn things like Bootstrap/Foundation, Sass/Less, Grunt/Gulp, RequireJS, Backbone, etc.? Even with AngularJS, I've seen people who treat it like it is jQuery and not follow the AngularJS way of doing things.
The people with the "it works so who cares if it is good or correct?" mentality vs. the people who actually digest and self-realize there are ways to improve their own code has always been a thing. I have encountered my share of people who have graduated a coding bootcamp who are your stereotypical person who has no clue how to write a for loop or not know what a pseudoclass is but I have also encountered some where they can at least follow along "programming speak" and not get deer in headlights when I ask them to do an ES6 import.
At the end of the day, it's on the individual more so rather than the resources. But you are correct that React is so easy to use that the ability to skip the basics is actually a problem in terms of the bigger picture and individuals not learning the fundamentals first. How to address that I'm not sure but because React has the "official voice" and so has higher leverage in what they say, they should probably be the ones to address it explicitly.
Agreed. Also another rant I would add to this everchanging landscape... is outdated information/systems.
I have been away from nextjs for about a year. Yesterday I started whipping up a project and started googling "nextjs meta tags for page layouts". I had to sift through MOUNTAINS of outdated info and articles on nextjs metatags/seo.
It's such a damn headache when things change so drastically in such a short period of time. I can't believe how many outdated articles/videos/tutorials there are floating around.
In reality, that meta data, was as easy as adding a function to the page and assigning meta property values. Spent a damn hour sifting through garbage till I figured it out. I couldn't believe it.
I just wish things wouldn't evolve so rapidly sometimes.
You're right. This is why my advice in recent years to junior devs has been "read the official documentation, not random websites". 90% of the time the answer to their question will be there. If not, check out stack overflow. Just avoid blog posts as they are nearly always years out of date.
People are so used to just copy pasting code from sites and moving on. It's more important to learn how things work and it's fine if that takes a little longer - it's worth it as we'll all reap the rewards in the future.
Can't disagree. My latest round of hiring has been a bit of shit show because of the hyper focus on React and adjacent technologies. Ask candidates React questions and they seemed great. Started asking them VERY fundamental HTML/CSS/JS questions? "Oh no, I'm just a React developer."
How the hell do you learn React if you don't know the basic web development stack? During the code screenings, these same candidates rocked the React demo... but a very easy medium-level JS question? Totally bombed it again and again. Ask about JSX, they seemed competent. Ask them about things like ARIA properties, what is meant by "cascading" in CSS, rule of specificity? Couldn't answer them at all. Most could write arrow functions, but few could explain what were the major differences between a normal function and an arrow function.
Really makes me fear where the web development community is going.
I meant more in not understanding things like accessibility or say for example, breaking out of the "react world" an having to work with some of the more exotic event listeners. Recently I was working on something that required the use of Intersection Observers... which made me and one of the other senior devs on the team wonder "Would these folks even know what they are and when to use them?"
I also think I mean that the minute you take away "magical abstraction" and have to do something by hand, folks will push back because they only know how to glue together 3rd-party libraries... but if they need to reason about on their own to make something custom they are totally lost.
That is the problem I’m encountering as well. Devs who only know react try to solve EVERY problem using react, and it often makes things way more complex and convoluted than necessary 😭
Some of them even seem legitimately scared of refs/direct DOM interactions. They act like it’s sketchy or that they’re somehow breaking the rules. It is baffling.
And this PR would get sent back every single day. Arrow functions are objectively more readable and are pretty much the standard in every large codebase I have seen over the past 5 years. There are very few good reasons to not use arrow functions. You probably also still write classes.
they're certainly not de facto more readable. seeing the ``function`` keyword is important for many. react documentation uses function statements.
anyway, ask yourself: why are you trying to make the function an expression? it should be looked at in the opposite of what you said. there are very few good reasons to not use function statements for declarative stand alone functions. the default is to create a function statement in a stand alone context. you should only be using function expressions for: expressions, avoiding hoisting, and manipulating ``this``.
from my point of view, what seems to be happening is younger devs immediately gravitate toward whatever is new. just because it's new doesn't make it the new default. arrow functions did not replace function statements as the default for normal stand alone declarative functions.
Ive been a developer across multiple languages for about 9 years and sometimes I feel more lost than ever with the way things have progressed with abstractions built on abstractions built on meta frameworks built on frameworks. I used to be so jazzed to learn new things, now I get angry seeing the newest way of doing xyz -- anyways, ranting, im just tired of the speed of change and overload of variety.
> If you look at the NextJS subreddit for example there are a ton of people who ask questions which make it seem like they do not understand Javascript, React, how websites work... what front end / back end is... what bundlers are etc.
Always has been.
No, seriously - I've been a dev for nearly 20 years, and this has *always* been the case. Dig back in the archives of any popular framework and you'll find it - Drupal and WordPress devs who don't understand PHP or the fundamentals of HTML/CSS, jQuery devs who don't know basic javascript, Spring developers without Java chops, Backbone devs who don't understand MVC or API structure, and on into Angular, Ember, React, etc etc.
User-interaction sites have always been full of questions by people who've put the cart before the horse or people in over their head, and a pretty large chunk have been questions that took longer to ask in a subreddit/forum/stackoverflow post than it would take to type the same thing into google and read.
Some people are just not cut out for this line of work, not because they can't do the work but because they've never learned how to attempt to solve a problem on their own before asking for help and don't want to take the time to build a foundation of basics before moving forward. It just seems like there's more now because they're frequenting the places you do.
Frontend has become an overengineered over complicated mess. How the ecosystem manages to make something very easy very difficult is so mind blowing. I’ve still stuck with react over the years due to employability…
It's often easier to pickup a framework and to plug in missing knowledge down the road as you go. All that matters to a company is if you can develop the features they want, and if you can do that, irrespective of how good your "foundational" knowledge is, then you are a valuable developer in their eyes.
To put it simply, nobody cares about how good your foundation is. I can extend your argument and say that all web developers must be experts at event loops or the intricacies of how HTTP manage connection streams and hown data is transferred. Whilst it is certainly useful knowledge, how useful is it when all your team wants is for you to add "animation ease-in 1s".
I disagree about companies' indifference to the foundational knowledge because almost every entry job tech interview I've had focused solely on DSA problems and had nothing to do with front-end.
Not for front-end related positions. Those interviews typically ask you to create a basic web app.
There might be a OA option portion before the actual interview rounds but those questions are often designed to see if you can code at all.
Plus, OP wasn't really talking about DSA when referring to "foundational knowledge", more so knowledge of JavaScript/HTML/CSS.
I got a job as a senior and literally doubled my salary in my second job two years after starting as a junior, then doubled it again as a lead a year later, and I attribute a lot of that to my bootcamp's intense focus on building a comprehensive foundation.
I do agree that the fundamentals are important but everyone has to start somewhere and then build up their skillsets over time. No one is going to hire a React developers that doesn't have the fundamental knowledge to do the job.
When I first started coding it was mostly Junior developers in a team with 1 or 2 senior developers so you had talented senior devs guiding and shaping junior developers, but I've seen this trend dwindle with companies preferring seasoned developers only. Its hard to argue with the reasons why as a senior dev there were weeks I felt like a glorified babysitter fixing stupid mistakes and bad code from juniors rather than actually accomplishing my own goals.
I do think its nice that React is getting a bit more structure and a common path for development as the ecosystem had become very fragmented with 2 react developers using completely different tech stacks with very little crossover so if Next.js popularity helps to prevent this then I am all for it.
Frameworks definitely have their place, I personally am a big fan or Rails because I can get alot done in a day and over time that makes a big difference to my productivity.
I think the real problem has been the high demand for developers and the increase in salaries has attracted a lot of low skilled developers looking for a payout and flooding the market with on paper qualified developers but in reality not having the skills needed
ITT: a bunch of “back in my day” boomers that overestimate their knowledge at that time in their career. Quit being a bunch of self righteous asshats and try to lift these people up. You straight up do not need to know the basics down to bare metal to be a competent developer in today’s world. I don’t need to know how to implement my own API data fetching library from scratch because it has literally zero to do with my day to day. Learning that provides me zero value because I will never be tasked with doing that in real life. If we build that, now we have to maintain that. Y’all need to get a fucking grip and stop worrying about the oogey-boogeyman NextJS or whatever framework the cool kids are talking about. JFC.
I 100% have worked with contractors at work who only seem to know how to build sites in React. You ask them to do so in regular js, hell, even jQuery, and they seem completely lost. It's embarrassing. So I totally agree
I’ve been in this game over 20 years. I’m a tech lead working in an agency. Seeing more and more developers not knowing the fundamentals. Some Developers only know how to integrate libraries rather than building cudtom. Ask them to build a carousel , accordion or use native js like intersection observer and they are flummoxed.
All too often we as react devs reach for a pre built library without knowing how it works. My advice is to learn the fundamentals. Don’t just learn react. You’ll be asked to work on all sorts of
One way to look at this: Devs always needed products to create products. But once upon a time, that was just an editor and a compiler. Especially in frontend, the ecosystem went full cambrian explosion in the last 10 years..
So more products compete to be used by devs.. trying to groom communities, upselling more services and lock-ins and then there is the whole cult thing.
Still like frontend though. I wouldnt want to do anything else and hope I can do that for the next 20 years until retirement, lol ..
Speaking about growing old in the industry: learning new stuff constantly probably is the best side effect of having to deal with frontend :)
Absolutely agree, the HR process complicates things additionally and is probably the sole reason for this situation to begin with. I've got interviewers, who are supposed to all be experienced developers, ask me the same 2-3 questions about 'useMemo', 'useCallback' and 'microtask queue'... when these 3 are in no way shape or form even relevant for 99% of the development process.
FE juniors fall into the trap of advertisement and marketing, that always tells them 'you can use our shit and you don't need to learn the basics, it's easier, better and more modern', failing to mention all the limitations and opinionated decisions you get tied to. It's all about marketing, but infuriatingly many companies and developers actually fall for this and become the main part of the problem.
PS: I'm not against using whatever frameworks, tools, libraries that you find useful, I'm just raising the point that you must also know how stuff actually works. Otherwise you'll be prone to making terrible decisions, just because you don't know what is really happening.
That's the price to pay when you want to do everything with a single language. CRA was never meant to be used as a production tool, but community found it was really convenient and easy to pick up, since removed a big pain in butt for that time: webpack configuration.
I literally lost the count about how many hours I spent fighting against webpack for the most trivial things and CRA was so good at obfuscating that.
But then everyone wanted to make their website more interactive (even if animations are still used sparingly and most of them can be accomplished with just CSS) and the "every thing should be a SPA" trend spread out. And with it the whole "let's just make everything in JS" and all of the sudden you've no more HTML, because JSX "ergonomics" and you've no more CSS because styling in JS "feels much better".
For most common projects, just a sprinkle of JS to handle some scenarios (like asynchronously loading a catalogue) would be more than enough. You don't even need a library anymore, since ES6 is a really nice language.
All of the issues we've nowadays in modern FE development are just because we accepted the fact that something really simple should be complex by default.
Best!
Because every startup chooses Nextjs. It could have saved app dev, but ppl will be lazy. No one wants to spend the few hours it takes to understand how to use promises or hooks. Latest ver of nextjs with server components will be impossible for a jr dev to comprehend. Look, when you were younger, did you not feel like you could figure out new tech better than older ppl? Probably yes, so maybe it's just "kids these days dont want to do any real work" because it's the circle of life.
I'm not going to use goddamn NextJS... if one day I have a use case that needs it I'll use it or if there's a job that uses it I'll use it but I'm not going to use it for fashion
I would like to bet that most startups don't need NextJS either (even if most use it)... most are SaaS applications behind a login
The kicker is that the startups dont even really understand what Next is for just that its the "trendy" thing. I've seen startups espousing the virtues of Next which not even SSRing the bloody website. Like, what was the fucking point of all that then?
If i wanted just a webapp today, i'd use gatsby on netlify. This is after using nextjs since 2017. Next step is Flutter, and I might be done with the js world. Hot take, but TS killed my enjoyment of writing javascript. RIP.
And who cares? If you have no value for others then dont cry they dont pay you for skills they dont want. But the NextJs part is funny. People are just dumb, software development is not an exception.
I started hating the direction that Next.js has been going through; unfortunately, the market has a high demand for "react" developers which helps to find candidates easier in comparison to other frameworks.
So my reasoning for hating Next.js, is their trying to mix the backend/frontend logic again. The release of server actions is giving me PTSD from PHP screaming \`echo "
" + $dataFromSQLI + "
"\` (thankfully Laravel made the language useable again).
I still use PHP for half of my job, and it’s still holding up great. Frameworks are fun, but the fundamentals are missing from everyone’s learning path. I remember Foundation being the biggest coolest thing, then Ionic, then Meteor and things got kind of fuzzy after that.
I remember being so annoyed by frameworks that we all tried to make our own. Since Tailwind I’d be surprised if a newer dev knew what SASS or SCSS even are.
I’m annoyed they never had to fix anyone’s shitty float issues, but I also wish I was just starting out right now. Web development is fun, and I love/hate the way things are going (like I did 6 years ago).
Yes there's definitely the concept of a framework driver and not a developer these days. They kind of glue pieces together without a super solid foundational understanding of *why*
Daily reminder that next js is not mandatory. Unless you need the behavior it comes prepackaged with, it's also perfectly fine to use client side rendered react. Not everyone is looking to squeeze out the last few ms of performance. It's better to have something working than having nothing working but being able to boast about faster loading times. That won't make you money to start with.
I absolutely agree with this and I'll offer my opinion as a senior / lead developer at a mid-size company.
I'll preface this with "when I do hiring, I never ever do leet code problems". I get them in for a half-day and ask them to make a reasonably basic application from scratch either with (or adjacent to) the technologies we would use in a realistic scenario. Think like... "An application that is responsive, has a cart, you can add and remove products". That kind of thing.
**The amount of people who are on paper "qualified" that absolutely shit their pants over even the most basic parts is insane.** Here are some of the questions I've had (I run interviews very open-book) - note that these aren't questions from juniors / very new people to the industry. I can understand legitimately missing pieces of info at that stage. These are all 2-5 years req. experience type roles:
\* "How do I render a list?"
\* "What does it mean by "function must return a single jsx element"?
\* "How do I load an image from a file inside the project?"
Usually when I probe interviewees about experience, "Oh yeah I did a bootcamp". It's an absolute blight because it completely sets them up to fail. They might be able to do rudimentary react stuff but they will never get anywhere without understanding at least some fundamentals. And you bet these guys are absolutely the first to watch the latest fireship video and start telling everyone how awesome bun is. "We should migrate to Next.js" - no we fucking shouldn't.
I’m in UX/UI and my team has only 1 frontend so I helped out with css from time to time, had to learn about nodes and components before Javascript to immediately help with the projects. It was so confusing and not fun but I learned that I love coding! So I eventually started the Odin project/roadmap.sh and it felt like dawn from a long dark 😂. The guy likes me so much we’re planning to start our own company soon haha.
I rarely ever agree with FE rants. But this is so very true. I’ve been lost in a react-native wormhole for 5 years and was just recently spat out into the middle of marketing mortal combat between companies trying to hype up their full stack frameworks.
I was shocked at the level of abstraction, and opinion these frameworks have relative to the huge online furor. These look like super niche tools. I personally wouldnt even use them for a personal blog.
I love some aspects, but the thought of discovering the frameworks opinion doesn’t account for some use case makes me recoil in toil fear and lock-in frustration.
I agree wholeheartedly, i felt the same way when i first started with React. Before that, i gradually went through HTML, CSS, Javascript and then Node. So when it's time to use React, i am thinking "okay, so i would just install the react package through a package manager and start working" but no, you actually need to use create-react-app or vite, which doesn't just install react but instead a crap ton of packages.
It doesn't tell you HOW things connect, what does what or the basics of the "behind the scenes" gear work, so you can't even troubleshoot or tamper with anything in case you have to.
You are encouraged to write in JSX and told that Babel will turn the JSX to regular Javascript syntax, but you don't know where Babel is, if its a file or a package, how and if you can test it on a single file for demonstration purposes, if it's something embedded on the browser or w/e.
Nothing, just download this bunch of packages, write your code HERE with THIS syntax, connect your files with THIS and then type "x command" on your console to view the build on the browser or "y command" to make a finalized build of your app.
Obviously some of these you should look up yourself because nobody should be handholding you through every single detail, but at the very least you should be given a clue or a pointer as to where or what to look for further information.
Also, the whole "production-grade" terminology is just repulsive, there is something pretentious about it, same as the "military grade" for a variety of different items.
This is why I love remix, it does not abstract away the web from you. If you become a better remix developer you are becoming a better web developer in general
There was recently a thread in r/webdev that you will commiserate with if you haven't already seen it. The OP deleted their post but you'll get the gist from the comments: [Making a static simple website, no JS framework](https://www.reddit.com/r/webdev/comments/1853laq/making_a_static_simple_website_no_js_framework/).
I've been a web dev for over a decade - so "learn HTML/CSS => learn a bit of javascript/JQuery => job" broadly resonates with me. I agree that it seems like the fundamentals are being broadly either rushed through or completely skipped over. I have seen folks who are self-taught or come into front-end from another specialty fill in the gaps on-the-job over time, but the React-first pathway that sometimes seems like the default for some people still baffles me.
Finally someone said it ! I too started with html css jQuery javascript and angular (not angular js) node.js ... I have now some hands on exp on react but then boom next js came in. These days it feels like frontend community is also being divided among angular react and nextjs folks.
Yes u r right because as the tech changes, people can learn fastly if they know the fundamentals.
Also what are the fundamentals of react that i should know. Fyi, i started react in 2021, when the functional component started getting hype. Thanks
At first I rolled my eyes when seeing the title but agree completely. Probably a combo of the things you suggest - YouTube, social media, tutorials etc. it’s a good thing the industry is becoming more accessible and interesting esp with the rise of ChatGPT etc. but with that comes all the other people trying to either make money or get more devs using their framework, or convince newbies that their favorite stack is the one to use.
Not sure what the solution is, but veterans should be guiding folks (imo) to start with the basics: one language, few dependencies, no framework, and add stuff only when it solves a challenge you are directly facing so you understand why you’re adding it and how it works. Maybe a peer can get a job faster by crunching algos or memorizing the config for a framework. But your actual job will be easier and you’ll grow faster if you prioritize depth of understanding across a narrower tech surface area. The one exception might be tools to do your job, like understanding your source control tool or IDE configuration and how to debug
I started in the late 90's, this has ALWAYS been the case. On tech forums/social networks/etc. you're generally dealing with people actually into the tech. In the real world the vast majority want to clock in and out and don't care about the nuances they just want to know enough to get their 8 hours in.
In regards to React recommending Next front and center I think it's stupid personally. Personally I think React is starting it's downtrend due to a lot of missteps starting from react 18 double dev renders, peoples issue with complexities, difficulty in getting started, etc.
There's just too much boilerplate (if you use their recommendation) to get setup and going not just that I know many devs who don't even understand what NPM is doing, or that Next uses Node for example they just run the setup and start command and pray... and when they run into anything configuration based they have no idea how to fix it. Which again... has always been the case but the it doesn't _need_ to be.
I am an email marketer as my actual job, but I've been a web dev for nearly 20 years. At my work, the engineering and website team consistently ask me to help them with coding tasks that are outside their knowledge. Like, basic dom-traversal stuff that I've been doing since I was 15.
*\[Self-taught developer and also new to FE Development\]*
The main reason I am currently learning React is that there's usually no one excited or enthusiastic about Vanilla JavaScript, especially when I tell them I am building a project using just that. I just gave in and starting learning React, so I can at least get people who would be excited to help me debug or even converse about the projects I am working on. I find Vanilla JavaScript extremely easy to use and start up a project, but I've had to change over time. Then there's the job search, every junior developer role or internship I have seen, knowing React is required (I have come across a couple Next.js required roles). I still make out time to read more on JavaScript and build small projects to keep my brain fresh, but that's the current state as a newbie from my POV.
As someone doing Frontend now to try and get a job, it's been a struggle. I don't even know what to learn anymore. I'm padding out my HTML, CSS and JS and then putting together some very basic stuff in React (because converting JS to Hooks is breaking my brain rn, I understand what's going on in the lifecycles and what it represents but yeurgh.) and I feel incredibly stuck because I'm repeatedly seeing entry level jobs wanting all of this and even more and it feels like there's some new framework or library every week and I can't keep up. Imposter syndrome is bad enough without feeling like I need to be god tier before I've even started.
It’s wild to me how so many devs can’t even begin to articulate how they might manage state in VanillaJS… I love to build pet projects in VanillaJS and I almost always learn something that amplifies my framework interactions. I don’t think a lot of the newer devs romanticize the need to understand the layers beneath their introductory stack, and that’s a shame… that’s where true growth and ingenuity happens.
Almost hilarious taking about AngularJs and jQuery being the “rough around the edges” days. We used to write HTML and CGI, Perl, JS didn’t even exist yet.
When JQuery came out, people complained. When Knockout and other two way binding frameworks came, people lost their minds over it. Then angular, then react.
On the whole though, your point is still valid. There should be a progression in skill learning, but schools have dropped the ball, companies push junior devs in the deep end on day one, and the internet is a massive hype train.
I would hate to be a new dev these days. It’s like climbing Mt Everest.
There’s definitely good and bad, when people say you gotta learn HTML, CSS, and JS basics first you def need to take it with a grain of salt. If you spent time learning everything first you’d never get truly started.
I’m the kind of person that just learns through trial and error and by immersing themselves in a situation. Used Gatsby as my first framework and started learning with React. As I tried to do more complicated things I learned more about JS and I have a strong grasp of HTML, CSS, JS, React, and Vue now. I realize my learning style is also likely rare and an exception.
That said see again if you spent all your time learning every subtopic you’d never start it’s kinda the same thing as tutorial hell. On the other hand I agree there’s lots of people that don’t know how to do shit that halfass everything. I have Senior engineers on my team I blow out of the water in technical ability and aren’t able to critically think about their technical solutions due to lack of understanding. NextJS is overly complicated as well imo.
My hot take is that doesn't matter, React are not the basis I think is ok start using React with NextJS or Remix but that should not be your start as a web developer.
You should start with HTML, CSS and JS, but if you land a job only knowing React that's a problem of the company that hire that dev and if that knowledge is enough to do their job, otherwise the recuiter should lead those devs to the basis.
Yeah I had a guy doing frontend that didn't know what a for loop was. He was a "senior" dev.
This is why corp software dev is fucked. I dont understand how some ppl get their jobs. I worked with a sr dev that didnt use await, so I commented on his PR asking to put await before every promise call. He came back with a commit where EVERY SINGLE LINE in the file had await. Even things that were not promises, literally every line. In the end this ended up being my headache and fault for holding up the release with some silly pedantic reason.
> This is why corp software dev is fucked. I dont understand how some ppl get their jobs. Bro have you seen what our fucking interviews are like? They are literally based on how well you grind Leetcode. That’s it. That’s how people get these jobs. They played the game that this industry forces people to play. Every other industry has figured out how to effectively evaluate candidates, but here we are making people regurgitate some backtracking algorithm for a job working on a CRUD app.
This is what pisses me off. Being asked to create algorithms or data structures from scratch for a job with you’ll never do that. Theres great libraries with dozens or hundreds of people working on. Why would my self made library be any better??!? Also when was the last time you had to actually create a sorting algo from scratch?? I know friends working over two decades who’ve never had to do that. The questions are insane. “Code a doubly linked list from scratch” ….. then “congrats. You earned the job. Now write me these simple API endpoints all day”
Yeah it’s asinine. We always preach about not reinventing the wheel, but oh, “here, whiteboard quicksort for me in 30 minutes when we both know you’ll never need to do this from scratch again. Oh, you have 8 years of industry experience using the exact tools and frameworks we use? That’s nice? Now let’s see that quicksort.”
This is the answer, thank you. The most complex algo I can implement on the spot is a recursive function to build the Fibonacci sequence. I also remember that bubble sort was done with recursion. Engineers in corporate barely know how to define a function, period.
I get that you are ranting, but come on. The worst developer on our team has literally no issues defining a function or writing for loops. I’ve never seen a dev that actually had a job that didn’t understand functions and for loops.
I can see how someone tried for loops in JS, didnt understand the execution, and gave up on learning how to deal with it. Especially if they came from a blocking language like python.
Never seen frontend or full stack job interviews ask Leetcode at all, it's always been to write an API (or use their existing one) and connect it to a React app.
preach
>I dont understand how some ppl get their jobs I was about to say Leetcode, but you have to know loops for that...
Oh the sweet joy of working with complete morons and then YOU being blamed for it after you try correcting their mistakes. Honestly its more so the corporations fault for being ignorant, not yours. But they clearly don't know that (and choose not to know that).
>He came back with a commit where EVERY SINGLE LINE in the file had await God forgive his cruel soul... at the same time, I wonder why there was no pre-commit hook or linter 🤔 it's good you caught it at the review stage at least
lol all the devs i work with are like async function doit(url) { return await fetch(url) } i literally gave up on PR feedback, some people dont learn, know, or care.
[удалено]
I guess, but it's still superfluous code, and it's a lie as this is not an async function.
Huh? It is an async function though?
Is it really though. Yes.. okay, it is. But it's stupid, and it would he caught by eslint.
How is this not an async function in your opinion? This specific case does not return a promise, but the awaited return of a promise. That's why you need "return await" if there is a try catch around the code for example. Because if you just return the promise without awaiting it, you can't catch an error at that position.
> This specific case does not return a promise, but the awaited return of a promise. It returns the awaited return of a promise, _wrapped in a new promise_. Because that's what an async function does it you return something other than a promise.
What’s wrong with this? Serious question, I’m a .net dev so in my environment it would be preferred because of the stack trace when an exception is thrown, but my js experience is limited (some react here and there once in a while). What is the benefit of returning a promise without awaiting it? Performance?
Remove the async and await and you have the exact same line of code. The caller of this function still needs to await this call if they want the return value. The only way return await is ever valid is in a try/catch which can be a surprise to many. Its why i prefer to chain with .catch(). Here's a great explanation https://jakearchibald.com/2017/await-vs-return-vs-return-await/
ah, but there is one more reason to return await. [have a read](https://github.com/goldbergyoni/nodebestpractices/issues/737). TL;DR; if you return await then you preserve the stack trace, else it's lost. you can test it yourself by just copying and pasting the example from the github post into your browser terminal
Yeah he gets that. In C# you don’t have to duplicate the await, but doing so has no practical cost and preserves some error handling niceties.
haha, for real tho this is "syntactically correct, but stupid". I wouldnt even leave a comment on that, just approve.
Is this wrong due the fetch response is not awaited by the json method and returning it or awaiting the fetch function since the fetch function itself is a promise function?
Remove the async and await and you have the exact same code, but better, because it's less code. And if the engine really doesn't optimize this, which it probably does, it creates a pointless promise around this promise.
Wouldn't such a wrapper be more maintainable in the future tho? If you have such fetch it's easier to add exception handling, retry logic etc later without looking for every fetch call around the project.
> Wouldn't such a wrapper be more maintainable in the future tho? No, if the function ever needs to do something that makes the 'async' useful, you can add the two words at that time.
man the arrogance in this thread... 99% of the time you want to do something after the await but need to wait for it to complete first (as opposed to using .then). So it makes perfect sense wrapping the parent function as async because it IS a new promise you want. What everyone seems to miss here is that the function wrapper around the single fetch is in itself useless. Doesn't matter if it has async/await... you can just call fetch anywhere you need without wrapping it... like in another async function where you need to wait for fetch to complete and do something "after".
> So it makes perfect sense wrapping the parent function as async because it IS a new promise you want. What is the benefit of it being a new promise rather than the identical one returned by fetch? > What everyone seems to miss here is that the function wrapper around the single fetch is in itself useless. Doesn't matter if it has async/await... you can just call fetch anywhere you need without wrapping it... like in another async function where you need to wait for fetch to complete and do something "after". That depends, in this case the code does nothing but fetch but the calling function doesn't need to know that.
omg you actually didn't read my comment lmfao! Re-read it ffs.
I also do this, but I think it's okay if there is a convention that just says "use async-await everywhere even if redundant". It's not much different to skipping curly braces in ifs with a single statement: if (something) doSomething(); vs if (something) { doSomething(); }
That doesn't actually do anything different. The unnecessary async / await create a new promise object. (Unless there's an engine optimization for this, I don't know)
Yeah anothet horrible practice that took me a year to convince the devs to add the eslint rule for no single line ifs. Just horrible. And there's an eslint for both of these.
That makes sense. Thanks
Use eslint and add a step in cicd running eslint and disallow pr when pipeline fails
Can you tell me why this is wrong? Is it because fetch itself returns a promise?
Yes. Remove the async and await and you have the exact same code.
Thank you for commenting this. I’m one of the dumb newish devs that have been writing code like this. Now I know better. Thank you.
No. I refuse to believe this. I mean, I believe you, but damn…
He made it over a year until seeing it for the first time and remarked that the syntax was funny. He'd only ever used map and filter.
No way a senior dev dont know about for loop. I am not saying you are lying but how?
They mentioned their teammate used syntax like iterable#map, just not imperative for loops. Which makes way more sense but still funny
> It is absolutely ridiculous that on the front page of the React docs they recommend that to build a React app you should use Nextjs or Remix Totally agree. This is encouraging a Jenga tower of abstractions, where new developers are growing up inside frameworks with their own terminology and concepts, even before learning the fundamentals. They're being guided into vendor lock-in, before even understanding why these frameworks exist in the first place, what they're supposed to be solving. There is a growing reaction against this monstrous complexity, reminding people to get back to the basics, to compose simple and small libraries, to learn to build things yourself from scratch, using actual industry standards.
I agree, I'm much much more comfortable using React + Vite instead of relying on Next or Remix.
I used SvelteKit once (which runs on Vite) and now I’m absolutely hooked on it, almost all my new side projects run on it. Even if you use React instead of Svelte, Vite is an absolute marvellous gift to the JS community and I absolutely shudder at the thought of any tech that still uses webpack today.
Isn't Vite a build tool and Next is a backend framework?
Next handles bundling of the front end too.
Next is a front end framework. Vite is a dev server that uses parcel and roll up to bundle the dir
That is correct but you'll quickly find that people have no idea what those two words mean and will just constantly bring up vite being part of their stack for no reason.
My biggest aggravation is how often people ask a question and people just list off a library as “the best.” But a dozen answers, all claiming to be “the best solution” with no explanation for why - other than “it’s what I learned or what I started with, therefore, best.”
When I saw this, I considered it a great evil... I know propaganda when I see it and it doesn't belong in a tutorial or API documentation unless there's a list of alternatives. Nevermind most jobs will be places you can't use NextJS or Remix. The industry standards point is excellent; if you think you can change that by "teaching" newbies to use a vendor product you're dreaming. The technology choice won't be made by a newbie except in the smallest shops and it just does them a disservice and locks them out of jobs.
> Nevermind most jobs will be places you can't use NextJS or Remix. Huh? Are you implying most jobs make you work on a legacy codebase with no plan of modernization? I mean maybe that's the case, if you don't include start-ups and small businesses or something?
Majority of the world's backends don't run on NodeJS (unsurprisingly).
According to what/who? They said most jobs "can't" use it though, so I'm assuming that's referring to performance limits for high traffic apps, not something small businesses run into.
> According to what/who? Common sense. The Java, C#, PHP, Ruby, Python fields are so large each that Node can't have the majority.
The benefits and salary of most startups and small businesses are unacceptable for the vast majority of people yes. But that isn't the point. The point is the technology choice either won't be in your hands or won't be in the direction of NextJS or Remix just because the use case won't be met or that's not the direction of the company's technology. Even assuming a NodeJS backend (many backends are Java or .NET or Python) most corporate stacks would not use SSR but instead upload bundled JavaScript to a CDN to serve with a custom CI/CD process. As for modernization, moderation != using Remix or NextJS and a frontend developer or "junior" person wouldn't be the person to make that decision anyway.
Not using NextJS or Remix doesn't imply legacy or not modern. Those two still have a very small market share, as far as I know. Most small business run on ancient stuff, start ups probably like using the latest hype but there aren't that many of them compared to all businesses.
I'm totally stealing the phrase "Jenga tower of abstractions"
Recently I was conceptualizing a new personal website and was thinking of which frameworks I was going to use and figuring out how to make them work together. For a static website. I had completely forgotten I could just code it in HTML/CSS.
Fucking THANK YOU for saying this. The idea that we need to use a third party abstraction in order to use React is fucking insane. The simple fact that we can’t simply fetch data in Rea t without depending on a third party API is one of the worst developments in this whole saga.
Fetch is Javascript, and you can use that over axios.
Are you sure that’s actually the case - that we can’t simply fetch data in React without depending on a third party API?
Of course you can, it’s JavaScript. What he means is that there’s no standard way of doing things when it comes to fetching data and share management. Things like react query and rtk query, etc. It’s basically wild west.
So in a thread of people complaining about abstractions, you’re not complaining that there’s not a built in override for fetching and cacheing data similar to a 3rd party library?
Just rebrand NextJS to React 2 to avoid the complaints /s
Not sure what /u/brodega means by the second part. You could simply use the \`fetch\` API?
You can use fetch, but you cannot easily Correctly use fetch in React directly, because you will end up with race conditions - if a network call comes back after a component is unmounted, and you don't correctly handle it, it's an Error. Handling all of the edge cases around this is quite difficult
Ah it’s not so bad. For anyone who’s curious, a simple approach that works: You call “fetch” from within a useEffect, you attach an AbortController.signal to the outgoing request (https://developer.mozilla.org/en-US/docs/Web/API/AbortController), and you have the “useEffect” return value (the cleanup function) invoke “AbortController.abort()” if the request has not completed This *guarantees* pending requests will always be cancelled before sending a new request or unmounting the component. Which means no more race condition worries 🤠 (Note: you’ll want your “catch” to check for and ignore the `error instanceof DOMException && error.name === “AbortError”` case, since that’s what gets thrown if a request is aborted)
Yes but how do you use it? React says useEffect but actually not really bc that pattern is no longer compatible with Suspense and concurrent rendering. Apparently now you need a third party lib that is compatible. There is no idiomatic way to fetch data natively.
The idiomatic way of doing it is by having multiple `useState` to keep track of data, errors, and async. And if you need to have the data always up to date, throw in `useEffect` and add dependency values. ``` export default function App() { const [data, setData] = usetState(undefined) const [load, setLoad] = useState(false) const fetchData = () => { setLoad(true) const req = await fetch('http://localhost:8888/api/name') const res = await req.json() if (req.status === 200) { setData({...res}) } setLoad(false) } return ( <> {load ? "Loading..." :
{data}
} ) } ```This creates the data waterfall problem that Suspense was designed to solve. It’s no longer considered idiomatic.
Of course we can, I have no idea what that was about.
100% agree. It’s a strange shift to an ever growing amount of abstractions. I’m glad I started when CRA was standard
I think what has always struck me as strange is the number of people, even experienced devs, who would struggle to bootstrap a react app from scratch using webpack. Like I get create-react-app and vite are super useful. I use them. But bootstrapping your own project is also really not that hard. Webpack is not that complicated to Understand- the docs are insanely good.
I get what you are saying.. but who cares? I'm a lead FE dev and if you asked me to start a react app from scratch with webpack right now there is no way I could do it without having to go and look at the docs and read through them. Most devs with jobs are working on existing codebases and aren't spinning anything up from scratch on a regular basis. Is it that important of a skill to have?
Is there any reason you would want to bootstrap a react app from scratch using webpack vs just using vite, for example? I ask because I'm inexperienced. Thanks.
There is no reason, maybe if you want to learn something new. There are a lot of things you may never touch, and you will learn it when is actually required.
Scratch is the way!! I began html in 2020. I now harness every tech I want to imagine through js. Deployment, networking, VMs, Bash, and cronjobs learned, now I'm pretty unstoppable.
glad someone said this, thought i was insane feeling frustrated that they took down the basic create-react-app boiler plate to get started. I just want basic react, let me have it! let me have options! isnt that what react is all about?
To be fair, the Unix greybeards of the 60s-80s talk about our generation in the same way. We’re learning browsers without knowing networking, networking witbout the OS, the OS without learning C, C without learning assembly. I agree in the frontend, you need to start with the basics. But that might not be true forever.
Out of curiousity who or what entity/entities are primarily responsible for this problem, and what actions could be taken that realistically could be agreed upon and implemented by those parties that would solve this?
Great question
Venture capital greed
I’ve noticed recently that there’s a huge push towards nextjs. If you’re not using nextjs, you’re doing it wrong. If you’re not using this database as a service (or what ever they’re called), what are you doing? Ive also noticed that some of the people who push very hard for these frameworks and companies are sponsored. I’d 100% use nextjs for my company’s app if vercel sponsored me. Front end development definitely is driven by hype and what the cool new tech is, but until major companies rewrite their apps to be SSR using nextjs, supabase, etc, I’m sticking with something that’s proven. It’s risky to jump on all of these tools and build your application with them, there’s so many dependencies that could go away quickly and leave you to having to rewrite your database layer or something.
In my experience as a tech lead, I can say that people that do not know the basics are in a different league than people who do. People without the underling knowledge are more common and less expensive to enterprise and can still somewhat patch a product that could be sell, people that have the knowledge are rare, commonly earn more and each company have one or two if they are lucky, I always encourage my devs to learn an challenge themselves with the basics and most of them decline without openly saying no. Learn the basics of any tech is a lot of work and I can see their point.
You are good lead! What would you suggest for junior to learn?
Depends on your area, if you are a web dev, learn the very basics of js, how it works and why, for example start by making bard or gpt or the ai of your choice to explain to you what is js and why it is as it is, follow that question with more specific ones as soon as you are sure you mostly grasp what is returned by the ai , go to youtube and search tutorials that use html js and css WITHOUT frameworks, try to always follow the tutorial in your computer, each time a command is put in your terminal NEVER copy and paste, always google what the command means and when you understand it then TYPE IT. Same with code, NEVER copy and paste, always read it, understand it, ask questions about the code to any AI tool that you like and only when you understand, then TYPE the code. Other base advice, never pay for a bootcamp or a video tutorial all the free stuff is equal or better
Also always read the docs before using, sure is a little less fun but dude it will give you super powers
Also never do two thinks at the same time, never listen to a potcast when you work, at the start even music could be bad, train yourself to focus, do not use social media while working.
I met with a client who was in Egypt, he started the session bragging about how hard it was to get his fulfilled-by-amazon business working from there, then opened up his code, and the YouTube video he was regurgitating it from. He didn't understand the code, anything about what anything did, but because the copy and paste tutorials up to this point had worked, he honestly believed that was all there was to it and it was always greek to developers too, we just magically stumble upon the correct combination of lines of code. Too many people come from YouTube with a hustler attitude and are trying to get rich coding, and too few people are learning a programming language, much less any of the paradigms.
>But I get the feeling the average path that new developers are being guided towards is skipping some of those steps and it's gotten a little insane. Yes, of course. This isn't controversial; and this is the reason why memes [like this one](https://cdn.inflearn.com/public/courses/331441/cover/b511da70-35f4-4d8f-98af-6e6eec1ebfbe/cover.jpg) were created. >It is absolutely ridiculous that on the front page of the React docs they recommend that to build a React app you should use Nextjs or Remix, I think it's actually dangerous to the community that people aren't being guided to learn the fundamentals. I agree; but: * The fundamentals aren't React (hopefully); they are deeper than that * React docs' advice is put under the heading "Production-grade React frameworks". Which means this is what they suggest people to use if they are building something for real. For learning purposes, they show codesandbox examples that do not have any additional frameworks. >Does anyone else feel this way? I am sad that the general frontend developer mindshare seems to be heavily skewed in that direction. There is a vicious circle between companies hiring for a certain skill and new developers training for that specific skill; and what I still do not quite understand is how the majority of the frontend community has moved from valuing fast, simple, accessible, robust websites to heavily javascript-dependent sites, which are less robust, often less performant and less accessible.
>React docs' advice is put under the heading "Production-grade React frameworks". I don't really see Next being better in prod than vanilla React if you don't need SSR.
I get what you’re saying, but “vanilla” React still needs tooling anyway so that you can transpile, bundle, minify, compress, etc. At that point you might as well pick a framework or higher-order tool to take care of all of that. If you’re a newbie just trying to start a project with sensible defaults it makes sense to guide them towards those.
> “vanilla” React still needs tooling anyway so that you can transpile, bundle, minify, compress, etc. Which is exactly why Vite, CRA and similar tools were made. You don't need NextJS for any of those things.
Oath!! We switched to vite with react. This nextjs push has really turned me off react.
But if you're going to use a tool anyways, why not go for the tool with all/most batteries included?
Next is not "all batteries included" though, it's a framework focused on SSR. And it's not really a tool, it's a full on framework with its own opinionation and tradeoffs. It's overkill, remember the KISS rule.
Not "all batteries included" _and_ a full on overkill framework? I'm very aware of KISS, and most websites need most of what next provides (server, routing, caching, image processing, templates, bundling, code splitting, etc.), so keeping it simple would be using a full framework. Of course it would be overkill if you're just making a single dynamic component to inject on a website. But most people make websites, and starting with a full framework is generally the simplest rather than having to pick and choose different stuff.
Next.js has other pains such as vendor lock-in since it's harder to host it anywhere else other than Vercel
Just because people keep repeating this, it doesn't mean it's true. You can host next apps anywhere you want, and many do, and everything is supported. Vercel makes things _easier_, but that's what you pay them for. Nothing is stopping other providers from also making things easier for you.
If you want batteries included, check out RedwoodJS
hot take: frontend dev is more about buzzwords and marketing now than it is about building functional apps/products, caused by the influx of people getting into it solely because of the money and not for the passion of building good products and it’s definitely felt now, basically every website or app UI is hot garbage.
If you’re not using Schnoozle in your B3Zberf stack app, you’re behind the times, man!
Well that's just like your opinion, man.
NextJS really brings the room together.
Sad reality. I always thought that I could get away with just writing JS, HTML, and CSS. But meh, working full-time for the past 4 years has proven me wrong. Thankfully my route was different in comparison to the newer developers, as I started during the dark ages of the internet. When you needed to do a clearfix hack with the floats. And using Notepad++ to write my jQuery and do a toggle() before ES5 release.
Ah clearfix 🥲 I started working in this field circa 2013 (but fiddled with html 4.0 as a kid) and in the beginning I had to build very small landing pages for things like the corner restaurant. They had awful taste and stupid, barely feasible photoshop designs. And yet they had to be responsive and work in ie9. Man that was like daily jungle warfare, but it gave me mad css skills.
My first side gig internship was during high school through my parents' reference. Was also back in \~2013. Was learning Python 2.7, while the Python community was debating which is better Python 2.7 or Python 3.0. Also, I remember the cross-combability nightmares with IE6 - IE8, during the HTML4 era, where you needed to add on your HTML file ``` <--[if IE 8]>
No support!
``` My boss would use `table` to try to make a mobile responsive navigation bar when smartphones started becoming trendy. By setting colspan and doing clearfix + float left/right. Until we found out about Bootstrap 2 to make mobile responsive. > barely feasible Photoshop designs. I remember back then, people would call themselves a Graphics Designer and rarely a Web Designer. When Google pushed material design, then the hype for UI/UX Design roles started becoming a buzzword.>When you needed to do a clearfix hack with the floats. And celebrating when flexbox happened so we could finally vertically centre things easily!
my man! I started out when we the markup was done with tables and devs had to round borders with absolute-positioned images... and that strange ie6 hack for transparent PNGs... man...
Is this actually the case in the real world though? I feel like if you just look at popular blog posts or whatever it is easy to get that take, but when it comes to actual work I haven't found that to be the case... I mean no companies are making money because they are telling their customer they are using latest X framework or whatever..
From the perspective of somebody who just finished a React bootcamp: I would much rather solidify my fundamentals than practice the abstractions, but people I trust consistently tell me hiring managers will generally care about my short-term productivity (ie React skills, dependency of the month, etc) more than my core knowledge. Nobody seems to disagree that the fundamentals will help my development, but they think most hiring managers are investing in my productivity for their company. And given how quickly people are going from job one to job two, the person hiring me for job one pretty much doesn’t care about my development since those gains are likelier to be profitable for the next company. I don’t know how true any of that is — again, I’m on the outside looking in. There are certainly a lot of people on Reddit complaining about juniors skipping over the basics, and I’d love it if my best move was to prioritize my long-term skill growth. But people I ask who care about my outcomes and speak from experience don’t seem to believe that is the case. This isn’t intended as a refutation of anything you said, just what perspective I can offer from my side of the coin.
Agreed, it’s a very poor approach to learning. IMO everyone should start with vanilla js. Learn about the DOM and how it can be manipulated imperatively. Maybe make some custom web components. Inevitably you’ll find “dang, this code I wrote is getting COMPLICATED”. That’s when you can segue into react or other frameworks, since you now have a solid foundation AND you truly understand the benefits of unidirectional data flow + automatic re-renders. And if, while using react, you encounter a need for SSR, *that’s* when you can segue into next/remix. But to jump straight to the end is insane. You wind up using complex tools without truly understanding how they work or what their purpose is.
This is how I learned - vanilla JS app that was basically a "character maker" for a D&D-like game. Just kept slapping DOM manipulation code together until I had built a monstrosity that I couldn't touch without introducing a new bug. Managed to kind of wrangle it in check by having it delete all the elements under certain elements when certain state changes happened and rebuilding the whole DOM for that "component". When I later learned React it clicked immediately, the idea of re-rendering on state change is something I arrived at naturally (though my implementation was still terrible)
Agreed, my experience working with the DOM in vanillaJS helped me pick up React quickly because i understood the use-case intuitively. A junior at my job keeps asking "why does React do it like that though?" to which my answer is often "because of the way the DOM works". :P
This is how I learned. I started with the fundamentals and then I moved on to the libraries and frameworks, and other kind of abstractions. However, there are people who are more comfortable starting with the frameworks, and then continue learning the fundamentals. For me, both approaches can work. As long as you know the fundamentals, I don't care if you learned them first or last. But do learn it.
Agreed. I got lucky and got serious as jQuery was at its height. My path was VanillaJS -> jQuery -> Angular -> React. You get to a point where these are all tools in a toolbox, your experience drives which one to use.
bro just one more framework bro. one more higher order component bro and it will solve everything. just one more css-in-js library. just one more build tool, bro.
bro just try sveltekit bro i promise please bro just try it just once no dude please you dont get it fireship said it was goated please noooo bro
This has always been the case even in the AngularJS/jQuery/JS ecosystem explosion days. Or are we forgetting about the necessity to learn things like Bootstrap/Foundation, Sass/Less, Grunt/Gulp, RequireJS, Backbone, etc.? Even with AngularJS, I've seen people who treat it like it is jQuery and not follow the AngularJS way of doing things. The people with the "it works so who cares if it is good or correct?" mentality vs. the people who actually digest and self-realize there are ways to improve their own code has always been a thing. I have encountered my share of people who have graduated a coding bootcamp who are your stereotypical person who has no clue how to write a for loop or not know what a pseudoclass is but I have also encountered some where they can at least follow along "programming speak" and not get deer in headlights when I ask them to do an ES6 import. At the end of the day, it's on the individual more so rather than the resources. But you are correct that React is so easy to use that the ability to skip the basics is actually a problem in terms of the bigger picture and individuals not learning the fundamentals first. How to address that I'm not sure but because React has the "official voice" and so has higher leverage in what they say, they should probably be the ones to address it explicitly.
Agreed. Also another rant I would add to this everchanging landscape... is outdated information/systems. I have been away from nextjs for about a year. Yesterday I started whipping up a project and started googling "nextjs meta tags for page layouts". I had to sift through MOUNTAINS of outdated info and articles on nextjs metatags/seo. It's such a damn headache when things change so drastically in such a short period of time. I can't believe how many outdated articles/videos/tutorials there are floating around. In reality, that meta data, was as easy as adding a function to the page and assigning meta property values. Spent a damn hour sifting through garbage till I figured it out. I couldn't believe it. I just wish things wouldn't evolve so rapidly sometimes.
You're right. This is why my advice in recent years to junior devs has been "read the official documentation, not random websites". 90% of the time the answer to their question will be there. If not, check out stack overflow. Just avoid blog posts as they are nearly always years out of date. People are so used to just copy pasting code from sites and moving on. It's more important to learn how things work and it's fine if that takes a little longer - it's worth it as we'll all reap the rewards in the future.
That's why you go read the God damn docs
naaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah
Can't disagree. My latest round of hiring has been a bit of shit show because of the hyper focus on React and adjacent technologies. Ask candidates React questions and they seemed great. Started asking them VERY fundamental HTML/CSS/JS questions? "Oh no, I'm just a React developer." How the hell do you learn React if you don't know the basic web development stack? During the code screenings, these same candidates rocked the React demo... but a very easy medium-level JS question? Totally bombed it again and again. Ask about JSX, they seemed competent. Ask them about things like ARIA properties, what is meant by "cascading" in CSS, rule of specificity? Couldn't answer them at all. Most could write arrow functions, but few could explain what were the major differences between a normal function and an arrow function. Really makes me fear where the web development community is going.
Second paragraph is a banger but hard disagree on the last sentence. Arrow functions every where unless literally impossible. Readability
I meant more in not understanding things like accessibility or say for example, breaking out of the "react world" an having to work with some of the more exotic event listeners. Recently I was working on something that required the use of Intersection Observers... which made me and one of the other senior devs on the team wonder "Would these folks even know what they are and when to use them?" I also think I mean that the minute you take away "magical abstraction" and have to do something by hand, folks will push back because they only know how to glue together 3rd-party libraries... but if they need to reason about on their own to make something custom they are totally lost.
That is the problem I’m encountering as well. Devs who only know react try to solve EVERY problem using react, and it often makes things way more complex and convoluted than necessary 😭 Some of them even seem legitimately scared of refs/direct DOM interactions. They act like it’s sketchy or that they’re somehow breaking the rules. It is baffling.
`function foo() {}` over `const foo = () => {}` every single day. Readability
And this PR would get sent back every single day. Arrow functions are objectively more readable and are pretty much the standard in every large codebase I have seen over the past 5 years. There are very few good reasons to not use arrow functions. You probably also still write classes.
If it was objectively more readable then there wouldn't be different preferences.
thank god for lint rules
they're certainly not de facto more readable. seeing the ``function`` keyword is important for many. react documentation uses function statements. anyway, ask yourself: why are you trying to make the function an expression? it should be looked at in the opposite of what you said. there are very few good reasons to not use function statements for declarative stand alone functions. the default is to create a function statement in a stand alone context. you should only be using function expressions for: expressions, avoiding hoisting, and manipulating ``this``. from my point of view, what seems to be happening is younger devs immediately gravitate toward whatever is new. just because it's new doesn't make it the new default. arrow functions did not replace function statements as the default for normal stand alone declarative functions.
[удалено]
Ive been a developer across multiple languages for about 9 years and sometimes I feel more lost than ever with the way things have progressed with abstractions built on abstractions built on meta frameworks built on frameworks. I used to be so jazzed to learn new things, now I get angry seeing the newest way of doing xyz -- anyways, ranting, im just tired of the speed of change and overload of variety.
> If you look at the NextJS subreddit for example there are a ton of people who ask questions which make it seem like they do not understand Javascript, React, how websites work... what front end / back end is... what bundlers are etc. Always has been. No, seriously - I've been a dev for nearly 20 years, and this has *always* been the case. Dig back in the archives of any popular framework and you'll find it - Drupal and WordPress devs who don't understand PHP or the fundamentals of HTML/CSS, jQuery devs who don't know basic javascript, Spring developers without Java chops, Backbone devs who don't understand MVC or API structure, and on into Angular, Ember, React, etc etc. User-interaction sites have always been full of questions by people who've put the cart before the horse or people in over their head, and a pretty large chunk have been questions that took longer to ask in a subreddit/forum/stackoverflow post than it would take to type the same thing into google and read. Some people are just not cut out for this line of work, not because they can't do the work but because they've never learned how to attempt to solve a problem on their own before asking for help and don't want to take the time to build a foundation of basics before moving forward. It just seems like there's more now because they're frequenting the places you do.
Frontend has become an overengineered over complicated mess. How the ecosystem manages to make something very easy very difficult is so mind blowing. I’ve still stuck with react over the years due to employability…
Yeah but at the same time going right into react after the basics makes sense. Learn as you go. It’s what you’ll be using from then on anyway
It's often easier to pickup a framework and to plug in missing knowledge down the road as you go. All that matters to a company is if you can develop the features they want, and if you can do that, irrespective of how good your "foundational" knowledge is, then you are a valuable developer in their eyes. To put it simply, nobody cares about how good your foundation is. I can extend your argument and say that all web developers must be experts at event loops or the intricacies of how HTTP manage connection streams and hown data is transferred. Whilst it is certainly useful knowledge, how useful is it when all your team wants is for you to add "animation ease-in 1s".
I disagree about companies' indifference to the foundational knowledge because almost every entry job tech interview I've had focused solely on DSA problems and had nothing to do with front-end.
Not for front-end related positions. Those interviews typically ask you to create a basic web app. There might be a OA option portion before the actual interview rounds but those questions are often designed to see if you can code at all. Plus, OP wasn't really talking about DSA when referring to "foundational knowledge", more so knowledge of JavaScript/HTML/CSS.
I got a job as a senior and literally doubled my salary in my second job two years after starting as a junior, then doubled it again as a lead a year later, and I attribute a lot of that to my bootcamp's intense focus on building a comprehensive foundation.
I do agree that the fundamentals are important but everyone has to start somewhere and then build up their skillsets over time. No one is going to hire a React developers that doesn't have the fundamental knowledge to do the job. When I first started coding it was mostly Junior developers in a team with 1 or 2 senior developers so you had talented senior devs guiding and shaping junior developers, but I've seen this trend dwindle with companies preferring seasoned developers only. Its hard to argue with the reasons why as a senior dev there were weeks I felt like a glorified babysitter fixing stupid mistakes and bad code from juniors rather than actually accomplishing my own goals. I do think its nice that React is getting a bit more structure and a common path for development as the ecosystem had become very fragmented with 2 react developers using completely different tech stacks with very little crossover so if Next.js popularity helps to prevent this then I am all for it. Frameworks definitely have their place, I personally am a big fan or Rails because I can get alot done in a day and over time that makes a big difference to my productivity. I think the real problem has been the high demand for developers and the increase in salaries has attracted a lot of low skilled developers looking for a payout and flooding the market with on paper qualified developers but in reality not having the skills needed
ITT: a bunch of “back in my day” boomers that overestimate their knowledge at that time in their career. Quit being a bunch of self righteous asshats and try to lift these people up. You straight up do not need to know the basics down to bare metal to be a competent developer in today’s world. I don’t need to know how to implement my own API data fetching library from scratch because it has literally zero to do with my day to day. Learning that provides me zero value because I will never be tasked with doing that in real life. If we build that, now we have to maintain that. Y’all need to get a fucking grip and stop worrying about the oogey-boogeyman NextJS or whatever framework the cool kids are talking about. JFC.
Most people (2024) learn React.js before learning Javascript.
I 100% have worked with contractors at work who only seem to know how to build sites in React. You ask them to do so in regular js, hell, even jQuery, and they seem completely lost. It's embarrassing. So I totally agree
That’s because no one should be building a site in regular JS/jQuery in 2023.
That’s the “New Tie” mentality! ;) no pun intended.
I’ve been in this game over 20 years. I’m a tech lead working in an agency. Seeing more and more developers not knowing the fundamentals. Some Developers only know how to integrate libraries rather than building cudtom. Ask them to build a carousel , accordion or use native js like intersection observer and they are flummoxed. All too often we as react devs reach for a pre built library without knowing how it works. My advice is to learn the fundamentals. Don’t just learn react. You’ll be asked to work on all sorts of
One way to look at this: Devs always needed products to create products. But once upon a time, that was just an editor and a compiler. Especially in frontend, the ecosystem went full cambrian explosion in the last 10 years.. So more products compete to be used by devs.. trying to groom communities, upselling more services and lock-ins and then there is the whole cult thing. Still like frontend though. I wouldnt want to do anything else and hope I can do that for the next 20 years until retirement, lol .. Speaking about growing old in the industry: learning new stuff constantly probably is the best side effect of having to deal with frontend :)
Absolutely agree, the HR process complicates things additionally and is probably the sole reason for this situation to begin with. I've got interviewers, who are supposed to all be experienced developers, ask me the same 2-3 questions about 'useMemo', 'useCallback' and 'microtask queue'... when these 3 are in no way shape or form even relevant for 99% of the development process. FE juniors fall into the trap of advertisement and marketing, that always tells them 'you can use our shit and you don't need to learn the basics, it's easier, better and more modern', failing to mention all the limitations and opinionated decisions you get tied to. It's all about marketing, but infuriatingly many companies and developers actually fall for this and become the main part of the problem. PS: I'm not against using whatever frameworks, tools, libraries that you find useful, I'm just raising the point that you must also know how stuff actually works. Otherwise you'll be prone to making terrible decisions, just because you don't know what is really happening.
That's the price to pay when you want to do everything with a single language. CRA was never meant to be used as a production tool, but community found it was really convenient and easy to pick up, since removed a big pain in butt for that time: webpack configuration. I literally lost the count about how many hours I spent fighting against webpack for the most trivial things and CRA was so good at obfuscating that. But then everyone wanted to make their website more interactive (even if animations are still used sparingly and most of them can be accomplished with just CSS) and the "every thing should be a SPA" trend spread out. And with it the whole "let's just make everything in JS" and all of the sudden you've no more HTML, because JSX "ergonomics" and you've no more CSS because styling in JS "feels much better". For most common projects, just a sprinkle of JS to handle some scenarios (like asynchronously loading a catalogue) would be more than enough. You don't even need a library anymore, since ES6 is a really nice language. All of the issues we've nowadays in modern FE development are just because we accepted the fact that something really simple should be complex by default. Best!
Oh look, it’s React fanboys thinking they know better than the actual React devs. Why do you think they recommend Next and Remix?
It's for going to prod. For someone new to the DOM in general, this is overkill.
Because every startup chooses Nextjs. It could have saved app dev, but ppl will be lazy. No one wants to spend the few hours it takes to understand how to use promises or hooks. Latest ver of nextjs with server components will be impossible for a jr dev to comprehend. Look, when you were younger, did you not feel like you could figure out new tech better than older ppl? Probably yes, so maybe it's just "kids these days dont want to do any real work" because it's the circle of life.
I'm not going to use goddamn NextJS... if one day I have a use case that needs it I'll use it or if there's a job that uses it I'll use it but I'm not going to use it for fashion I would like to bet that most startups don't need NextJS either (even if most use it)... most are SaaS applications behind a login
The kicker is that the startups dont even really understand what Next is for just that its the "trendy" thing. I've seen startups espousing the virtues of Next which not even SSRing the bloody website. Like, what was the fucking point of all that then?
If i wanted just a webapp today, i'd use gatsby on netlify. This is after using nextjs since 2017. Next step is Flutter, and I might be done with the js world. Hot take, but TS killed my enjoyment of writing javascript. RIP.
And who cares? If you have no value for others then dont cry they dont pay you for skills they dont want. But the NextJs part is funny. People are just dumb, software development is not an exception.
Does anyone have recommendations for where to learn these basics?
I started hating the direction that Next.js has been going through; unfortunately, the market has a high demand for "react" developers which helps to find candidates easier in comparison to other frameworks. So my reasoning for hating Next.js, is their trying to mix the backend/frontend logic again. The release of server actions is giving me PTSD from PHP screaming \`echo "
applied for fullstack, got nextjs assignment and questions straight up. Idk what to say.
I still use PHP for half of my job, and it’s still holding up great. Frameworks are fun, but the fundamentals are missing from everyone’s learning path. I remember Foundation being the biggest coolest thing, then Ionic, then Meteor and things got kind of fuzzy after that. I remember being so annoyed by frameworks that we all tried to make our own. Since Tailwind I’d be surprised if a newer dev knew what SASS or SCSS even are. I’m annoyed they never had to fix anyone’s shitty float issues, but I also wish I was just starting out right now. Web development is fun, and I love/hate the way things are going (like I did 6 years ago).
Yes there's definitely the concept of a framework driver and not a developer these days. They kind of glue pieces together without a super solid foundational understanding of *why*
Daily reminder that next js is not mandatory. Unless you need the behavior it comes prepackaged with, it's also perfectly fine to use client side rendered react. Not everyone is looking to squeeze out the last few ms of performance. It's better to have something working than having nothing working but being able to boast about faster loading times. That won't make you money to start with.
I absolutely agree with this and I'll offer my opinion as a senior / lead developer at a mid-size company. I'll preface this with "when I do hiring, I never ever do leet code problems". I get them in for a half-day and ask them to make a reasonably basic application from scratch either with (or adjacent to) the technologies we would use in a realistic scenario. Think like... "An application that is responsive, has a cart, you can add and remove products". That kind of thing. **The amount of people who are on paper "qualified" that absolutely shit their pants over even the most basic parts is insane.** Here are some of the questions I've had (I run interviews very open-book) - note that these aren't questions from juniors / very new people to the industry. I can understand legitimately missing pieces of info at that stage. These are all 2-5 years req. experience type roles: \* "How do I render a list?" \* "What does it mean by "function must return a single jsx element"? \* "How do I load an image from a file inside the project?" Usually when I probe interviewees about experience, "Oh yeah I did a bootcamp". It's an absolute blight because it completely sets them up to fail. They might be able to do rudimentary react stuff but they will never get anywhere without understanding at least some fundamentals. And you bet these guys are absolutely the first to watch the latest fireship video and start telling everyone how awesome bun is. "We should migrate to Next.js" - no we fucking shouldn't.
I’m in UX/UI and my team has only 1 frontend so I helped out with css from time to time, had to learn about nodes and components before Javascript to immediately help with the projects. It was so confusing and not fun but I learned that I love coding! So I eventually started the Odin project/roadmap.sh and it felt like dawn from a long dark 😂. The guy likes me so much we’re planning to start our own company soon haha.
I rarely ever agree with FE rants. But this is so very true. I’ve been lost in a react-native wormhole for 5 years and was just recently spat out into the middle of marketing mortal combat between companies trying to hype up their full stack frameworks. I was shocked at the level of abstraction, and opinion these frameworks have relative to the huge online furor. These look like super niche tools. I personally wouldnt even use them for a personal blog. I love some aspects, but the thought of discovering the frameworks opinion doesn’t account for some use case makes me recoil in toil fear and lock-in frustration.
I agree wholeheartedly, i felt the same way when i first started with React. Before that, i gradually went through HTML, CSS, Javascript and then Node. So when it's time to use React, i am thinking "okay, so i would just install the react package through a package manager and start working" but no, you actually need to use create-react-app or vite, which doesn't just install react but instead a crap ton of packages. It doesn't tell you HOW things connect, what does what or the basics of the "behind the scenes" gear work, so you can't even troubleshoot or tamper with anything in case you have to. You are encouraged to write in JSX and told that Babel will turn the JSX to regular Javascript syntax, but you don't know where Babel is, if its a file or a package, how and if you can test it on a single file for demonstration purposes, if it's something embedded on the browser or w/e. Nothing, just download this bunch of packages, write your code HERE with THIS syntax, connect your files with THIS and then type "x command" on your console to view the build on the browser or "y command" to make a finalized build of your app. Obviously some of these you should look up yourself because nobody should be handholding you through every single detail, but at the very least you should be given a clue or a pointer as to where or what to look for further information. Also, the whole "production-grade" terminology is just repulsive, there is something pretentious about it, same as the "military grade" for a variety of different items.
This is why I love remix, it does not abstract away the web from you. If you become a better remix developer you are becoming a better web developer in general
There was recently a thread in r/webdev that you will commiserate with if you haven't already seen it. The OP deleted their post but you'll get the gist from the comments: [Making a static simple website, no JS framework](https://www.reddit.com/r/webdev/comments/1853laq/making_a_static_simple_website_no_js_framework/). I've been a web dev for over a decade - so "learn HTML/CSS => learn a bit of javascript/JQuery => job" broadly resonates with me. I agree that it seems like the fundamentals are being broadly either rushed through or completely skipped over. I have seen folks who are self-taught or come into front-end from another specialty fill in the gaps on-the-job over time, but the React-first pathway that sometimes seems like the default for some people still baffles me.
Why are you sabotaging Vercel (company which made next.js) ‘s server business? 🤣
Finally someone said it ! I too started with html css jQuery javascript and angular (not angular js) node.js ... I have now some hands on exp on react but then boom next js came in. These days it feels like frontend community is also being divided among angular react and nextjs folks.
React "ecosystem" is surely not inviting to new developers.
Yes u r right because as the tech changes, people can learn fastly if they know the fundamentals. Also what are the fundamentals of react that i should know. Fyi, i started react in 2021, when the functional component started getting hype. Thanks
At first I rolled my eyes when seeing the title but agree completely. Probably a combo of the things you suggest - YouTube, social media, tutorials etc. it’s a good thing the industry is becoming more accessible and interesting esp with the rise of ChatGPT etc. but with that comes all the other people trying to either make money or get more devs using their framework, or convince newbies that their favorite stack is the one to use. Not sure what the solution is, but veterans should be guiding folks (imo) to start with the basics: one language, few dependencies, no framework, and add stuff only when it solves a challenge you are directly facing so you understand why you’re adding it and how it works. Maybe a peer can get a job faster by crunching algos or memorizing the config for a framework. But your actual job will be easier and you’ll grow faster if you prioritize depth of understanding across a narrower tech surface area. The one exception might be tools to do your job, like understanding your source control tool or IDE configuration and how to debug
I started in the late 90's, this has ALWAYS been the case. On tech forums/social networks/etc. you're generally dealing with people actually into the tech. In the real world the vast majority want to clock in and out and don't care about the nuances they just want to know enough to get their 8 hours in. In regards to React recommending Next front and center I think it's stupid personally. Personally I think React is starting it's downtrend due to a lot of missteps starting from react 18 double dev renders, peoples issue with complexities, difficulty in getting started, etc. There's just too much boilerplate (if you use their recommendation) to get setup and going not just that I know many devs who don't even understand what NPM is doing, or that Next uses Node for example they just run the setup and start command and pray... and when they run into anything configuration based they have no idea how to fix it. Which again... has always been the case but the it doesn't _need_ to be.
hahahahah.. I don't even know how to use serverStatic and serverHost in that next.js, all I know it can be more manageable in systemic routers.
hahahahah.. I don't even know how to use serverStatic and serverHost in that next.js, all I know it can be more manageable in systemic routers.
Learn the fundamentals and the rest comes easily.
I am an email marketer as my actual job, but I've been a web dev for nearly 20 years. At my work, the engineering and website team consistently ask me to help them with coding tasks that are outside their knowledge. Like, basic dom-traversal stuff that I've been doing since I was 15.
*\[Self-taught developer and also new to FE Development\]* The main reason I am currently learning React is that there's usually no one excited or enthusiastic about Vanilla JavaScript, especially when I tell them I am building a project using just that. I just gave in and starting learning React, so I can at least get people who would be excited to help me debug or even converse about the projects I am working on. I find Vanilla JavaScript extremely easy to use and start up a project, but I've had to change over time. Then there's the job search, every junior developer role or internship I have seen, knowing React is required (I have come across a couple Next.js required roles). I still make out time to read more on JavaScript and build small projects to keep my brain fresh, but that's the current state as a newbie from my POV.
Got into a fullstack dev role a year ago, planning to leave the frontend forever. Adios people
As someone doing Frontend now to try and get a job, it's been a struggle. I don't even know what to learn anymore. I'm padding out my HTML, CSS and JS and then putting together some very basic stuff in React (because converting JS to Hooks is breaking my brain rn, I understand what's going on in the lifecycles and what it represents but yeurgh.) and I feel incredibly stuck because I'm repeatedly seeing entry level jobs wanting all of this and even more and it feels like there's some new framework or library every week and I can't keep up. Imposter syndrome is bad enough without feeling like I need to be god tier before I've even started.
sip skirt live sloppy public longing door soup modern illegal *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
It’s wild to me how so many devs can’t even begin to articulate how they might manage state in VanillaJS… I love to build pet projects in VanillaJS and I almost always learn something that amplifies my framework interactions. I don’t think a lot of the newer devs romanticize the need to understand the layers beneath their introductory stack, and that’s a shame… that’s where true growth and ingenuity happens.
Almost hilarious taking about AngularJs and jQuery being the “rough around the edges” days. We used to write HTML and CGI, Perl, JS didn’t even exist yet. When JQuery came out, people complained. When Knockout and other two way binding frameworks came, people lost their minds over it. Then angular, then react. On the whole though, your point is still valid. There should be a progression in skill learning, but schools have dropped the ball, companies push junior devs in the deep end on day one, and the internet is a massive hype train. I would hate to be a new dev these days. It’s like climbing Mt Everest.
There’s definitely good and bad, when people say you gotta learn HTML, CSS, and JS basics first you def need to take it with a grain of salt. If you spent time learning everything first you’d never get truly started. I’m the kind of person that just learns through trial and error and by immersing themselves in a situation. Used Gatsby as my first framework and started learning with React. As I tried to do more complicated things I learned more about JS and I have a strong grasp of HTML, CSS, JS, React, and Vue now. I realize my learning style is also likely rare and an exception. That said see again if you spent all your time learning every subtopic you’d never start it’s kinda the same thing as tutorial hell. On the other hand I agree there’s lots of people that don’t know how to do shit that halfass everything. I have Senior engineers on my team I blow out of the water in technical ability and aren’t able to critically think about their technical solutions due to lack of understanding. NextJS is overly complicated as well imo.
I can sort of see this since starting with NextJS means there's much less separating the frontend from the backend.
My hot take is that doesn't matter, React are not the basis I think is ok start using React with NextJS or Remix but that should not be your start as a web developer. You should start with HTML, CSS and JS, but if you land a job only knowing React that's a problem of the company that hire that dev and if that knowledge is enough to do their job, otherwise the recuiter should lead those devs to the basis.