Is the madness ever going to end?

The argument for Electron and React Native isn't "it's modern", it's "it's much cheaper". Hiring experienced desktop application devs to build a quality native app for each platform is going to be expensive, hiring a few JS bootcampers to build one react UI that works on every platform is extremely cheap - shittier performance is the tradeoff to instantly have access to every platform. It's not a coincidence that Electron apps like e.g. Slack, Spotify, Discord are massively dominant players in their markets, I doubt you'd look the engineering leads of these companies in the face and tell them that you believe they put no thought into the tradeoffs of Electron and that they're just following trends.

These types of arguments are incredibly embarrassing to read, not only because they betray a stunning lack of familiarity with the topic, but it's basically a conspiracy theory: everybody is stupid except me, all these successful companies making billions of dollars and attracting top talent are just throwing money into a fire for fun.

[1] https://unixsheikh.com/tutorials.html

I'm not going to refute the author's points one by one. Everything being complained about exists for a reason. I agree that it's incredibly complex. It's overwhelming. That's why people specialize.

An individual can still own an entire application and infrastructure, limit their technology choices to those from the 90s, and produce a perfectly functional, modern web application indistinguishable from anything using the latest tools and frameworks. It's a whole lot of work, though.

If you take the time to learn some of the modern tools, they'll save you a lot of time. Why re-invent the wheel? But all these time-saving frameworks are complex, and learning all of them would take years, if you haven't been keeping up as they evolved. You can learn one or two of them quickly, though. You can specialize.

That's why we have DevOps teams, UI teams, API teams, database teams. That's a lot of people. But that's what it takes if you want a high-performance web application that can scale to support hundreds of millions of users, is responsive around the world, supports a variety of languages, can handle disruptions, complies with regulations, and on and on. Don't need those things? Then stick with PHP and HTML on a server you run yourself. This isn't the 90s anymore. There are a lot of people out there, and if you're building something worth using, it's a different ballgame.

I strongly disagree with this sentiment. I think the author's view that frameworks like Electron offer "no value over a native desktop application what so ever - well, perhaps with the only exception that now a 2 year old baby can make something shiny that you can click on with your mouse." is missing the point that a "2-year-old baby" making something shiny you can click on is an amazing feat, and an example of the power of the democratization of computing technology.

I do agree that tech stacks are increasingly obtuse, and not something any one person can carry in their head. I do agree that this is problematic. However, I really believe that the more individuals get access to a technology and have their barriers to using it removed, the better odds we have of letting someone with great ideas execute those ideas.

I explained the concept to her and she started referring to it as "encryption", I told her it wasn't encryption and she immediately started to debate me about that. Let that sink for a bit, she really thought she knew more than me about a (fundamental) concept that I just introduced to her world a few minutes before.

There's a plague of incompetence and mediocrity everywhere, and that is one cause for the issues that OP is talking about. It won't get any better soon so expect to have a lot of fun in future years.

At the end of the day, naked tech has no value. It's only the end-user features that make money. The industry has optimized for this, and that is what gives rise to all these seemingly insane practices. They aren't great from a pure tech perspective, but they help speed up feature development.

Paradoxically, the community still values naked tech much higher than end-user features. That is why the community heroes are those who write kernels and frameworks. So you have a million developers all trying to "make it big" with their bespoke framework. 99% of these go no where, but even that 1% that gain some traction just add to the constant churn of `inventing "revolutionary new ways" of doing the exact same thing.`

Putting aside the downsides and reasons not to use Electron, this statement is just false. They are not "constantly crashing." I currently use at least Figma, Insomnia, Slack, Spotify, and VS Code and these apps rarely crash, if ever.

This is true. They were exceptional, and there were far fewer of them. They worked in organizations that tightly controlled intellectual property and don't share their source or methodologies for free with the world. Some of these people had an issue with the barriers to entry and did something about it, democratizing access. They did crazy things like open source their work and evangelize an open source ethos. They created more accessible programming languages. They created frameworks based on methodologies that they learned the hard way. They changed the world.

After a solid 25 year run of it, we are in a period of great technological abundance built on sharing knowledge and technologies. There is so much available now. Yet, we are in the infancy stage of developments that can barely be imagined. Whatever seems like madness now is nothing compared to what is to come. More languages. More frameworks. More ways to solve the same old problems. More abstractions built on abstractions built on abstractions. And, occasionally, there will be force multipliers.

As I write this, I feel energized, not demoralized, about where we are and where we are heading.

Fuck Electron. I've seen what it can do to a product firsthand. If you get a competent web dev, it might work, but it will be slower than snail shit. Just write it in Qt. You don't need to use C++, Qt has bindings for many languages, including Python, Rust, JS with Qt Quick, and even Lua. Myself, I don't mind modern C++, though in many cases I prefer Rust.

