Hacker News Reader

> bad code and bad tools and bad frameworks are reigning supreme over real engineering. Why?

Why? The (ultimately unsuccessful) quest for the silver bullet. Nobody wants programming, they want programs - so anything that promises to deliver programs faster looks like a holy grail. Inevitably, though, the promise boils down to a pre-packaged implementation of an existing approach that does something relatively specific, with some options for customization. If you want to step outside that customization, you not only have the assumptions baked into the new "silver bullet", you also have to understand all the nuances of the layers upon layers of other approaches (and all of their assumptions), to the point where it would be faster to just shed all the layers and do it yourself (but you can't because noooo, you're a dinosaur, you don't understand anything, it's the future, it's the modern way of doing things).

Which is why we ought to be building webs with Assembly.

Seriously though, there is an equilibrium somewhere, and on top of that a lot of stuff that is more about business and work than programming.

I may be getting out of my depth here but, am I wrong to say that a good deal as to why webdev in Java is even a thing is because there were people around who knew Java to begin with? That a good deal of people learning PHP did it just because Wordpress is a thing? That react native for desktop is about people with expertise in react native being able to develop for desktop?

Workers want paychecks. Society wants products. Workers will learn to make products so they earn paychecks and if they can spend less time learning they will, obviously, do so.

It’s refreshing to see this as the top comment on a forum where we are often guilty of this mentality.

I notice that this mentality isn’t as common in circles of people with their nose to the grindstone building things.

Right now I have some game modding Discord servers in mind where everyone has crappy tools but is focused on building things regardless, and complaining about the state of things just feels trite, as if the entire ecosystem is responding “Ok, in Utopia things are better, but what are you building today?”

For some reason people confuse sour grapes with some sort of high brow eureka they need to dump onto the world.

> The browsers native language is HTML. HTML is a markup language and if you feed HTML to the browser it will very quickly render the page with what you give it. But no. Let's not do that. Let's instead feed the browser with JSON and then have the build in JavaScript engine translate that into a pre-formatted output which then gets translated into HTML before it's served to the user.

I agree with you. I agree with the author. I put my own idea into practice:

https://htmx.org

> Meanwhile, the shitty tech is winning. According to this author, bad code and bad tools and bad frameworks are reigning supreme over real engineering. Why?

The funny thing is, 20 years ago the same arguments were being made.

"Windows MFC is a nightmare to write against!"

"X11 is terrible, why are we using it?"

"Everything we write is built on so many abstractions developers don't know what they are doing."

"VB6 is dumbing down development"

"Developers writing in Java don't understand what is really going on."

"Java is too slow!"

OK the last one was true. UIs in Java were obscenely memory intensive relative to computers back when Java was first introduced.

But yeah, more things change, the more the complaints stay the same.

All of them are still true, except for the last one (for nearly all use cases).

Java got its slow reputation mainly because any early encounter with a Java applet would proudly display the Java logo and then cause your computer and disk to thrash for 30 seconds.

Then Java developers heard this, confused it for "Java executes slowly" and so they never fixed it, until Java applets just became obsolete.

Eclipse didn't help Java's reputation any.

"Amazing new IDE has just come out! Good luck running it!"

Also local Swing apps were memory hogs compared for the time. 20MB was a lot on a machine that had 256 or 512MB in total.

Internet complaining gets eyeballs. Look at this comment thread. Look at the position in the HN queue.

I'm not a fan of it. I understand the author's complaints and frustrations (I am also "chronologically-challenged"), but I have found that complaining doesn't really buy me much. I'll do a minor whine, from time to time (usually about the ageism in tech), but, for the most part, I try to bring some light to the conversation.

I write native (Swift) apps for Apple systems. I tend to avoid the "bleeding edge," as that isn't really where Ship lives, but I think that the way I do things, results in very good software (note that I didn't say "better software," as comparing against others only pisses people off, and doesn't buy me anything -unlike a lot of folks, I'm not in competition with anyone).

Of course, that doesn't prevent others from sneering at me, but that's their burden. I'm not exactly sure what benefit it gives them, as I am no threat.

If people like the way I do things, and want to improve that, then I am often fairly helpful, but I am not really into standing in the street, yelling at passing cars. I have better things to do.

> I write native (Swift) apps for Apple systems.

Swift is only 7 years old, one of the newest languages/tools in existence. This is an implicit argument against the author's case.

One might perhaps argue that Swift's newness/modernness is an exception, that it's "one of the good ones" when it comes to new systems. But this doesn't really work. Using Swift for native GUI app building is platform-specific, and writing native apps for other platforms requires other tools. If Swift represents an improvement on what came before, it implies that such improvements are needed on other platforms also. (If it doesn't represent an improvement, why are you using it?) This also implies that cross-platform solutions might be useful - like Electron or React Native!

Being chronologically challenged doesn't actually prevent one from understanding the driving forces behind modern software technology. Certainly, fads and cargo cults exist, driven in part by people's inevitably incomplete understanding and desire to follow practices that others seem to be using successfully. But to be able to distinguish between the fads and the useful advancements requires a better understanding than the OP exhibits.

Complaining seems like a perfectly fine activity to me if there's some valid content in it. But it becomes fairly useless otherwise, except possibly as you say for driving social media engagement.

Exactly.

New is not necessarily bad. Old is not necessarily good. It all depends on what we are doing, and what our goals are.

I also use PHP to write my backends. It works nicely, for the scope of my needs. I’ve been writing in that, for over twenty years. My servers work quite well, but aren’t particularly “buzzword-compliant.”

