Ask HN: What are your unpopular opinions about programming?

It's a lot easier than you all make it out to be [0].

I'm not a 'programmer' like you all are, at best I can hack together code to get things done. I use git maybe once a year. I'm a biotech person that likes to hang out because y'all are mostly smart and the community is great here.

But man alive, this is not that difficult. Yes, it's hard to wrap your head around some nested dependancies. But it's a lot easier than any chain of protein/gene/neuron interactions. This stuff makes sense and you can edit it. My field can't really do that most of the time and it really doesn't make sense for decades (at best).

Like, I'm trying to follow along here and am mostly lost. But the few times I do know something about the code y'all are talking about, it's made out to be a lot more complicated than it needs to be.

I mean, yeah, keep that up though. Makes your bosses pay you more and lord knows those suits should be doing that and not spending the cash on rockets and shitty pick-ups.

But for real, y'all are making this out to be a lot harder than it is.

[0] this is supposed to an unpopular opinion, right?

It's not even anything fancy, just even simple things like calendars, date pickers, meeting schedulers, etc. Sure, you can do it all serverside, but we're talking about JS here, not any external database.

JS itself can't "keep" an original timezone in a Date() object. e.g.:

`new Date("2024-04-01T00:00:00Z").toString() `

Becomes your browser's time zone, even though the input was in Zulu/UTC. Also note that a time offset (Z or +08:00) is not the same as an IANA time zone string, and that's a one-way conversion. If you go from something like Los_Angeles to -7:00, you have no way to tell if the -7:00 is due to a daylight savings time or another locale that doesn't observe American DST. And JS doesn't store either piece of info.

If you have multiple users across different time zones trying to plan an event together, JS's date handling is super footgunny (is that a word?) and it's very easy for devs to make errors when converting datetimes back and forth from the server/DB to the app UI.

And because JS is so powerful today, there are many things that should be doable entirely clientside, but aren't easy right now. For example, relative time: wanting to make a scheduler that can search for +/- 7 days from a certain selected datetime. What is a "day"... is it 24 hours * 7? What do you do about daylight savings time boundaries? Or if you go from Feb 1 to Mar 1, is that "one month" or "28 days"?

These may seem like edge cases to you, but when it comes to datetime... really it's all edge cases :( You run into half-hour timezones, daylight savings time (which is a set of rules that vary over time even within the same country, not just a static offset per timezone and date range), cross-locale formatting, etc.

A lot of this is very doable with existing libs like Luxon, or datefns for simpler use cases, but they are fundamentally hacking around the weaknesses of the built-in Date() object with their own data structures and abstractions.

For me as a frontend dev working on ecommerce sites and dashboards, I've had to correct more datetime bugs from other JS devs (including some with decades of experience) than any other issue, including React state management. The tricky part is that a lot of the weaknesses are non-obvious, but it really is buggy and weak as heck, especially compared to many serverside languages. It's based on a very early implementation of Java's dates, which has since gotten a lot better, but JS's Date was still frozen in time.

Thankfully, most if not all of these issues will be solved with the Temporal API once it's stable... it's been like 10+ years under development, since the Moment days. Can't wait!

To solve for that you can serve WebSockets on the same port as HTTP. Most web server application's don't know how to configure that, but I know it can be done because I doing it right now in my own applications.

To some degree, yes, and I'd hope that other skilled professionals would take a similar approach.

Like if I wanted to add EV charging to my home, I'd hope the electrician would take the time to explain the different levels of charging, the breaker and wire upgrades needled, etc., find a suitable installation site around the house, etc., not just start hooking things up willy-nilly. Or that a HVAC person might talk about the pros and cons of heat pumps, or a doctor might discuss different treatment options, etc.

It's different from, say, being a line worker in a factory assembling the same part 10000x a day, or a fast food worker.

Sure, at some level we're all just "solving problems", but I'm arguing that a good dev thinks about the problem and possible solutions as a whole, and utilizes that agency to make the final output better, instead of just coding Jira tickets to spec and never saying a peep.

But that's my own bias as a predominantly frontend person working for small or medium sized companies where specialization isn't as extreme. Maybe at bigger companies and teams they already have many layers of UX/UI/design/management and don't need (or want or appreciate) a dev speaking up about any of those things. In my experience it's never that black-and-white and a lot of tickets and designs are ambiguous and require both professional judgment and some empathy to implement well.

Maybe that's why I prefer the generalities and of the frontend vs, say, hyper-optimizing a very specific database call.

Heh, it's funny, my partner is a vet tech and I keep thinking how interesting it would be to build a CRM for them and their patients (there is already an industry for that and some of the apps are actually decent).