You must log in or register to comment.
I started programming in 2015 and I’m very surprised that webapps have managed to get worse in that time period. We have 10 years of work on the V8, 10 years of React and Angular, 10 years of DX improvements and my current work is C# takes a minute to compile and Angular takes 4 minutes for a production build.
I know now we have TS and there’s a lot of safety that comes with it but somehow things are just slow, both building and on deployed websites. Websites should be snappy when everyone has a GPU that can go incredibly fast compared to 10 years ago and cores that are 2x faster and 4x as numerous.
Good write up. I agree with several points
And it pains me too that everything is damn electron. Can we please go back to writing stuff that doesn’t require that?
I don’t mind an old style interface. Hell, in many cases I’ll welcome it with open arms. Modern UI is not necessarily better. Both tech wise and also style wise.
There is https://tauri.app/ coming up to let Electron app developers debloat their offerings.
Eh, as funny as this is, I can’t agree that programming peaked with Java. In fact, much of this is just a rant about JavaScript, not about much else.
VSCode can easily do cross-file renames if you write Rust. Rust is kind of peak programming if you ask me, and it’s modern and still new. I don’t feel programming has peaked yet tbh.
You can do cross-file renames in … gasp!.. Typescript!
… Kind of.
It’s flakey af on large enough codebases.
Nothing anywhere near as reliable and robust as C# or Java for refactorings.
Eh rust still has issues in some domains, e.g., when cyclic data is appropriate. You can do it, but it’s annoying. To me, Haskell is really peak programming, but I know that’s opinionated and most won’t agree.
Vscode can do cross-file renames in pretty much any language. An LSP that doesn’t support this is not doing its job.
Eh rust still has issues in some domains, e.g., when cyclic data is appropriate
This might be but then again I’ve been writing Rust for several years and have yet to actually run into this problem. The borrow checker definitely places certain restrictions on what kind of stuff you can do (for good reasons!). Once you know how it works, your brain starts writing the code in advance to fit how the borrow checker likes it and it becomes second nature and a total non issue.
Of course this is part of the reason Rust has a bit of a learning curve, which is fair. But any good sophisticated tool meant for professionals requires proper training and knowledge.
Yeah it depends what you’re doing. I do a lot of circuit modeling where different subsystems need to talk to each other. The solutions are either Rcs (and a bunch of custom drop logic) or a parent struct holding all the others. Both are awkward. But in other programming domains I’ve found rust pleasant.
What might benefit you here is a proper GC. There are a few libraries to do this in Rust, though I don’t have any good recommendations since I haven’t needed this myself yet.
The audacity to be nostalgic for Eclipse!
Every time I read something like this it comes to mind that we’re more likely to remember the good bits of the past than the struggles. People use containers because the “works on my machine” problem was a constant pain.
You can still ship code into production quickly if you pair program and commit to trunk to bypass the code review process, and have a CI/CD pipeline set up to automatically build and publish the package.
And I’d much rather have a cloud env pull my code and automatically deploy something than manually transfer files over FTP.
Old man shouting at clouds…
The way the author described programming in 2025 did make me chuckle, and I do think he makes some excellent points in the process.
It’s 2025. We write JavaScript with types now. It runs not just in a browser, but on Linux. It has a dependency manager, and in true JavaScript style, there’s a central repository which anyone can push anything to. Nowadays it’s mostly used to inject Bitcoin miners or ransomware onto unsuspecting servers, but you might find a useful utility to pad a string if you need it.
In order to test our application, we build it regularly. On a modern computer, with approximately 16 cores, each running at 3 GHz, TypeScript only takes a few seconds to compile and run.
Hmm, partially. One real thing that I see now is cloud costs. All of the stuff we now have in our pipeline does inflate our costs quite a bit, which then puts pressure on the budget and that crunches everywhere.
I miss the days when it was simpler as well. Back before there were botnets with hundreds of thousands of compromised routers across several countries that could send tens of terabytes per second of data to your server for a sustained period of time. Back before there were thousands of bots crawling every IP and domain imaginable for exposed, abusable ports and wp-admin endpoints. Back before people started to compete in how many 9s of uptime they supported (before killing that all with LLMs anyway).
Sadly, we can’t go back to those times. Doing so with a production service would not end well.
The issue is not npm. Npm is a solution to a problem, even if it isn’t perfect.
The issue is we live in a different landscape.
Eclipse was great, having used it in the past, but its features are not exclusive to Eclipse. I can do the same inlining and extracting of code in vscode with code actions. The compile times weren’t seconds for me in the past, but they are for me now. Vite helps that even more (though that’s comparing JS to Java).
well there is some Rust building up under that JavaScript… maybe that can save us.
Rust isn’t built for the same purpose as JavaScript though. What do you mean?