1. People tend to put excessive hope in silver bullets, quick fixes, and the easy path. "Discipline" is generally shied away from.

2. It's an attempt to save the more expensive thing (engineer time) for the cheaper thing (RAM) especially in the face of rapidly improving hardware (which may no longer be true).

3. As engineers become expensive, people who have little interest in the subject become sufficiently motivated to hit the minimum bar, bringing down the average talent/quality of the pool. I am daily shocked by the number of engineers that do not understand the differences between implementations, and how "good enough" for a single scenario is not "good enough" for a complex and unpredictable future. Your 1 month implementation may be "faster" on paper, but if we consider the implementation time until yours and mine have acceptable robustness under duress, acceptable bug counts, predictable outcomes in unpredictable scenarios then my 6 month implementation will beat your "requires rewrite" (quarterly) by years... But never mind that, the engineer with the crap impl will "save" the company $100K a month in opex when he cuts the inefficiency in half and be promoted to architect. Meanwhile the engineer that does an efficient impl, maybe slightly over schedule will languish because there isn't even a 10% gain to be had, or the thing runs so stably the project is entirely forgotten about for years (because it just works) ...

So yeah, Electron is what we get when we pursue logical fallacies with little to no accountability for the true outcomes, and no rewards for excellence and subject mastery. Yup I'm a dinosaur too.

Anyways, I'm ranting now too...

It's just like everything else in today's economy -- incredibly short sighted and whatever you make will either evaporate or be someone else's problem in short order. But, that's how you behave in such an environment! You'd get fired for writing a cross platform toolkit if the the expectations are set through the current climate of shipping shit apps quickly. Apps that function just well enough to retain a subscription or shovel ads or mine data or upsell or whatever.

You'd have to change the entire reason why people are paid to write software to fix this. People aren't "stupid," they're on average lowish skill (JS bootcamp to first hire...) and behaving rationally under the incentives.

By bad I DON'T mean junior or inexperienced. Bad is someone who really doesn't have any intrinsic motivation or drive to improve their craft, or worse doesn't care how it impacts the world - they're in it exclusively for the money. It really sucks working with people like that. Like this is literally what this entire stupid orange website used to cheer for 10 years ago when recruitment and VCs all talked about hiring for passion, its why github contributions and side projects and an interest in tech were valuable signals before they became another metric to be gamed.

Tech really does seem to be increasingly full of mercenary types now. People who give 0 fucks about ethics or integrity. Don't care what their employer does, don't care about their craft, don't care about working multiple jobs in secret. Just robots you put a coin in and turn the crank to get some code out. Github Copilot has admitted to using all Github code, regardless of license. Mass theft. But some robots built that because they were paid enough.

Long live idiots, for I'll always get paid

https://htmx.org/

https://unpoly.com/

https://hotwired.dev/

These are the tools that promote the idea of keeping app state on server and client/server talking HTML, not JSON. If you're not yet familiar with the concept, you'll love reading Essays here: https://htmx.org/talk/ (scroll down and look to the right side).

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 situation is really bad for the industry." Also, why?

People with the mentality like the author don't actually want to build things. They just want to sit and complain. Their sense of righteousness and victim mentality gives them more pleasure and validation than actually engaging with the "modern" tech world.

Some other articles by the same:

- "Using a framework can make you stupid!"

- "So-called modern web developers are the culprits"

- "One sure way to determine if you are stupid"

- "SQLite the only database you will ever need in most cases"

- "No, your website is not a web app even if you call it so"

Personally, I think another commenter got it right pointing to commoditization (interestingly I find the commoditization of computing in general has greatly decreased my interest in it, but that’s a me problem), though I always find the ire towards web dev as the root of all evil to be a little too strong. There’s a lot of bullshit, but I see bullshit in plenty of other domains as well. Web development just has the status of being the largest platform at the time.

Also over abstracting is bad, so is over/pre-optimization and frameworks can add a ton of unnecessary overhead, but y’know, something about hammers. That being said, I’d rather inherit an overcomplicated Laravel application from someone that an overcomplicated raw-PHP monolith.

Because you know that in 10 years you'll have to un-learn all of your Electron and React skills and re-learn something new. Equivalent, pointlessly new, but new nonetheless.

The problem is, nobody is going to let you do that. Chasing the new shiny thing is, for better or worse, part of the software industry. You will always have to learn something new that does the exact same thing the thing you already knew how to use did 10 years ago. The best you can do is find some company that's stuck on some previously-cool technology, but even then they'll want you to rewrite it in the new thing.

Right now developers are in demand, they can charge a premium and they need to justify a career by filling their resume with accomplishments.

OSS (unmaintained or overengineered is fine) is unfortunately one of these.

