I develop a HN/Reddit clone [0] that has high density settings. The home page is fairly high density by default. But if you go into the settings [1], then you can really crank up the home page UI density by setting posts per page to 50 and post spacing to 2. The density is more apparent on desktop since the lines don't wrap.
When I read this, the first thing that came to mind was "until you have to work with time zones". I generally enjoy working in JS, but it's such a pain point for me that I can't help but not think about it whenever I see a datetime.
It doesn't get as much mindshare as the problems with typing and frameworks and fashion trends and such, but my god, I've never seen a major, popular language with such poor support for basic time zone manipulation and storage. It is really really bad and won't be fixed until the Temporal API is stable and widely available: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
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!
Not necessarily, that advice usually assumes that you either are the subject expert or that your job is scoped and therefore benefits from being able to rush a job to maximize compensation
If you can bill by the hour, you benefit from the customer figuring it out on the go, which will take longer, but also be better fitted (If you can make it work)
If your job fits in "I'll make your X twice as good" or "I'll implement this standard" bill by the project, so you don't get punished for being more efficient; if it fits in "we'll solve your software problems", bill by the hour and you'll be rich, because they won't run out of problems to throw at you
I feel like it depends highly upon the nature of the project.
I've worked with (and for) consultants and we typically billed by the project for things with well-defined scope, work, and outputs. (Maybe a small business website, or PBX system.) But we billed by the hour for things that were unfamiliar territory for us and forced us to learn as we go. Like migrating a bunch of data from an ancient proprietary database to Postgres.
Do you have any suggestions on deploying? I looked over the readme. I’m not understanding how to go from clone to cloud. Meetup sucks and I’m wondering if this might be a good replacement for local groups.
- get all the source code for the actual app (ie. the code from the comment castles repo)
- figure out all your environment variables (the ones I list in the README)
- now you can run the node app (you probably want to use pm2 if on Linux)
- then connect that running node app to the public internet (I use something random for the HTTP_PORT environment variable, like 3333, and then I Nginx reverse proxy that to port 80 on my domain name (I will try to get this Nginx code and post it here later))
- and then I run the let's encrypt certbot for https
I agree it's too tough to define. So I'm just basing this off of vibes. One of my closest friends is a really good C++ programmer, so that's where I'm coming from. I'm not a C++ programmer at all.
I think the C++ standard might be the biggest. Like, just the amount of compiler passes it does and what means when is kind of insane. I shouldn't even have seen that in my life, yet I did. I guess that's what friends are for :')
But the ecosystem of C++ seems quite small compared to others as C++ programmers want to build stuff themselves.
So it depends if you just look at the standard versus the ecosystem.
