181–190 of 232 posts
I guess I skipped this app before because on the screenshot it looks like it just has one panel. But after trying it out, it has "dual pane" mode, so I will give this a shoot.
Earlier quoted context omitted.
It's not possible to remove anything without potentially breaking backwards compatibility. Removing ANYTHING in Javascript would be a tremendously bad idea. If webpages from 30 years ago stopped working because 2025 developers favor aesthetics and disrespect legacy, I'd be pretty angry.
I do like the way Rust has language editions which let you work around this, at least partially. Mostly though I don't care if we break old stuff. It happened all the time when developing for the desktop. People just dealt with it. The ones most impacted are lazy enterprises and I have no sympathy for them. Clinging on to the past stifles innovation.
If you start telling people they have to install an obsolete web browser, and then an obsolete operating system, and then patch the drivers because all the hardware doesn't support it anymore, you have effectively gatekept information that was once available in the open web to the tech elite.
Yes, "tech" is redone from scratch every 6 months so 5 years ago is an eternity, but there are plenty of fields where 30 year old information is just as invaluable as something published today.
Nobody is maintaining webpages published in the 90's. Nobody is going to update them. They are just there, sitting on some university's server that barely gets any hits. The author probably died 12 years ago and nobody even remembers who is responsible for it or that it's running. And it's in everyone's best interest to keep it that way: online.
Earlier quoted context omitted.
How is that any better than React + ?
PHP is extremely simple to use. That makes it extremely simple to onboard new people and also to support. Complexity brings associated costs, sometimes bigger than the development itself.
Earlier quoted context omitted.
It's not possible to remove anything without potentially breaking backwards compatibility. Removing ANYTHING in Javascript would be a tremendously bad idea. If webpages from 30 years ago stopped working because 2025 developers favor aesthetics and disrespect legacy, I'd be pretty angry.
> It's not possible to remove anything without potentially breaking backwards compatibility https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
How does something like this even happens.
Anyway, if you "use" strict mode, but the browser doesn't support it, you're effectively not running in strict mode, so you can't actually assume the Javascript will execute differently.
Earlier quoted context omitted.
Do you have some examples of large and complex C# applications with really good performance? I’m hard pressed to think of any Microsoft software at all that I think feels really nice. Except for VSCode, which is of course built on Electron and not .NET. The only thing that comes to mind is Paint.NET, which doesn’t seem like all that big of an application. It’s very nicely done, but I think it’s only got like a single…
Isn't Visual Studio (not VSCode) written in .Net.
Earlier quoted context omitted.
PHP is extremely simple to use. That makes it extremely simple to onboard new people and also to support. Complexity brings associated costs, sometimes bigger than the development itself.
Last time I created a Laravel app it created dozens of default files and folders for me. How is that simpler than Go/Gin or Python/Fastapi? When does the extremely simple part come in?
Earlier quoted context omitted.
And COM/OLE/ActiveX components (whatever Microsoft fancied calling them that year) could have been used just as easily from Delphi. And you don't even need COM. You could do the same things today with RAD components in, say, Java. But it's just no longer a fad. Programmers nowadays don't think that dragging a component that makes phone calls and linking it to a button. Nowadays, they would just write "npm install tel…
The way COM model worked, is that an application (for example, microsoft word) would implement this COM interface (that they'd have to anyway, for various reasons such as interoperability), and it would become available as a component to be used in another application. It's a grandiose vision. It just didnt work out because of how complicated it is in practise to implement the COM interface(s), and not enough apps di…
Earlier quoted context omitted.
Isn't Visual Studio (not VSCode) written in .Net.
That's specifically an example of an application that I think is slow. It's slow to load and often slow to respond. The support for Git has to be amongst the slowest of any professional application in the world. But I'm pretty sure it has a deeply flawed architecture compared to VSCode.
Edit: I stand corrected, based on reply in a sibling comment most of the perception stems from how .NET Framework works. Understandable.
Earlier quoted context omitted.
.NET supports native AOT for a while now.
I don’t have a lot of experience with this, but that’s mainly because there’s no way to compile my company’s application with Native AOT. At least not without a significant amount of work. This is because there are many limitations in what can be compiled this way, and most C# applications and libraries were never built with such limitations in mind.
Earlier quoted context omitted.
Last time I created a Laravel app it created dozens of default files and folders for me. How is that simpler than Go/Gin or Python/Fastapi? When does the extremely simple part come in?
For one, PHP doesn't require bundlers to work, nor does it require compilers, transpilers, watchers or whatever. You just save your code in your editor of choice and that's it.
Also, you still run artisan to view your code after you save. Same thing with Python's FastAPI: I run FastAPI's server. I just save my code just like PHP.