This problem would be greatly diminished if we had small companies delivering value and getting paid based on that - thriving or ceasing to exists if needed. Instead big corps lead the way and pay politicians to complicate regulations and keep the status quo.

The bigger the corp the more it resembles a government: inefficient, full of useless layers and completely detached from actual performance.

Most engineers will live all their career in a place where their input doesn't influence much the success of the company and they will be awarded plenty of time to dedicate to new non-innovations.

Sadly this is the fallacy of all educated people: “… is <what I’ve studied > and gained an excellence in, not throwing stuff at the wall to see what sticks”.

The reality is human improvement comes in two ways 1. Repetition for excellence and 2. Exploration for innovation.

Innovative exploration has always been a stochastic walk by relatively educated people into the areas that are their knowledge gap. Even physical exploration is only made safe through mental exploration first. e.g. All of astronomy prior to space flight.

Even as someone most interested in excellence, you’re better off helping foster/improve exploration than trying to hold it back.

I normally don't mind typos and would never comment on a misspelling like this. But I also cringe pretty hard at people lamenting over how dumb people around them are. The fact that this kind of rant is so full of typos is fairly appropriate.

It's not like any of the old tools have disappeared right? If you don't like Electron/NW, nobody's stopping you from building native apps with Qt, GTK, or you can just draw your own UI raw! If you don't like frameworks with their own templating systems, maybe don't use them? I don't like them either! and yet rather than complain I just don't use them...

Abstractions by their nature make some use cases easier and others harder. They trade off efficiency for familiarity. If an abstraction is "popular" it just means many people appreciate its benefits over its limitations for their particular use case. Being opinionated is the whole point. If you don't like it or if it doesn't fit, don't use it.

Gatekeeping in general is bad. Dismissing a modern framework because it's "too high level" is rather silly. On the other hand, dismissing someone only because they're not using the "modern" stack (whatever that is) is equally silly.

You also seemed to be focused on only web development. I would argue that "IT people" are not limited to web development -- and that you're overlooking the entire maker movement (including Raspberry Pi's and Arduinos), the breathtaking development going on with self-driving cars, and the development still taking place with AI.

But as always -- follow the money. Old school engineering shops got their money from the military (the internet is thanks to DARPA, after all). Web 1.0 got it's money from selling physical goods. Web 2.0 got it's money from venture capital and digital goods. What are we selling now?

> Why in the world has this idiotic trend of abstracting everything away by layers upon layers of complexity gained such a strong foothold in the industry? Has everyone except the "unix greybeards" gone mad!?

The complexity adds brittleness and security vulnerabilities to software. Essentially every popular tool these days is over-complicated. Also, the fact that the industry has evolved into some kind of monolithic hivemind has had the effect of forcing everyone into these brittle, over-complicated technologies and has censored much of the nuanced dialog around software design in favor of blunt dogma.

And I feel old. It used to be you secured a system when you knew every single thing that was running on it. Those days are long looooong gone.

And today, I had to go find Visual Studio 2019 because hashcat needs CUDA needs VS19 and Microsoft REALLY wants you to use VS22, but CUDA doesn't support it.

And so it goes.

There is still rock-solid engineering to be found, usually in domains where the stakes are high (for example, fintech), but anything web-related is best kept away from if one is allergic to bullshit.

This article is a long boring rant with zero insights, in which the author never thinks to ask why...

> Why in the world has this idiotic trend of abstracting everything away by layers upon layers of complexity gained such a strong foothold in the industry? Has everyone except the "unix greybeards" gone mad!?

... ok he does use the word "why" once but only in a rhetorical question. It's never asked honestly.

Electron solves problems that "unix greybeards" have been loudly and wilfully sticking their heads in the sand about for decades. Yes, it solves them badly, but that's a lot better than not solving them at all.

... he also complains briefly about PHP templating libraries which tells me he's never had to mitigate XSS vulnerabilities in large PHP applications.

http://www.smashcompany.com/technology/my-final-post-regardi...

What happened is speed. You need to ship fast or you're dead. The need for speed is not just because of commercial dynamics, also because of another major industry failure: programmer productivity did not scale up.

2 decades ago it was expected that by now we would be on 5G languages. Where you basically are modelling applications instead of coding them. This never actually happened, we're mostly at 3G still. Which is relatively low level grunt coding, error prone, repetitive, etc.

In fact, sometimes we even sink below 3G. Recently Chrome shipped a feature that allows a developer to tell whether the internal layout engine should regularly update a section of an HTML document or not. Whilst performance optimization is admirable, it really is kind of ridiculous that a developer has to involve himself in paint cycles and GPU stuff. There's even articles telling you how to write JavaScript in such a way that the bytecode compiler runs slightly faster.

What??

