Hacker Newsnew | past | comments | ask | show | jobs | submit | d357r0y3r's commentslogin

It really is just mostly this, and social media has tricked people into thinking otherwise.

I was looking at some photos of myself about 10 years ago. At the time, I had been hitting the gym hard, consistently, and intelligently. I had a huge bench press, squad, and deadlift, and was lifting 4-5 days a week, and managed every facet of my diet.

Now, I'm older, have kids, don't sleep as much, and definitely don't make it to the gym as much. I might lift twice a week - and don't try very hard or do progressive overload at all - and try to get in 3-4 days of cardio.

And I honestly don't look very different. Muscles are roughly the same size. In clothes, most people wouldn't be able to tell the difference.


Counter argument, muscle maintenance is a lot easier than muscle growth. Of course you don't look that different now, you have done enough work to significantly change your physique, but done plenty to maintain.

Muscle memory is a real thing.

Gaining it is hard and slow, but once you do it, you can easily maintain it with very low volume (1 time a week with very reduced volume/weights). And even if you don't train for years/decades, you still rapidly get it back once you start again.

That's why one of the best investments in people health should be weight training during the teenage years/20s. Getting muscles and strength is the easiest at that point of life, and you will reap the benefits for the rest of one's life.


Genetics play a factor, but you can still look pretty good, feel great if you consistently go to the gym, lift heavy weights and eat your calories.

You won't look like Arnold as there are genetic factors at play but people shouldn't be discouraged in thinking they won't be able to achieve a good body.

Another factor, that I think many men forget (I can't speak for women), is their testosterone levels. If you are following everything and have no results I recommend that you have your levels tested. Many men are suffering from Hypogonadism without realizing it. I had this issue for years and when I did my tests, I was at 7.6 nmol/L !

My doctor put me on HCG and it was like night and day.


You've lost your sense of perspective. You might lift twice a week and try to get in 3-4 days of cardio? You're in the top <1% people on this planet by fitness.

>social media has tricked people into thinking otherwise

I assume most fitness influencers on social media are on steroids.


The reason it's faster is largely because it doesn't have all those little quality of life features and extension ecosystem. It's easyish to make software perform well if it doesn't do all that much. If you take base vscode, no extensions, and just do raw text editing, it's hard for me to tell the difference between vscode, zed, or any other editor.

When vscode was released, Sublime was faster - and it stayed faster. But that wasn't enough to stop the rise of vscode.


You can tell by the colors, the icons, the font...most Claude Code apps from scratch will look roughly like this.


I've built significant applications using Monaco, including things that tie into custom LSPs.

They really just should have used Monaco. This will be a burden to maintain and won't be a core differentiator.


Codemirror nowadays has first-party LSP support: https://github.com/codemirror/lsp-client


What's the story with supporting CommonJS libraries? I've tried to update many projects to ESM multiple times over the years, and every time, I ended up backing out because it turned out that there was some important upstream library that was still CommonJS - or even if we fixed those issues, our downstream NPM consumers wouldn't be able to consume EJS. So then you have to go down this rabbit hole of dual compilation, which actually means using something other than tsc.


It's possible, but it can be weird and difficult: https://nodejs.org/docs/latest-v17.x/api/esm.html#esm_common...

Thankfully, actively-maintained CommonJS-only packages are quite rare by this point (in my experience).

> our downstream NPM consumers wouldn't be able to consume EJS

Node.js 20.17 and later supports loading ESM using `require()`: https://nodejs.org/api/modules.html#loading-ecmascript-modul...

The next version of Babel (currently in beta) is even going ESM-only.


It's almost like Python 2 to Python 3 upgrade. Took a decade but everyone is finally happy.


With "type": "module" there's very few reasons to do dual compilation unless you have very conservative downstreams that hate promises and async/await, and even then there's mitigations now (sync `require()` of async ESM).

It's been a while since I've had a trouble importing an upstream CommonJS library. Often it is easy enough in the rare cases where upstream is particularly old/gnarly you can vendorize an ESM build with rollup or esbuild.

That said, CommonJS is also now a strong maintenance signal for me and if a library doesn't have recent ESM builds I start to wonder if it is at all well maintained and not just a pile of tech debt to avoid. JSR has started becoming my first place to search for a library I need, ahead of NPM, because of JSR's focus (and scoring systems) on ESM first and good Typescript types.


I just couldn't figure out what this was in <60 seconds. Examples and use cases need to be a little more prominent in the docs.


You've gotten good at telling the machine what to do. He's gotten good at telling people what to do.

The latter turns out to be a much more effective way to build power and influence.


The point is he's not, as he can't prove.


>He's gotten good at telling people what to do.

Not in this case as it seems he didn't get the outcome he expected.


It is absolutely worth the cost and complexity. The cost and complexity of building a web application using some home grown vanilla JS system will end up being a horrible engineering decision most of the time.

There have been zero times in my career where I thought "hmm, maybe we shouldn't have build this thing in React and let's just go back to page scripts." If you're building landing pages and websites, then okay. But that's not most of what we're all hired to build these days.


That's way too dependent on context to say the cost is always worth the complexity.

On a team that is experienced in react, or a project that is heavily dependent on client side rendering react (or similar) make sense.

On a team that is more backend focused or a project that is CRUD heavy and generally rendering state that persists on the server, it could very well make sense to lean on server rendered HTML with small bits of JS scripts for interactivity.

We as an industry way over tilted on client-side rendering. If you're building Facebook or Figma or Discord, sure maybe CSR is a must. For most websites you don't need much CSR though, and if you're only using it for small bits of interactivity you may be better offer foregoing the complexity of a framework and taking responsibility for the full render pipeline.


Cline is pretty solid and doesn't require you to use a completely unsustainable VSCode fork.


I have heard Roo Code is a fork of Cline that is better. I have never used either so far.

https://github.com/RooVetGit/Roo-Code


I prefer Roo, but they're largely the same right now. They each have some features the other doesn't.


By the time I've fully documented and explained what I want to be done, and then review the result, usually finding that it's worse than what I would have written myself, I end up questioning my instinct to even reach for this tool.

I like it for general refactoring and day to day small tasks, but anything that's relatively domain-specific, I just can't seem to get anything that's worth using.


Like most AI tools, great for beginners, time-savers for intermediate users, and frequently a waste of time in domains where you're an expert.

I've used Cursor for shipping better frontend slop, and it's great. I skip a lot of trial and error, but not all of it.


,> and frequently a waste of time in domains where you're an expert.

I'm a domain expert and I disagree.

There's many scenarios where using LLMs pays off.

E.g. a long file or very long function are just that, and an LLM is faster at understanding it whole not being limited in how many things you can track in your mind at once (between 4 and 6). It's still gonna be faster at refactoring it and testing it than you will.


I agree that it's amazing as a learning tool. I think the "time to ramp" on a new technology or programming language has probably been cut in half or more.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: