While we're on the topic of styling, why is the default font size so small? The comment size is 12px. In my view, that's like sub/superscript or caption size, not body copy.
I regularly zoom to 150% on HN or use a bookmark that sets styles via JS so I don't have to strain while reading. Am I the only one? And no, I don't need glasses!
> people WFH 3 or 4 days a week with one day of the week being designated as a "meeting day" where everyone is in the office.
I sort of had this setup before covid: the company I work for does consulting and my coworkers and I will often be at client's offices. When we write our contracts we make sure to always designate Friday as the day where all employees come back to the 'home base' for meetings, catch-ups, socializing, etc. It works quite well, and we'd always look forward to Friday's because of it.
If I could continue to WFH 3-4 days a week and then go into the office on Thursday/Friday, that would be great.
I'd love to choose a side. Sadly, I'm living in Copenhagen after living in the U.S. for many years and there's no fried chicken war and barely any fried chicken. I recently found one joint where you can get a decent fried chicken sandwich, though that's about as far as it goes.
It's such a shame because the chicken you can buy here is, to my taste, of much higher quality compared to that in the U.S. The tenderness is incredible, and it's so moist it's almost impossible to overcook. I'm not really sure why it hasn't caught on here. Perhaps it's simply a matter of preference/taste.
Your last point is a cause of some apprehension for me. In the team I'm currently working with one of my coworkers calls himself a React Developer, and my experience has been that anytime an issue arises that may not be specific to React, this person's ability to problem solve significantly diminishes.
I've seen it in a couple of other individuals as well, and I feel it's becoming more widespread, though I hope I'm wrong. In these instances, I see the framework existing both in the code as well as the mind, and operating outside of it is often a leap too far.
> and my experience has been that anytime an issue arises that may not be specific to React, this person's ability to problem solve significantly diminishes.
this has been my experience too, I'm a full stack engineer playing a devops role right now on a greenfield govt project. Getting our CI/CD pipeline going within our environment constraints with react has been a pain in the ass. Every time something goes wrong the front end dev just kinda throws his hands up and basically tells me its my problem. I ended up having to go through all the issues opened on github to find solutions and implement them myself. I'm no javascript expert but to me the solutions seem to be super hacky when I've found other frameworks out there that handle these things out the box or more gracefully.
I was on a project supporting legacy code for a long time before this, and was quite looking forward to working with newer js frameworks but this left a sour taste in my mouth. And I already had a bad impression of react prior. I might look into pushing for some of the alternate frameworks out there.
There's a slew of workarounds offered in that github issue, most people (including another team in my org) opted to just rebuild the app every time a docker container is created which kind of defeats one of the major pros of using docker IMO.
> So the issue I'm referring to is this, which has been open since 2017
I probably don't appreciate the complexity of the issue, but I would say environment variables are not React's concern; it’s up to you how to architect your code. If you want runtime environment variables, then either add them to the html that React will render into, so that the javascript code can read these variables in before rendering, or have an api endpoint that your app will query before or during rendering and will get all the relevant config information from it.
> but I think next.js and nuxt.js does
Probably because they server-side-render. And even if your app renders on the client side; even if you don't use next, nuxt or whatever, there is no-one stopping you from dynamically serving the html skeleton with the relevant variables in it.
But then, it all probably has been mentioned in that issue. I wonder why it wouldn't be a good solution.
> but I would say environment variables are not React's concern; it’s up to you how to architect your code
I don't consider it part of the "code" but part of configuring the application based on the environment you're deploying it on(Precisely why the FE dev basically said its not his problem). The fact that a lot of people are suggesting you just build the app every time you deploy a docker container is really concerning to me.
> I wonder why it wouldn't be a good solution.
it just feels dirty. it's the fact that I have to add these into the code that it feels like a hacky solution for a production app. using a shell script to read read the OS environment variables to create an ENV file then convert that ENV file to a javascript file that is then read, it seems like many things can potentially go wrong.
Ideally they would just deal with this within the dotnev library
Dotenv runs on the server. If a part of your application also runs on the server (such as with Next, Nuxt, etc.), and your responses are generated dynamically, then it is trivial to use the dotenv. If, however, the runtime of your application is confined entirely to the browser, and what you are serving to the browser is only static assets, such as with create-react-app, then, if you still want your environment variables to be defined at runtime rather than at build time, you need to design a bridge between your server and your client specifically for injecting the environment variables.
Here, for example, is an article describing such an injection at the nginx level: https://medium.com/@jans.tuomi/how-to-use-environment-variab.... Or you can serve index.html using a full-fledged dynamic server, such as Node, and inject environment variables there (and probably cache the response for good measure as well, not to overstrain Node). This really is not something that is React’s responsibility — although it may very well be the responsibility of the frontend developer to set this all up.
yep i know how it works after looking into it since I didn't know anything about react before, just makes me not want to use react or vue for any enterprise level software.
All those solutions you mentioned I've considered and are mentioned in the github issue. I just think its way too much work and overly complicated for what is basically a prototype. Which is why I opted for the simple hacky solution.
> This really is not something that is React’s responsibility
This is why I'm already pushing for our team to move off react I don't think its the right fit for us. We also don't like JSX
Personally, I'm super wary of any ____ developer. It's a fixed (vs growth) mindset that tells me they are specialists. I think specialists are best to be consulted by generalists, but not trusted with larger decisions outside their scope.
This is usually a smell that the person is competent at what they do, but doesn't know what's going on under the hood. Funny enough, I'd rather work with someone who doesn't know the specific technology, but knows what the language was built on top of, because they'll have a better intuition for how it actually works and be able to learn it relatively quickly.
I'd rather work with someone like that, too. All is well and good when one can crank out React components, but if that same person doesn't know how to find, for example, the tag name of a element from an event handler, a little red flag goes up for me, and as you said, probably doesn't know a great deal about what's going on under the hood.
I agree. Though this person can be a bit touchy when constructive criticism is aimed at them, this would most likely be beneficial for them, and also the team, in the medium/long run.