I'll continue with another example, to show my age. In the 90s, I used Borland Delphi quite a lot. It's basically drag and drop UI building and then you connect code with events. Incredibly intuitive and productive. An the app would be lightning fast, much faster than today's "desktop" software running on hardware a 100 times more powerful.

30 years later, and we're hand coding for the web. There's no robust layout builder. No standard library. Not even a standard development environment, we have to cherry pick it together.

With productivity this low, and needing to ship fast, the only solution is to build another crappy abstraction on top of the pile of garbage.

Importantly, this often fails. It doesn't actually lead to higher productivity, rather even more complexity. Nor does it typically improve the user experience.

Why does it continue anyway? Because the person suggesting that framework never pays the price. When the choice starts to hurt, they are long gone. Some other poor sucker will be maintaining that ancient Angular project.

Which brings me to my final point: the profession of software architect seems to be dead entirely. It's just coders now, making seemingly random short term choices. But I guess that is the modern state of the world: extremely short term. Nobody does anything proper or fundamental anymore.

I should start a blog too.

The benefits are clear. This software could grow plugin ecosystem vastly exceeding anything that was previously possible even after pouring millions of dollars into it.

Electron is better than everything else by various engineering metrics. Just not RAM or CPU usage. And despite large RAM and CPU usage it manages to be way faster than many native IDEs that came before.

I feel like someone could have written the same 10 years ago. "But why do we need something so inefficient as Python, we have C that does the job and is much faster". "GUIs? Such a waste of resources, CLIs do the job just fine and you go faster with it!"

At the same time, I'm also personally quite bored with the sheer amount of complexity we seem to put in everything those days. Layers of frameworks on top of frameworks, especially for simple projects. My friends who followed bootcamps lately learn React, not Web Dev. That is a problem IMHO in the Long run.

Instead, it complains about stuff like Electron.

I think the author is wrong that the technologies he complains about are all that bad.

Also, there was no world in which a traditional Unix system was a good experience for a regular person, and it's never going to happen.

Just today, I was discussing with a friend about the lack of tail calls in mainstream languages (outside of FP), and how the typical reason cited ("you lose debug stack traces!") makes no sense under any scrutiny (the stack losses from looping are necessarily total, yet tail calls can easily be implemented flexibly to allow for optional stack growth in certain situations like debugging). So we get more complexity (iterative loops) because the pop culture of software development repeats irrational conclusions (apparently) without thinking.

Same goes for folk advice like "never rewrite" (okay, okay, it went badly for Netscape once, or something), "never build your own tools/languages" (yes, this isn't software, but the Empire State Building was constructed within a single year by a firm that constructed all of its own tools custom for the job), "role-based access control is necessary for security" (capabilities are actually quite cool), "always reset your password every three months" (lulz). There are many others.

I am starting to believe that behind every phrase of false but universally-accepted IT folk wisdom s a billion dollar idea waiting to be demonstrated; extra if you can combine a few together AND give the currently lost wanderers out there a bridge to the simpler, more enduring way.

If all the website is doing is serving news articles or blog posts, then sure. But, web is increasingly used to build apps. Apps are different from documents. No, it isn't crazy to build apps that run in the browser; web has a fantastic distribution story. And apps can't be reduced to a markup language and a stylesheet.

Low interest rates drive money into speculative hands and then in into the salaries of tech cargo cultists, Resume Oriented Architects, Tech mono-hammer-wielders[0] and other people who should never be given the power to make decisions. This creates all sort of bad ideas and tech. We are in a monstrous PLIRT bubble ATM. Pyric because them winning means all of us losing.

[0] Every problem's soln is methodA/techX: the only one these ppl ever use.

He also doesn't appear to have recent experience being a developer that was involved with the first iteration of a project. Yes, things do get over complicated and need to be simplified later. There's always going to be someone getting over excited about using a new tool and insists on using it despite it being expensive and not meeting any additional requirements. The problem is his opinion is entirely based on hindsight and the fact he only gets work after that excited guy has either changed their mind or left.

He also doesn't clearly see the potential benefits of some of these frameworks and architecture. He definitely doesn't get the very basic idea that proper architecture requires choosing solutions based on the business needs. A small simple we pages don't particularly benefit from from complex architecture. Purely offline desktop applications certainly don't benefit from using react native, especially if it's doing anything complicated.

However, standardization of solution approaches across applications does have the benefit of making it much simpler to maintain any employee pool capable of continuing to develop and maintain their software. That's why when an internal tool is needed to manage semi complex data it's generally best to continue using Angular for the web ui and not suddenly decide to use Razor.

I built my first raw PHP and vanilla JS web application SaaS about 15 years ago. Some things have changed for the better since then, and some for the worse. Since then I've seen hundreds of frameworks, ideas, concepts come and go. Some of them, like Symfony/Laravel are a godsend which made my development much faster and easier. Other ideas, like React/Angular are unnecessary piles of complexity which add little value to the customer. I maintained a large Angular 2 app in production for several years, and after that built a startup on React, then I decided frontend JS frameworks and SPAs simply weren't worth the effort. Went back to HTML-only and a little vanilla JS, and the result was absolutely refreshing -- far less complexity, and the users can't tell the difference (it's actually faster and MORE reactive than most react-crap apps built these days). But I wouldn't go back to raw PHP, the abstraction layer that Laravel provides is well worth the performance tradeoff.