I’m not really a server programmer, though. If I need a backend to be more intense than what I’m capable of doing, then I’ll hire someone to write it, using a more robust stack, and I need to be prepared to open my wallet, as I have high standards. Good engineers will always cost more. They’re worth it. They will frequently also have gray hair; regardless of the tech.

Alternately, it becomes impossible, by analysis paralysis, to decide what stack to learn and build from. Which one is safe? Which one is secure? Which one has legs?

Which ones do you dedicate your precious time to as a direction to keep earning a paycheck?

>Which ones do you dedicate your precious time to as a direction to keep earning a paycheck?

LAMP.

I'm pretty convinced my future grandchildren will be maintaining legacy LAMP systems.

There are also great projects like Hotwire that are gaining momentum that seek to actually address some of these problems of never ending layers of complexity. I think more constructive posts advocating for things like that would be more productive than the 1 millionth "SPAs are too complicated" blog post.

Most of these solutions that the author complains about came about to solve real problems, and without addressing how we can continue to solve those real problems with a simpler set of solutions, it's really just noise.

Veterans then to gloss over the fact that most "evolution" in programming revolves around programmer experience, not around the use of resources.

The bad side is because passionate young people come in hordes and they will gladly program anything for a penny. For the company is cheaper to hire a team of those youngsters and let them make your program in every (ugly) way they can, rather than pay a fortune for a veteran programmer that takes their time to deal with code that manually handles memory.

The good side is that you no longer need a computer degree or 20+ years into programming to make something decent.

>Meanwhile, the shitty tech is winning. According to this author, bad code and bad tools and bad frameworks are reigning supreme over real engineering. Why?

Because in the time that OP spends tracking down segfaults and getting a dozen native libraries to compile for his native app, the JS dev has already finished XYZ feature. And because the environment is so high level, he can use the extra brain capacity for things like UX, business logic, and accessibility (things people actually care about) rather than meaningless implementation details.

This stuff won out for a reason. HTML/CSS/JS is literally a 10x improvement in iteration speed versus native.

It didn't win for that reason.

I've been out of the GUI scene for a long time, but I will say I've been hella-impressed with some of the more modern Qt tech.

QML gives you JS for the view layer (and some logic if you desire), and a declarative way to lay out your UI. I think it's worth a comparison as a reasonable way to quickly iterate on a UI while having something very lean and portable as the output product.

Wait, isn't Qt proprietary? I feel like that kind of vendor lock-in alone disqualifies it for a lot of use cases...

There seems to be a dearth of actually open, native, and cross-platform GUI toolkits.

Qt is a mix of LGPL for the core, and GPL for some of the "value-add" modules (for which there's a commercial license available for those who can't live with GPL requirements).

> HTML/CSS/JS is literally a 10x improvement in iteration speed versus native.

When you need to release your application across multiple platforms? Yes. Not much else even begins to compare on that front.

Compared to native development on a single platform? Not even close. HTML/CSS/JS development is painfully slow in comparison.

> Compared to native development on a single platform? Not even close. HTML/CSS/JS development is painfully slow in comparison.

I find it's often not, largely because the amount of focus on web apps means the native frameworks often are less productive by comparison than what is available for the web.

I'm still waiting for anything in HTML/JS land that's as productive as WPF.

i don't see why i'd ever spend time on any particular platform when i could avoid it. I don't like any of them, but i still want my software to work on them.

> drop their victim mentality and start putting their own ideas into practice

How? Do you send pull requests to thousands of projects to delete their codebase?

Invest into your own super wonderful alternative and they'll crumble at mere sight of your engineering superiority.

Or not.

Missing the point a bit? The author is in no way complaining about the lack of choice in web frameworks and similarly hyped up stuff.

He is complaining about unnecessary churn and unnecessary software and you obviously don't reduce it by writing even more stuff.

You can reduce abundance of software by writing more software.

Nothing kills software as effectively as creating alternative software that works way better.

Citation needed.

>Meanwhile, the shitty tech is winning. According to this author, bad code and bad tools and bad frameworks are reigning supreme over real engineering. Why?

Would it have anything to do with coding boot camps teaching people how to code specific to these frameworks vs deeper learning into broader coding?

Dead on. Building efficient and elegant software is difficult. The author should actually give it a try some time.

Yep. When I saw the tired "Electron = bad" rant I immediately went to look for a tab entitled "Projects" to see if the author had created a native desktop app with "value"[1] equal to or greater than what a good Electron app provides (Slack, Spotify, Discord, VS Code). But lo and behold, no such tab.

[1]: [Electron apps] constantly crash and has no value over a native desktop application what so ever

> Slack, Spotify, Discord

All those examples could or do work just as well as web apps, right? I don't think that's the authors message, but I'd rather have those type of apps be web-based instead of electron-based or native.

They are web apps... open.spotify.com, discord.com, app.slack.com. Even vscode.dev. The desktop product is just a repackaging of the web app with perhaps more OS integrations. If you don't want the OS integrations, use the web app. Some are available as a PWA too, which provides a nice middle ground.

They all have artificial restrictions in the web versions which makes them worse to encourage people to install the apps (actually not sure if discord does this, I've only used it a little bit). For spotify and slack there is definitely an active push to make their web apps worse than they need to be.

At least for VSCode, it's the other way around - the app was first, and even if it was always an Electron app, it was still designed and written for the desktop. It actually took some time and effort to port that to vscode.dev, which wasn't there at the beginning.

VS Code started as the Monaco editor, which was (and still is) first and foremost a code editor for web.

Electron apps are pretty much that tho. Just with extra access to the system that you wouldn't want to give to every web page.