Is it?

Genuine question that I've been asking myself for the past several years: In what senses is software engineering actually an engineering discipline?

If you make a project trade-off for the sake of code maintainability, is that based on empirically tested knowledge or following a design pattern guided by an artisan's intuition about how code will be interpreted?

- Moore's law and the free ride of software during a few decades

- The difficulty of doing text rendering and UI properly on several platforms

- New generations of programmers being proficient with the tools they used to learn, favor using them as long at it works

The free ride is mostly over, this is a good thing, I am not sure if this is too late or not.

Someone has never worked in a restaurant!

Twig, Blade, etc. are generally "compiled" into PHP and cached. I don't think they should cause any application to load four times slower.

JS Bootcamp graduates are easy to find and employ for relatively cheap. Experienced developers (no matter if self taught skills or classically trained) are fewer and cost more.

So most of the new and shiny tools and apps are broken on arrival, and often stay that way for a long time (MS Teams is for instance awful to use even to this day).

However there are plenty of wonderful applications out there that aren't being written haphazardly but rather by professionals that care about quality and stability.

The author should just select the tools he wants to use, and stay away from the rest. It is what I do.

Honestly.. Yeah.

Modern tools operating at higher levels of abstraction allow teams to create large amounts of functionality very quickly for more platforms. This changes the economics of software supply.

It's a fallacy to look at an app and say "I'd like this more if it were native instead of written in Electron" because Electron is part of how that app was delivered with that functionality at that price point. It's like ordering a $20 pub steak and saying "I'd prefer this steak if it were A5 Wagyu."

I mean, I think there are serious rose-tinted spectacles going on here. We don't tend to think as much of the horrors of the past as the javascript-y horrors of the present, but they were there. The worst excesses of OLE/ActiveX (1990-early noughties) spring to mind....

Uh, no, IT people were idiots decades ago too. I was one of those idiots. I've watched myself become less of an idiot, over a very long period of time, because I can see my old self in other people today. But even that is a fallacy - I'm not actually less of an idiot, I just see my old idiocy and assume because I've seen it that I'm smarter now.

I find the "impostor syndrome" meme pretty funny. Tech people seem to get impostor syndrome when their egos develop a crack and they see their own lack of understanding, and worry somebody else will see it too. But then a tech person with a stronger ego convinces them that it's all fine, because actually we're all either idiots or geniuses and nobody can tell the difference.

The tech industry is basically at the same level of advancement as people who built small buildings in the medieval period. Large enough that you need an experienced craftsman to put it together, but small enough that they're not using geometry or doing the math necessary to safely build large structures. The idiocy will continue until society forces this industry to be a real regulated engineering discipline.

This article is literally designed to get to the front page of hacker news. Nevermind that these tools do exist for a reason.

I'll agree that the constant churn of the JavaScript world is utter madness, but also, yes PHP is not good enough.

Rudeness aside, this shouldn't be dismissed. The same designers you already have on staff who make your web sites look nice can make your desktop apps look nice using the skills they already have. Things like React Native mean that the engineers who make your web app can make your mobile apps (on both major platforms at once!), again using mostly the same skill set.

Yes, this leads to lower quality software! Electron apps use tons of memory and have huge binaries, React Native apps take longer to launch, etc. But the cost savings are hard to dismiss, especially for startups trying to get to market ASAP. And most importantly, the market doesn't seem to be punishing companies using these lower-performing technologies at all, so why would you not use them?

As someone who works with stuff the author hates (I work with Angular, NativeScript, and reverse proxies on a daily basis) I agree that it's all horribly inefficient and I'd love to to it the "right" way. I just love the time savings more.

I mean, no joke, democratizing software production is huge, and important, and hugely beneficial -- when more and more of our lives involve software, being able to produce it is hugely empowering. I don't know how much Electron really does that (we know it doesn't really let 2-year-old babies produce software), but that the author would find it of no benefit whatsoever if it did, or even something to make fun of or disparage...

When in other discussions people are like "the reason there aren't good no-code development tools is because software engineers don't want there to be, they are threatened by them, they keep them from us!" I'm usually like, nah, that's not what's going on... but it turns out they're literally talking about THIS GUY!

So anyway, I stopped reading there. Near the beginning.

However, I thought the more interesting to address would be

> There is something seriously wrong with the IT industry...

I think you'll find the same case whenever you get close enough to any industry, but don't agree with the general consensus. From afar, most industries, including IT, seem to be well organised and know what they're doing. Its only when you get into the weeds with them you see the chaos surrounding it.

Case in point, music. I've been playing around with synthesizers for the past few years as something a bit different from programming. But as I've got closer, I've come to see that simple problems often have inane solutions, where things that you thought one box could do on its own have to be handled by 10, all plugged into each other with different cables and in a different order.

So yeh, I'd say this is just a natural consequence of being in the industry. Talking to friends in completely different industries, I don't think this is unique to IT at all

Maybe stop blaming people who use tools that enable this and start blaming Apple, Microsoft and the Linux community for being incapable of providing one native UI kit with one native language that truly enables cross-platform development.

As someone with a background in philosophy of language, the idea that i can write a program in python instead of C is basically my barrier for entry.

I learned first-order logic, and I don't have a degree in CS.

Does that make me a bad coder? Maybe. I can still apply my knowledge of logic to solve a lot of problems that someone who spent years learning C instead of studying mathematical logic can't.

I dunno, whenever people stop thinking it's cute to use small monospace fonts for body text and make the text almost as wide as the page.

Reading this, made me wish the entry barrier to writing was higher. I mean you should definitely have a copy editor and proof reader to make sure you are not leaving out words (such as “be” in the first sentence). Back when writing first started, you had to get your own clay and cut your own cuneiform stylus and carefully craft your characters and then bake your tablets. Now, any random person on the Internet can write.

/s

Actually this aspect of programming is what makes it so exciting. There are no gatekeepers. You can throw stuff up against the wall and see what sticks. You are basically limited only by your imagination, creativity, and time in what you build. This low barrier of entry to programming is to be celebrated and we should be working to lower it even further.

Of course, you don't want to do that for every project, so there gets to be one common open source layer to serve that purpose. So now lots of people like the new layer and use it, and then it becomes prescribed for other developers. Then it's not a perfect fit for all those developers, and they start writing another layer to change it again. GOTO 10.

Another thing that happens is if you are used to working at layer N, then layer N-2 is really scary low level stuff. It's much more comfortable to write layer N+1 rather than step down to N-2. Even if N-2 is actually a lot simpler if you just lose the fear and try it.

I don’t care about building abstractions on top of abstractions because we’re not building code to last centuries, we’re just trying to last for about a year or two before we do a completely different solution.

You might as well ask why modern architects build thin crappy glass buildings instead of solid stone structures that last for a millennia. Simple: we have better engineering knowledge of materials and techniques so that we can build things to last just long enough for when we want to replace them, and with the least amount of effort and material required while still being within safety tolerances. We do not need to overbuild. You overbuild only when you need something to last a very long undefined amount of time or you don’t know what the fuck you’re doing so you play it safe.

The unfortunate side effect is that capable developers aren’t usually interested in solving simple problems inefficiently. So you won’t find them applying to your jobs.

This is the mistake, web/desktop app programming is exactly a place where you throw stuff at the wall and see what sticks. It does not matter how great your app is if no one is using it. Conversely if your app is successful you can always pay someone a ludicrous amount of money to fix it, software is nice like that.

Databases and operating systems are a completely different beast. In those domains things get so complex that proper engineering is essential and in those areas you also tend to find "better" engineers. But web and desktop applications is like building tool-sheds, engineering rigor is irrelevant. It matters when you build sky scrapers though.

>The entry barrier to programming needs to high!

as a blanket statement. It's an absurd assertion that seems to presume all programming does or should take place at the same level of mission-criticality/resource efficiency/engineering elegance.

To get a bit meta: I remember ~7 years ago when I was starting my career, these kinds of uncharitable, gatekeepy screeds would mostly just elicit nods of agreement from the HN masses (while making me wonder if I could ever be a "real programmer", severely exacerbating my imposter syndrome). I'm glad the web tech Overton window has shifted somewhat and there is more push-back now.

Seeing how far the demoscene has taken the C64 and ZX, I wonder if we'd see some sort of resurgence in skill if there was some sort of mandate on maximum hardware requirements, e.g. something like a 1GHz Pentium III with 256MB of RAM. That would've been a very comfortable machine in the early 2000s to do things like text messaging and audio/video calls, and in fact I did. Yet, having experienced the Horror of Microsoft Teams (https://news.ycombinator.com/item?id=20678938), on a machine far more powerful, the decline is definitely real.

Asking a few questions in response would be meaningful:

Do you ever write scripts to solve routine tasks so you don't have to do them over and over again?

Of course you do. Most ( not all ) of these examples are attempting to abstract a problem. In some cases they do that well in other cases they don't.

Have you upgraded your OS in the last 20 years?

Again, of course you have. Each of those upgrades have some useful and some not so useful things.

Did you upgrade your vehicle to a Tesla?

I can't answer this one but the same applies here. If you want to state "well yes because it helps the environment." My response would be simply a large number of auto advancements over the last 20-30 years makes the vast majority of that a reality for you.

So no, you will not stop attempts at progress. Some will win and others will become Studebakers but this is the activity that drives innovation.

When it clicks that most people are miserable because it works for them and most problems are trivial but for it being someone's job to manage it and ensure it's never solved, you can probably find some peace.

everyone wants to prove themselves by having s gh project that is used by a lot of people. So solutions start searching for problems...

I get to think the reason is competition. Your Qt app may run 4x faster taking 3x less memory, but i will build my Electron app first, eat the market, racing to the exit before yours gets released (and yes this also explains why nearly every software product we use is such a trash - the ones that aren't trash never got past MVP because trashier ones were out of the door first, and got funded).

This is a problem but i can't see any solutions to it. It is the nature of industry itself.

- Make thing - Thing becomes ubiquitous and widely used - Thing has warts and limitations - Make new thing on top of old thing, because old thing can't be reworked without major consequences because of its ubiquity. Repeat.

If you've worked in any job with reasonably complex processes, there's likely a few procedures that no one really understands, but when people try to change them or build on them, they only break things or get more confusing.

Not sure what can be done about it, but I have a hard time blaming anyone or anything.

I don’t disagree that Electron apps kind of suck, but it has practical answers to problems that Qt, for example, doesn’t. There’s nothing like Electron Builder…

1. Companies use Electron because they don't want to spend money on the desktop. After all, desktop users are declining.

2. You'll only get much worse, or not even usable softwares if you use the same small budgets to build native apps on multiple platforms.

Building an excellent Electron alternative that is not web-based is not in corporations' interest. Hackers are all ranting about Electron, but the only way to defeat Electron is to get together and build a high-quality open-source alternative because not many will pay for it, or it would be just rants forever.

Perhaps a bit too much hyperbole, but lots of industries have these cycles of increasing complexity. The necessity of such complexity is in the eye of the beholder.

  - Agriculture. Herbicide -> GM plants to resist herbicides
  - Automobiles. Manual -> Auto
  - Finance. HFT anyone ?
  - Construction.
  - Medicine.
  - Accounting. GAAP
  - and finally... Quantum Physics !

We should be making things simpler. But instead we have continue to add complexity. And most of the time needlessly. Since the industry gravitate towards solutions to gain economy of scale. There is no turning back, or separate tools that only fits Google instead of 90% of the market.

Next thing what is bad about vscode? I really like this application as a prime example of perfect cross platform compatibility. It is also electron based. Just because 90% is shit (because it is fast, easy to use and most important to deploy) does not mean it's the libraries fault, right?

The point being made in other comments about minimizing dev time vs maximizing reach / impact is really solid (re: Electron).

My real takeaway from the rant (which I found pretty amusing) was that the author isn't terribly effective at discussing these issues with others and feels like they just get labeled as 'Old' when trying to do so.

Yeah, I wouldn't be so sure about that. Lot of self taught who blew up things big time and are deeply familiar with the stack that the company they have been working at for 20 years relies on but would be lost in another company.

Absolutely no credibility when the entire post is a strawman rant with zero value from reading it.

Disingenuous.

I hope this thread doesn't turn into a shit show, but instead sheds some light on the real reasons.

90% of developers come from jQuery and WordPress world. Back then, they were using an existing framework and trying to reinvent the wheel on top of it.

These days, with changes in market, they are on the bandwagon of Next, Nuxt etc.

There are only 10% of fluent JavaScript engineers who know ins and out of the language and can understand and challenge various design patterns. Rest are just making six figure serving HTML, CSS hidden behind ultra complex frontend architecture.

This is huge when it comes to time to market and leveraging existing code and skills. Who are the people who are even learning native desktop anything anymore? It is hard enough to find developers. Now go find people who know/are willing to learn that.

Or, you can pack up an entire browser, a full Javascript runtime and interpreter, and use something that both programmers and users know that kinda, sorta works.

Sure, "worse is winning". But "better" hasn't even stepped up to the starting line.

Nothing new has been invented for the web since the JSF specification, all popular frameworks are copies of it, or its components. More than 10 years have passed and copies of this continue to be created.

And beyond the web:

Do we really need another Linux distro with deliberately obfuscated usage settings?

Does every application really need its own package manager with a new syntax?

because you can jumpstart without knowing anything about the problem at hand. And appear smart. And do tech-talks about it. And not dealing with the problem at hand saves you from failure. It's just not adult.

Known to all who rather wiped the windows than starting the thesis.

Just like with some silly fashion decisions, the only cure is to wait that it gets taken by a new fashion wave that hopefully is less silly.

Problem 1: is that all native platform owners built they own empires around their proprietary APIs as their competitive advantage. It's easier to do this, especially early, to crash to competition. Now the things have matured and various platform have extremely similar capabilities. Not the same, and not the same perf, but like 90% are overlapping.

Problem 2: Distributing things via web is orders of magnitude easier than anything else. No need to fly half of the world to install stuff on client machines, or send him a CD to do it themselves. No need to wait for the lords from Apple, Google or Microsoft to kindly verify your app (which takes a week). You can release on the web as much as you want. 100 deploys per day? Sure why not, if your CI can handle it.

Problem 3: People are reluctant to install stuff, or can't (not much space on device, no admin etc.). Web just works, for anyone (assuming moderately up-to-date OS).

Problem 4: Be generous, imagine you have infinite resources and money is not an issue. Now you need to build the same bloody thing for web, Windows, Mac, Android, iOS...

Fine, Alice built a Windows version and Bob built a Mac version. But hey, there's a small discrepancy in algorithm in the two. And the labels are different in the two, oops. Shit, translations in German are different too! Yadda yadda yadda, been there done that. And Windows team has higher velocity than Windows, what we do now? We want to have feature parity at all times.

It's not impossible, but the bigger the company, those overheads on every little thing become insane. Maintaining two+ enormous codebases in different techs to be in sync visually, algorithmically, localization, release process-wise... Good luck.

And hiring experience native devs is ultra hard and expensive. Hiring tens/hundreds of them, even more. I'm not surprised big companies get away from native; especially since web version are de facto mandatory for all kinds of software those days.

Now, iOS is different because Apple puts a lot of restrictions around what is allowed and about monetization. Plus the quality bar is pretty high. And iOS has some capabilities that are difficult to obtain from web browser technologies. Tough call, iOS native that is.

The blog post addresses none of those issues. I wonder if the OP ever worked on a team who had to ship the same product across 3+ tech stacks.

Actually, it is - and he just described evolution. And for the record, I don't like it, but what can I do. Would like to go to the cathedral, but I'm stuck in the bazaar.

This probably is because the industry wants backwards compatibility. It almost seems a miracle we have finally switched to Python 3 and stopped importing Unicode support "from the future".

News to me. I've built an entire software career around throwing stuff at the wall and seeing what sticks.

I've been in and around this industry for a long time and that's not exactly the way I remember it. (To clarify, of course there were clever people, but also a whole lot of otherwise).

The secret is that it only takes one person to build a website/business.

Everyone working at big tech should create their own thing and create competition.

The actual subject of the rant:

> Why in the world has this idiotic trend of abstracting everything away by layers upon layers of complexity gained such a strong foothold in the industry?

Well, I remember that I had to set up PHP and mess with php.ini, get nginx installed, php-fpm, get them talking and then I could install NextCloud which would complain a bunch about my nginx settings and time outs and url mappings etc.

Now that I have some "layers upon layers of complexity", I just add some completely understandable lines of "code" to a docker-compose.yaml file and boom. There I have it. I want to update? No more downloading, moving the old folder, extracting, then running occ, no, I just `docker-compose pull`, `docker-compose up -d`.

OP can rant al he/she wants because things aren't the way they used to anymore, but to me it just sounds kind of childish and tantrum-like. You can still do things the old way of you want, make a desktop native desktop app, make as many as you like. I also prefer them, but I can see the advantage of using the same tech for the web as for the desktop from the dev's point of view, so this is what we get. And I think a lot of complexity exists so that we can have infra as code, and that code is nicer if it is simple.

"All web servers have a built-in router. Whether it's NGINX, Apache, lighttpd, Caddy or something else. But no. Let's not use that; let's add yet another router on top of that with a single entry point and then basically re-write every single request before it gets served."

But have you tried Traefik? Just add some lines to your compose file and all your stuff has https, you want some basic auth? Add some lines. And we can put it all in git. It's much better imho than using every project's fav webserver and settings to do things. I cry when I think about the stuff I would have to configure without the layers of abstractions.

have seen this described as a "software russian nesting doll turducken cluster fuck" by a particularly frustrated individual.

Standalone PHP templating is torture.

Abstraction is indeed getting heavy but I don’t think it is a problem. Witness the recent enthusiasm for static sites and serverless. Sure that has its own complexities but the desire for clean minimal design is still there in some quarters without reverting to full html only

I hole-hardedly agree, but allow me to play doubles advocate here for a moment. For all intensive purposes I think you are wrong. In an age where false morals are a diamond dozen, true virtues are a blessing in the skies...