38 ms·

Is the madness ever going to end?

• datavirtue 5y ago
  It's because the demand for warm bodies that sort of understand how to code is so extremely high that there is no room to discriminate sufficiently. We are all working with dressed up normies that have zero clue. It's not their fault however, and trust me, they are looking for the exit.
• ramesh31 5y ago
  >Programming is engineering, it's not something where you throw stuff at the wall and see what sticks and just assume that programming languages, browsers and operating systems are made of magical dust. News to me. I've built an entire software career around throwing stuff at the wall and seeing what sticks.
• johnchristopher 5y ago
  > In the past IT people, whether we're talking about programmers or something else, were very clever people. People with a high level of intelligence that took serious pride in doing things in a meaningful and pragmatic way. 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.
• dexwiz 5y ago
  No it probably won't end. No you are not a dinosaur, but development has changed. Decades ago you could build an app from the ground up. This gave you a bunch of different layers to compose, and probably made the app overall simpler. Now most developers are given a box to create their feature in whether it's a Spring Bean, a React Component, or a serverless function, with an entire application stack under it. You could have each developer or team manager their own stack, and thus get microservices. But now you have just pushed your complexity from a single monolithic app to the space between all the individual apps. 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.`
  • torstenvl 5y ago
    That's an interesting and valuable perspective. I'm definitely one of the people who keep reinventing things that have already been done before, even though I'm not very good. But since I don't use programming to put food on the table, maybe that's okay - it's more of a hobby/educational endeavor than anything important. All the same, maybe if I spent less time writing, e.g., yet another dictionary/map, I could actually make something worthwhile.
  • Simon_O_Rourke 5y ago
    That's a great perspective, but are those peeps writing the unused frameworks just wasting their time to solve a question nobody has asked? Take the D language, it's basically a poor man's Java, with a shoddy garbage collector and aspirations at being C/C++... Is that the work of heroes or the misguided?
    • int_19h 5y ago
      I don't even know what to respond to the last assertion, because it's "not even wrong". Like, just about the only thing D has in common with Java is their shared C syntactic heritage, and an object model with single inheritance. But that also describes numerous other languages.
    • exdsq 5y ago
      D has interesting features like invariants
    • johnny22 5y ago
      Can't it be both? or none of the above? I don't know anything about D specifically, but effort spent here is likely to be valuable elsewhere. Either because of techniques learned, or approaches validated. Even if D never catches on, folks will learn from what they've done. And the folks who did it, will likely be able to get jobs in the field. I doubt the effort is truly wasted.
    • dexwiz 5y ago
      Are they solving a question no one asked, or a question that already has an answer? If there is already a clear answer, then it's probably a waste of time. Your answer needs to be better, and that is rare. When your answer is better, then its a paradigm shift to some. To others the answer is no better, and then it's just the infinite reinvention. It's even rarer to answer a question that no one has yet asked. Then you are a revolutionary.
• tlackemann 5y ago
  This is why I get paid top dollar as a consultant ;) When a company's top engineers decide to rewrite their stack in JavaScript, I get to swoop in, take $10k and tell them their old PHP monolith was just fine. Long live idiots, for I'll always get paid
  • tacostakohashi 5y ago
    It's amazing how (much of) 'senior management' is actually just stopping / not letting people doing dumb things. Turns out it's pretty much a full-time job just stopping silly things and keeping entropy at bay.
    • a_e_k 5y ago
      s/senior management/parenting/ It's striking just how much this comment also describes how I feel as a parent sometimes.
  • floodyberry- 5y ago
  • mschuster91 5y ago
    With a full-on rewrite, it's mostly because said top engineers have realized that their application has grown from tiny humble beginning to a behemoth with stuff bolted on everywhere, remnants of no-longer-used components never been removed and the likes, while their superiors won't ever grant budget for actual software maintenance (e.g. remove old cruft, update that Symfony release or in some extreme case, actually use a framework instead of hand-written router and ORM code) but they would be willing to spend money on a complete rewrite. What these "top engineers" need is a decent CTO, not people like you who come in and tell them to continue working on a tech stack that they have despised to work with for many months now. Incompetent upper management will only lead to resignations out of frustration, not to progress.
    • tlackemann 5y ago
      Yes, agreed. But do you know how rare good CTOs are? I do, because I've consulted for more companies without a good one than worked at companies with a good one. A good CTO is like a good CEO. They have to be involved in the nitty-gritty sometimes. Stepping down and up is a challenge that not many engineers possess.
• creamytaco 5y ago
  It's called "commoditization". Since programming is now a commodity, the barrier to entry had to be lowered in order to pump up the numbers. Growth at all costs! 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.
• deleted 5y ago
  [deleted]
• jokethrowaway 5y ago
  It's not going to end until companies realise the waste or there are enough developers to satisfy demand. 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.
• KennyBlanken 5y ago
  Will random tech people with blogs ever going to stop submitting clickbait-titled blog posts? 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?
  • bdavis__ 5y ago
    up next, chapter 2, about the docker infrastructure.
    • CRConrad 5y ago
      Someone else already wrote that and posted a link in this very thread: http://www.smashcompany.com/technology/my-final-post-regarding-the-flaws-of-docker-kubernetes-and-their-eco-system http://www.smashcompany.com/technology/my-final-post-regardi...
• gaze 5y ago
  The piece is kinda whiney and comes off like "get off my lawn!" and doesn't really add much beyond the myriad of other complaints. Thing is that I don't really think that many people love developing this way, it's just that nobody will pay anyone to shovel our way out from under this mess of technical debt. GUI development on windows is a schizophrenic mess and then you want to be cross platform? The only options are Qt, Wx, and Electron... or imgui... or lispworks CAPI or something. Electron has permissive licensing and you can hire JS devs and most importantly you can externalize a fair bit of the debt onto the end user as power and compute resource consumption. 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.
  • neilalexander 5y ago
    > and most importantly you can externalize a fair bit of the debt onto the end user as power and compute resource consumption "The user will tolerate it being crap" is not an excellent mindset for us professionals to be striving for.
    • gaze 5y ago
      This isn’t what we strived for. It’s what we compromised upon
• danesparza 5y ago
  You have a misspelling in your second sentence. 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?
  • widg3t 5y ago
    *its
    • danesparza 5y ago
      :-) Thank you for reminding me to be less judgemental
• Damogran6 5y ago
  Thank you for articulating this better than I could have. We had HTTPD...Then Apache2, then nginx...and a guy here is messing with GPU visualization and introduced me to caddy...which is better, for reasons. And just today I saw gunicorn (which I thought was gun-i-corn for a moment) and I see it's been around for YEARS. 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.
• 0xbadcafebee 5y ago
  > In the past IT people, whether we're talking about programmers or something else, where very clever people. People with a high level of intelligence that took serious pride in doing things in a meaningful and pragmatic way. 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.
• modzu 5y ago
  "where very clever people"
• Koshkin 5y ago
  > and while we're add it 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...
  • emaginniss 5y ago
    This comment was chief's kiss. Bone apple tea!
  • jnmandal 5y ago
    Don't think I realized there was an idiom about morels. Thanks for that
  • sebmellen 5y ago
    First a fall, in per portion to the RAM used by Electron, my C script uses basically none. These new programmers are just not four meal your with how to code properly. Should we create better education info structure for new developers, or just hall of cost everyone who codes in Electron? I'm leaning towards the ladder.
  • deleted 5y ago
    [deleted]
• lvs 5y ago
  ITT: lots of people who have promoted one trivial web technology or another who feel personally attacked by the post.
  • lezojeda 5y ago
    The one who feels personally attacked is the article's writer IMO. From this article and others from his website you can see he clearly has a problem with new developers, especially those from JavaScript. A lot of resentment can be read between lines.
    • DangitBobby 5y ago
      In general HN tends to express resentment towards web developers, especially those who make use of JavaScript frameworks. You can find people ranting about web development on this site at least once a week. I mainly chalk it up to those people having no fucking clue what they're talking about because they don't have the relevant experience, like a physicist talking about politics. They are smart and knowledgeable about things I will never understand, but they don't know anything about this and should probably shut up instead. Whether they are right or not, complaining about the modern web development practices on this website is a waste of keystrokes, because no one is listening.
• afarrell 5y ago
  > Programming is engineering 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?
  • hnuser847 5y ago
    I truly think it's more craft than engineering, and even that's somewhat generous. It's mostly guesswork, hacks, inter-team politics, and trend chasing. Imagine an engineering team designing a toaster. They have real constraints to consider, like physically fitting all of the components inside a single package and selecting materials that won't melt during operation. They have to ensure that product won't injure the user or light their house on fire. They have to carefully consider the lifespan of each component and design the product to last for a minimum number of years. The consequences of failing to do these things could potentially result in lawsuits, recalls, injuries, or even death. Now take the average web product. There are no real constraints whatsoever - almost everything comes down to opinions over aesthetics. Even the speed and reliability of the application is somewhat unimportant. Planning ahead is explicitly discouraged. Instead, software "engineers" are encouraged to be agile, move fast and break things, iterate based on feedback/complaints, and push out hotfixes when bugs occur. Software is expected to rot and be rewritten every 3-5 years in the latest language du jour. I could go on and on, but anyone who's been in this industry for more than a few years knows what I'm talking about.
    • CRConrad 5y ago
      > Imagine an engineering team designing a toaster. Heh... That supports TFA's point (if taken broadly as "old tech was better tech") in yet another way: Harking back to the famous Technology Connections YouTube video, the best toaster ever was conceived sometime in the 1940s or 50s.
    • afarrell 5y ago
      Right. Software is more like a form of artistic/literary expression. We can fight this and find ourselves confused and frustrated. Or we can embrace this and start adopting the techniques of the worlds of art and literature. * Design Crits as an available alternative to doing code reviews solo -- https://digitalblog.coop.co.uk/2018/03/28/how-to-run-a-design-crit-and-why-theyre-important/ https://digitalblog.coop.co.uk/2018/03/28/how-to-run-a-desig... * Embrace writing first drafts and then revising them -- https://twitter.com/paulg/status/1363503835390558208 https://twitter.com/paulg/status/1363503835390558208
• prions 5y ago
  It will end when people like the author drop their victim mentality and start putting their own ideas into practice. It seems that this person is content with yelling on the sidelines about how good and efficient things used to be. 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"
  • deleted 5y ago
    [deleted]
  • mmmeff 5y ago
    Dead on. Building efficient and elegant software is difficult. The author should actually give it a try some time.
  • Damogran6 5y ago
    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?
    • ramesh31 5y ago
      >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.
  • commandlinefan 5y ago
    > 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).
• bsenftner 5y ago
  I believe we, as an industry, are driving towards frameworks that can be operated with story-like analogies describing what needs to be done with no technology knowledge at all. The core computer scientists creating such a framework create it with entry level non-developers as the "end-users" in mind. Such a framework is the holy grail of software development because it will enable any Joe with any software idea to hire anyones to make "their dream". The "no code" movement is an early manifestation of this trend. BTW, the VFX world is ahead in this tread, creating production frameworks requiring no 3D graphics technical knowledge at all...
  • windows2020 5y ago
    This works great in many scenarios. But when the time comes to complete a task that the lossy abstraction that is the framework doesn't facilitate, Joe hits a wall very fast. He then needs to either unravel the abstraction, find another one or say it can't be done.
    • bsenftner 5y ago
      This is where the hold grail really pays off: those Any Joes that are deeply financially committed must hire real Computer Scientists to implement their non-standard needs. Of course, those real Computer Scientists work for the framework provider Corporation, and their expense is high enough that Any Joe is forced to give up equity for their non-standard feature. It is a operational maze designed to financially and mentally exhaust the new entrepreneur so they can be assumed and taken over by the status quo of existing deep pockets. Unless you've been asleep, this is exactly how SAP grew and continues to expand.
• the_only_law 5y ago
  I mean, I don’t necessarily disagree with the main point, but this feels like a short argument with straw-men and poor faith. 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.
  • fennecfoxen 5y ago
    > I’d rather inherit an overcomplicated Laravel application from someone that an overcomplicated raw-PHP monolith. Similar sentiments. Say what you want about overengineering and React/Redux with strong opinions™ on the paradigm and insane transpile / build / asset-transformation pipelines... I'd much rather have that than JavaScript code-snippets written to the page in the middle of nested for-loops (inside a database query result iterator) in HTML::Mason (i.e. "Perl pretending that it's PHP"). Which has happened.
    • hardee 5y ago
      n+1 problem is a choice, and programmer fault, not unique to any of that.
• kokanator 5y ago
  Agree but confused.... 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.
• root_axis 5y ago
  The author is fighting a strawman. Rather than engage with the specific problems these solutions were built to solve they dismissively regard them as just flavor of the week trends purely for the sake of chasing newness. This is true of the entire post, but I'll tackle just one since it's emblematic of my issues with all the rest: 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.
  • EVa5I7bHFq9mnYK 5y ago
    That's because Windows, Mac and all 1000 versions of Linux are intentionally incompatible silos. The only thing common is a standardized Web platform. "Hello World" shouldn't take 115 mb and trillion computer cycles, period.
  • bengale 5y ago
    The whole “newness” idea seems odd anyway considering electron must be coming on ten years old now. > The argument for Electron and React Native isn't "it's modern", it's "it's much cheaper". This is spot on. I’ve worked on a big electron project before for a massive firm and a lot of work was done before picking that direction. Proof of concept was done for a couple of alternatives but electron ended up better on balance.
  • com2kid 5y ago
    > The argument for Electron and React Native isn't "it's modern", it's "it's much cheaper". Expecations have changed. It is 2004, your company needs a simple CRUD app so your employees can work with some structured data in a DB somewhere, let's say so sales can check inventory levels in an existing database. A single developer can start up a Winforms project and throw something together in a matter of days to weeks. It can only be used by people on desktops running Windows while they are at the office, but that is fine because that is the world of 2004. 2022, your sales team needs to access inventory levels in a database. Assuming you haven't already been sold some multi-million dollar solution to do this (and you likely have, multiple times, and at least some of the implementations have failed), you now have the following requirements: 1. Some of your employees use Apple laptops, some use Windows. 2. People want to be able to access the data on their phones as well, which adds another 2 OSes to the mix. 3. Restricting the app to being onsite in the office doesn't cut it. So, you can write 4 (!!) native apps. The ugly WinForms one is still simple, but you can either adopt a proprietary "simple app building" solution for the other 3 OSes (or just use it for all 4 OSes), and have serious issues finding devs who know the niche tech you've picked, or you can make a website. Now, native apps on smart phones are a constant maintenance headache. Major OS releases break things on mobile all the time, and entire APIs get deprecated. (Another reason why writing against Windows is good, that Winforms app from 2004 probably runs just fine with 0 changes in 2022) It is easier to maintain 1 website than 2 mobile apps and 2 desktop apps. So, website it is. What framework are you going to use? Whatever one is stable, easy to hire for, and has the best tooling. OK so I wouldn't call React "stable", hopefully it has undergone its last major redesign for awhile (LOL), but there is tons of tooling for it. Of course the docs suck compared to what Microsoft had in 2004, because it turns out part of that $500 per seat license for Visual Studio went towards amazing documentation and example code. And because Web you'll get breaking changes now and then, but it still is easier than maintaining 4 native apps. People underestimate how simple Windows everywhere made life for developers. Amazing documentation, stupid good tooling, and an obscenely stable platform to develop against. A major OS version came out what, once every 3 or 4 years? And unless you were writing drivers, that major OS version wasn't going to break anything.
• deleted 5y ago
  [deleted]
• jcoletti 5y ago
  "They constantly crash..." 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.
  • wccrawford 5y ago
    It's possible that they crash constantly on that person's computer, especially if they have a bad power supply or other hardware. The problem might just be their own.
    • alias_neo 5y ago
      Dodgy stick of RAM maybe? I'm not a fan of electron, heck, is go as far as to say I don't like it, but those statements are just unfair. I run a bunch of electron apps on Linux every single day of the week for years now and I honestly can't say any of them have ever crashed. Yes they may take up a bunch of RAM, but how many software engineers have less than about 16GB, and what's that RAM there for, if not too run my tools? I can't say I've ever gotten over a few gigabytes of usage in a normal work day (not running any VMs for example). I don't use Chrome nor am I a tab-hoarder. Whether I like electron itself or not, the told built in it seems to get the job I need done just fine. Who cares if it takes 3-4 second to open, once per day?
      • strken 5y ago
        I used to do programming assignments on an Eee PC with 2GB of RAM, running Xubuntu and using Emacs as my editor. While modern netbooks generally have 4GB, and cheap laptops 8GB, it's not guaranteed that a student will be using a modern computer. Dev environments that waste RAM keep people from learning how to program, and disproportionately affect anyone using cheap hand-me-down hardware.
  • Trasmatta 5y ago
    The memory arguments are valid, but I don't think I've ever once had an Electron application crash on me. Contrasted with older native applications that would crash on a weekly basis.
• LeicaLatte 5y ago
  Not with that font.
  • ebspelman 5y ago
    Can't disagree with a rant if you can't read it.
• timmy2ply 5y ago
  I'll offer a counter, perhaps, unpopular opinion. I too, have found myself at times mentally fighting against what appears to be a tidal wave of modern software techniques. But I don't do that anymore, these days I try to embrace them using an ecological perspective. They won't all be great ideas, some will prevail while others fail, some will even survive well while at the same time layering complexity and loss of performance on the industry. However, I now see them all as being necessary experiments to further the technological advancements of the industry. Even if they are bug ridden, security nightmares, they all work to provide selective pressure and refinement by the industry in the aggregate. Upon close inspection, it looks like a mess, but if you back out and see it akin to our own bio-diversity and natural selection processes, you may begin to appreciate the wide variety of techniques and talents we have to choose from and that over time we should expect a refinement of our abilities.
• arilotter 5y ago
  > The entry barrier to programming needs to [be] high! 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.
  • deleted 5y ago
    [deleted]
  • Wowfunhappy 5y ago
    I agree. And the thing is, you could take out that final paragraph and I'd agree with every other word in the piece. It should be perfectly possible to write libraries and frameworks which are easier to use without writing additional layers of abstraction. Instead of writing a new template language in PHP on top of PHP, we could write it in C (or Rust) and it shouldn't be substantially slower or more resource intensive. This would of course require an experienced programmer who knows a lower level language, but then the barrier to entry would be lower for everyone else!
  • AnIdiotOnTheNet 5y ago
    While I can get behind the idea that lowering barriers to entry is a good idea, I don't think that's the same thing as tolerating ludicrously slow garbage tools just because everyone insist on either developing like a baby or only hiring babies. As an industry, we should be deeply ashamed at how much of the world's time and resources are wasted running poor software so a company can save a few bucks.
    • gabeio 5y ago
• etaioinshrdlu 5y ago
  I thought this was going to be about blockchain, or something else hypey like the Metaverse. 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.
• motohagiography 5y ago
  When you solve a problem, you deprive someone of one they can manage / extract value from, and so they invent new ones to manage. Problem solvers aren't actually that clever, they're more like beasts of burnden or working donkeys (asses) who have become wise to how they are being managed, but this doesn't change the fact that they are still asses. Most frameworks are new ways to favourably manage solved problems, and pointing out this fact without understanding it's on purpose is what a smart ass would do. (I am very much a smart ass.) 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.
• dave333 5y ago
  Interesting that the Unix command line is still just as functional and useful as it was 40 years ago and yet the UI frameworks have been thrown away and replaced every 2 or 3 years. My personal experience with UI has been Openwindows, X/Motif, Java, HTML/CSS, pLain old Javascript, ExtJS, jQuery, Dojo, Angular - various incompatible versions, and React. Glad I finally got to retire!
• shermozle 5y ago
  It's always someone who thinks there's nothing wrong with vanilla PHP.
• caymanjim 5y ago
  I'm a greybeard. I've been doing this since before HTML existed, and I've kept up with the changes as they occurred along the way. 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.
  • dexwiz 5y ago
    I agree with your argument. The comment about blogs taking long to load leads me to believe most of these complaints are really only applicable to small scale projects. The massive stacks used for web development now are targeted at organizations that can scale into the hundreds or thousands of web developers with varying skills. In turn, when doing small scale work, most newer developers copy the massive enterprise stack, pay the price for the possibility of scaling (both requestwise and developerwise) without every really needing to.
    • orev 5y ago
      There are far more small projects in the world than ones that need to scale to be huge, while at the same time every developer working on a small project is trying to build their resume so they can one day work on one of those big ones. So that leads the every small project using these huge stacks for no technical reason, and bogging all those users down.
• yakshaving_jgt 5y ago
  > PHP is … made in C … yet it is apparently not good enough. I'll agree that the constant churn of the JavaScript world is utter madness, but also, yes PHP is not good enough.
• jacobmischka 5y ago
  How did this unreadable stream of consciousness get on the front page.
• MattGaiser 5y ago
  > has 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. 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.
• fnord77 5y ago
  > 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? everyone wants to prove themselves by having s gh project that is used by a lot of people. So solutions start searching for problems...
• stephc_int13 5y ago
  There are a few factors that led to this situation. - 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.
• maerF0x0 5y ago
  I think this rant is going against the irrational outcomes of a few things 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...
  • Sebb767 5y ago
    > 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). It's worth noting here that Electron trades engineer time you pay for against RAM your customers pay for. On the other hand, Electron got things to a state where Linux is often supported and where I can usually run the whole app well sandboxed in my browser. So in the end, it's not that bad for end-users like me, either.
    • chrisco255 5y ago
      Customers ultimately pay for engineering time, too.
• aaomidi 5y ago
  Electron is literally the only reason Linux desktop is somewhat of a viable option right now lol
  • godDLL 5y ago
    Aha. It's also the reason I'm not running my raspi as my workstation.
• jnmandal 5y ago
  Ultimately I kind of agree with the sentiment but the sensationalism here is cringe. Also, some new tools and languages are indeed worthy improvements. It's worth calling out the ones that aren't; lashing out at all new technology as a whole is not how you should come at this issue.
• jeff-davis 5y ago
  It's because most programming efforts are built on top of a predetermined stack. If that stack isn't a great fit for whatever reason, then your only alternative is to make another layer that is a better fit, even if that same level of abstraction exists lower in the stack. 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.
• razemio 5y ago
  I am going to ask and duck. What is a seriously good cross platform (yes also web) [meaning windows, Linux, Mac, Android, ios, web] alternative to electron? I used haxe 2/3 (openfl), javafx, qt. No they are not even close. 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?
  • godDLL 5y ago
    Add raspi to your cross platform list. Now tell me how VScode runs. Kinda crap, is it not? Barely usable. And how do we fix that? We can't. I mean it's not a Commodore. It's a raspi. It streams 4K video and decodes it onto your projector on the fly. But editing code using a popular solution is not any good.
    • razemio 5y ago
      Funny that you mention this. I run it perfectly on my raspi 3 using code-server on home assistent. Now please tell me, what is a better IDE then vscode for a raspi 3? It barely uses any ram on the server side. Wouldn't it have been written in electron the code-server project would not be possible. Using a raspi not as a headless device when programming is a stretch. So the only IDEs that come to my mind are vim, emacs, eclipse Che, c9 and vscode. Would use vscode from this list, again not even close. Now expanding this further, before code-server I had to use vnc, nomachine, x2go, ssh, mosh or xrdp to use an IDE on a remote server. None of these solutions are lightweight or stable across an unstable connection besides console based IDEs. Now I can finally write software as if the IDE would run on my rather old laptop while executing code on a very powerful server with minimal setup cost and barely any ram usage (compared to a full blown IDE).
      • godDLL 5y ago
        > Wouldn't it have been written in electron the code-server project would not be possible. Please clarify what is so special about Electron in that case. It was so slow they had to do it that way, is that what you're saying?
• walrus01 5y ago
  > Why in the world has this idiotic trend of abstracting everything away by layers upon layers of complexity have seen this described as a "software russian nesting doll turducken cluster fuck" by a particularly frustrated individual.
• bsder 5y ago
  Well, if someone would just put in all the vast the work to make a good, cross-platform, multithreaded, graphics-card native, GUI toolkit for desktop, this would all go away. 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.
• phailhaus 5y ago
  I feel comfortable with asserting that the author has never worked on a complex web application. This web-dev hate borders on pathological: this is a guy that seems to specialize in Unix/Linux tooling, doesn't have a single tutorial on web app development [1], and yet has an intense hatred towards a space that he barely understands. 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 https://unixsheikh.com/tutorials.html
  • daveidol 5y ago
    Agreed. I was cringing to read this - had a laugh at the Patreon plug at the end of this poorly-written rant about something he clearly has no solid understanding of.
  • the_only_law 5y ago
    Yeah I went back to take a look at what else is in the blog, and his main schtick seems to be hating web development and frameworks, and not even in rational way.
  • goodpoint 5y ago
    Not at all. Having worked on all sort of companies and applications, the author is absolutely right.
  • BeefWellington 5y ago
    I don't necessarily disagree with your take but I think you should be making substantive counter-arguments to what the author wrote. Your post is essentially just attacking the author and of little substance in itself.
    • daveidol 5y ago
      Others on here are doing that. A few counterpoints: 1. Electron is cross platform - something the author never even mentions, 2. Really, PHP is the prefect end state for web development of all scale? The lack of even acknowledging these things is what really discredits the author in my book.
• 323 5y ago
  This article reminds me of when assembly programmers were ranting how stupid it is to use the bloated C language to create apps when assembly is perfectly fine for that, and how it's all driven by lazy programmers who don't want to learn how to write efficient code.
  • switchbak 5y ago
    Very true. Though early C compilers were pretty crap, and old machines unbearably slow. It's easy to look back from a modern context, but in the early days those arguments had some merit (at least at first). I find it important to keep that in mind when arguing against shiny/heavy/silly new tech in the present! Things like virtual machines, blockchain, new lang's, etc. In the era of the mainframe, 'microcomputers' were jokes, until they definitely weren't.
  • Jensson 5y ago
    Or hardware engineers ranting about how software is bloated when you can achieve the same thing by arranging some transistors. For example, Steve Wozniak created a working breakout game using 44 transistors. This was 1974, back then each transistor costed enough money that companies paid a lot for low transistor solutions. Today every computer has many billions of transistors.
    • jart 5y ago
      Wozniak says it was 45 chips. https://www.youtube.com/watch?v=17eUExffa5w https://www.youtube.com/watch?v=17eUExffa5w I would be surprised if only had 45 transistors. https://www.progettosnaps.net/manuals/pdf/breakout.pdf https://www.progettosnaps.net/manuals/pdf/breakout.pdf
• RcouF1uZ4gsC 5y ago
  > The entry barrier to programming needs to high! Programming is engineering, it's not something where you throw stuff at the wall and see what sticks and just assume that programming languages, browsers and operating systems are made of magical dust. 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.
  • bavila 5y ago
    I'm not normally one to fuss much over typos, but I similarly found it hard to take the author seriously when he makes a typo in the very same sentence that he attempts to extol the superior intelligence of IT professionals of yore. > In the past IT people, whether we're talking about programmers or something else, where very clever people. If you're going to talk down to people and insult their intelligence, please at least have the good sense to spell "were" correctly.
    • the_only_law 5y ago
      > in the very same sentence that he attempts to extol the superior intelligence of IT professionals of yore. Whenever someone tries to express this sort of of thing, I always have to wonder whether these superior professional of yore are pioneers of the industry back in days when commercial commuting was just starting to bud, but it’s always some guys from the mid-late 90s who seem much angrier.
• destitude 5y ago
  It's what the company prioritizes. If they can get away with spending less money on development and think the end-users will put up with whatever they made then that is why Electron succeeds.
• azangru 5y ago
  > So, now your simple news article or blog post takes ages to load on a 1 gigabit connection and requires about 3 times as much electrical power even though you're only serving text and perhaps a few images 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.
  • vbezhenar 5y ago
    Web is a terrible app platform. Unfortunately it's the best one available.
    • CRConrad 5y ago
      I hear there's a lot of things "called operating systems" out there; nearly every computer seems to be running one. Couldn't one somehow run applications on those?
• fleddr 5y ago
  It's a good rant. Basically, our computing foundation is from the 70s and we keep stacking crap on top. Given hardware advancements, it's embarrassing how we're making the user experience worse, not better. 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.
  • godDLL 5y ago
    You should. Blog. I have a title for you, for your first piece: Robots trade, CEOs fidget, managers require, coders put shit out.
• Havoc 5y ago
  Where is that xkcd about real men use a magnifying glass and butterfly effect to program. 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
• schwartzworld 5y ago
  - react sucks, just use html - electron sucks, just write native apps This article is literally designed to get to the front page of hacker news. Nevermind that these tools do exist for a reason.
• cryptica 5y ago
  I fully relate with this article. Especially this point: > 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.
• rationalfaith 5y ago
• distrill 5y ago
  > In the past IT people ... where very clever people. People with a high level of intelligence ... 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.
  • vasco 5y ago
    They're driving down the road shouting that all the cars are going the wrong way. What drivel.
  • barbarr 5y ago
    The typos seem to indicate they were using dictation to type
    • JetAlone 5y ago
      I was wondering about that too. Yeah that's probably it. Maybe carpal tunnel has made it hard for them to type to fix the typos?
  • larrymcp 5y ago
    I noticed on his "About" page that he says that English is not his native language. So I'll cut him a break on spelling! I wrote to him with proofreading changes including this one, and he has now corrected them.
• mattmaroon 5y ago
  “ It's so bad that I haven't managed to find a single industry with the same massive amount of stupidity, with the exception of perhaps the fashion industry.” Someone has never worked in a restaurant!
• irrational 5y ago
  I feel this so much. The direction web development has gone in is so insane to me. The complexity that has been introduced feels like complexity for the sake of complexity. In my opinion, the cons far outweigh the benefits. But I would never say this out loud since it feels like everyone else has drunk the flavoraid and is dismissive of anyone who is not on the bandwagon. I’m just thankful I can develop my own projects without the insanity and am counting down the years until I retire and never have to create a webpage using a build system (!!!) ever again.
  • JetAlone 5y ago
    >I’m just thankful I can develop my own projects without the insanity What a blessing indeed.. I want to retire from it too, but I've got a long way to go yet to keep making rent.
• widowlark 5y ago
  Spelling is wrong in the first paragraph.
• andrew_ 5y ago
  This entire post is peak boomer-meme. It's a rant because "new is bad." Heaven forbid they just stick with what they like and let everyone else churn. Their loves in native and PHP aren't going anywhere. Weird to see a "didn't have my coffee" moment make the front page.
  • markdoubleyou 5y ago
    Fair. Just realize that it'll happen to you (in 15 years you'll be raging, "goddammit, why does every UI require a 2 GB Roblox runtime") and go easy on the poor boomers. Circle of life.
    • andrew_ 5y ago
      Oh I'm already there. I'm 43 and have seen the "everything old is new again" cycle at least twice already. I'm just old school and don't need to air all of my gripes - I just let the youngs make mistakes we've already learned from.
• yazaddaruvala 5y ago
  > The entry barrier to programming needs to [be] high! Programming is engineering, it's not something where you throw stuff at the wall and see what sticks 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.
  • dragonwriter 5y ago
    > 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” No, it's the aspirational view of all insecure elite workers: “the job I do must have a high barrier to entry (otherwise, I will no longer command a premium salary)”.
    • deleted 5y ago
      [deleted]
• hwers 5y ago
  I'd love to go a layer deeper it's just that it's so so hard for me to grok it all and deal with platform complexities or even to get a job as easy in a spot where lower level stuff is used rather than e.g. electron. (Unless you've already spent decades grokking it.) Maybe if the lower levels were simplified (we could use a revolution on the lower levels to be honest).
• omgitsabird 5y ago
  > We have to put a completely different template system on top of PHP, also written in PHP, which now makes the application load four times as slow. Twig, Blade, etc. are generally "compiled" into PHP and cached. I don't think they should cause any application to load four times slower.
• ape4 5y ago
  Software is still a relatively young field - that's why we are always reinventing.
  • goodpoint 5y ago
    It's been 72 years since Turing's computer and 50 years of commodity computers...
    • orange8 5y ago
      And about 2000 years since the medical fields Hippocratic Oath.
      • goodpoint 5y ago
        so?
  • godDLL 5y ago
    Three generations have grown up since. One with email, one with the Internet, one with mobiles. I think it's time.
• uwagar 5y ago
  thank god in computing we dont have to use something to compute or we cant compute. you can stay simple and refuse to climb this meta complex ladder.
• SquibblesRedux 5y ago
  I'd like to see unixsheikh's take on the NFT and crypto scene.
• projectileboy 5y ago
  The piece that resonates most strongly with me is using Javascript to render HTML and CSS on the client side. Almost always, there is no good reason for this beyond lots and lots of Javascript programmers decided it was the right thing to do.
• clock99 5y ago
• deleted 5y ago
  [deleted]
• aikiplayer 5y ago
  There are times when complex frameworks are necessary because they've already dealt with the complexity and times when they're overkill or stupidly inefficient. 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.
• jakub_g 5y ago
  There are a few things: 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.
• jchw 5y ago
  I’m starting to wonder if everyone who makes these arguments has even tried making a native app across Android, iOS, Windows, Mac and Linux. It’s actually challenging to do it with Electron/React Native, and as much as I love/loved Qt, all of the effort of making things work and look nice, packaging for each platform, then coming up with a separate strategy for mobile because Qt is not good on mobile is not ideal. 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…
• profmonocle 5y ago
  > 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. 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.
  • CRConrad 5y ago
    > 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. Wrong way around. The opposite, yes, but not this way.
• AtNightWeCode 5y ago
  I think most systems today do more with less complexity than let us say 10 years ago. I worked on Java systems that have 12-15 layers in the stack. Good luck finding that kind of complexity in a modern system.
• bigbillheck 5y ago
  > In the past IT people, whether we're talking about programmers or something else, where very clever people. 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).
• hffftz 5y ago
• xwdv 5y ago
  I don’t care about the memory my programs gobble up because we’re not in the fucking 80s where we have to fight for every kilobyte. 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.
• tambourine_man 5y ago
  Whoever the author is, thank you. I feel less alone reading this.
• lucideer 5y ago
  This is a bad article, but it's a great example of why tech like Electron have succeeded. 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.
  • omgitsabird 5y ago
    > he's never had to mitigate XSS vulnerabilities in large PHP applications. You can do this with <?= e(<expression-to-escape>) ?>, where e is a function that escapes strings. Is this more work than writing {{ <expression-to-escape> }}? I guess, but this is what your template library is doing under the hood anyway.
    • vbezhenar 5y ago
      The question is not how mitigate vulnerability. Every vulnerability is trivially easy to mitigate. The question is whether it's easy to write vulnerable code. For PHP it's easy and implicit: <div><?= some_expression ?></div> For React it's hard and explicit: <div dangerouslySetInnerHTML={{ __html: someExpression }} />
      • omgitsabird 5y ago
        While I agree with the overall point, these are different environments. React normally operates in a DOM. It's templates are translated into javascript, and that javascript manipulates the DOM. PHP templates are just outputting strings.
        • 5y ago
• Subsentient 5y ago
  The company I work for hired several incompetent devs who wrote an abortion of an Electron client. It very nearly killed the company. I finally convinced the boss to let me rewrite it in Qt, and now our feedback is far, far more positive on the UX. Qt and GTK+ are one of those things that work "well enough" on the big three, especially Qt (GTK+ has serious theming issues on macOS), and it's hard to justify Electron as long as Qt or at least GTK+ exist. 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.
  • mbrodersen 5y ago
    Your argument seems to be that bad developers write bad software? Isn’t that true no matter the platform? I have written equally successful software in both Electron and Qt. In my experience, a competent developer can write great software given almost any platform.
    • Subsentient 5y ago
      While that may be partly true, Electron inherently attracts low-skilled, incompetent programmers due to its 'easiness', while in reality JS isn't that much easier than, say, Python. Not only do you have to deal with dumber programmers writing the code, but what people forget is that CPU and RAM usage isn't just some metric you see in htop or Task Manager. Electron apps are much slower than native apps at doing almost anything, sometimes to the point of obscenity. That was a big reason we were forced to ditch Electron, the WebKit bullshit was just too much for what we were trying to do. No matter how many bugs I fixed, it was still a bloated sack of shit. Qt was easy to write. Sure you had to put a few #ifdefs here and there, but for the mostpart, it was portable, easy, and Qt Creator saved us a ton of time compared to baking our own. If you write any application in "native" widgets for the host OS, shame on you. That is definitely the wrong way to do things in almost every case nowadays. That said, Qt and GTK+ provide so much better of a user experience with only slightly increased difficulty. It's hard to justify Electron.
• scotty79 5y ago
  I don't understand how can you diss Electron when you see something like VS Code or Atom. 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.
  • buu700 5y ago
    It's surprising to me that a Linux/Unix enthusiast of all people is so incensed about Electron and web tech. The alternative to Electron isn't that all their apps would be faster and more stable. It's that many of them wouldn't exist (either on Linux or in general), and the ones that did exist would inherently be more resource-constrained on the development side — potentially resulting in increased bugs, instability, security vulnerabilities, worse performance, lack of feature parity, and/or ultimately even premature deprecation to focus on higher-priority platforms. The web is a great equalizer. I'll put this another way: given the option, all else being equal, would anyone honestly choose to run the same app in the form of WinForms + Wine rather than just Electron? It might be a little faster for certain apps in the best case scenario, but on average it's going to be worse in just about every way; that's before taking into account that in real life all else is never equal (see previous paragraph).
  • int_19h 5y ago
    > I don't understand how can you diss Electron when you see something like VS Code or Atom. Because you also see things like https://github.com/microsoft/vscode/issues/22900 https://github.com/microsoft/vscode/issues/22900
    • scotty79 5y ago
      How does that cancel out all the benefits? You have multiple cores and all of them constantly do somehting when your computer is on. You have graphics processors that run code every frame which probably half of is bot strictly necessary. Is the cpu load from blinking cursor good or necessary? Definitely not. Is it important? Mostly not when compared to all the benefits. And this issue was resolved pretty effortlessly (if you omit trolling).
• vernie 5y ago
  If not for the references to Electron this reads like nerd rage from 1998. Be mad, dork.
• Semiapies 5y ago
  When will it end? 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.
• qwerty456127 5y ago
  > 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? 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".
• scoofy 5y ago
  This feels like flame-bait. 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.
• MaxfordAndSons 5y ago
  To those that agree with the author: it's quite disheartening to beginners (often learning JS as a first language) to hear these things. It's just purposeless gatekeeping that borders on anonymous hazing. Who in good conscience can assert: >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.
• userbinator 5y ago
  The author is very on-point about reinventing the same things over and over again, sometimes with even less functionality than their predecessors, and also consuming more resources while doing it. 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 https://news.ycombinator.com/item?id=20678938), on a machine far more powerful, the decline is definitely real.
  • crubier 5y ago
    You used one bad app so there is a general decline ?
• jabbany 5y ago
  What I don't get about the rant is why it matters what the "modern" way is. 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.
  • int_19h 5y ago
    As a developer, that is correct. As the end user of those "native" web-repackaged apps, the experience is just subpar. Give me back my native widgets and consistent UX.
    • crubier 5y ago
      You can have them back! Just use old versions of your apps, or old apps. But you won’t because deep down you know that those “web repackaged” apps are actually better than old GTK apps. More features, nicer UI, etc.
      • emodendroket 5y ago
        It depends, probably the "old version" of Spotify or whatever doesn't work anymore.
      • int_19h 5y ago
        Not really. The problem with old versions of apps is that they don't support anything newer (standards, protocols, file formats etc). And then there's security vulnerabilities. But that aside, when picking between different pieces of software, one of which is Electron, and the other one is Qt, I'll always pick Qt unless the Electron one is drastically better feature-wise (haven't seen that in practice yet).
• mbrodersen 5y ago
  It would be really nice if software developers that rant about X instead come up with a better alternative to X. You don’t like Electron? Great! Come up with a better alternative that still gives you the multi-platform/cost advantages of Electron. You don’t like Node? Great! Show all of us what a better solution would be that still gives us all the advantages of Node. It is super easy, but also super lazy, to ignore the advantages of X and only focus on the disadvantages of X. There is a reason why X became popular! An alternative needs to give the same benefits while fixing the problems. If nobody can come up with a solution for that then perhaps X is a pretty good technology.
• jd24 5y ago
  This rant reads like some old dude got left behind and is now yelling at the clouds; this is what gets on HN front page nowadays? It's clear he hasn't researched WHY these newer technologies and tools exist if he believes it is because we are just adding "unnecessary complexity."
• andrewstuart 5y ago
  Removed - too negative.
  • ldiracdelta 5y ago
    If they're passionate and argue well, but are willing to disagree and commit, then they are useful. I've been places where nobody pushes back and asks, "why are we creating nano-services for everything?" "Why is it a good thing to put two NICs and the Internet between every little thing in our system?" When no one is willing to point out that the emperor has no clothes and we're here to deliver features, not endless rewrites, that is a path to doom.
• thederf 5y ago
  As I see it, the cause isn't industry-specific, it's just incredibly apparent because of how fast our industry repeats the cycle of: - 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.
• deleted 5y ago
  [deleted]
• jrochkind1 5y ago
  Uh... if Electron really let a 2-year-old baby (or, hell, even an eight-year-old) write software as widely used as appreciated as Slack, Signal (Desktop), or VSCode... I'd say that whoever wrote Electron should actually get a Turing Award, because that would be society-shaking! 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.
• namelosw 5y ago
  It's simple: 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.
• kuahyeow 5y ago
  > It's so bad that I haven't managed to find a single industry with the same massive amount of stupidity, with the exception of perhaps the fashion industry 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 !
• SassyGrapefruit 5y ago
  Always seems odd that the cranky dinosaur doesn't use his/her unix super powers to gather likeminded talent to build the world's greatest, simplest, cheapest app and retire a billionaire. It's almost like there is more to the decision making process than that. /s
  • jart 5y ago
    Dinosaur here. I used my UNIX superpowers to do just that. https://justine.lol/sectorlisp2/ https://justine.lol/sectorlisp2/
• moralestapia 5y ago
  I had a meeting today with a "cybersecurity expert" who was consulting a big company that had no idea what a hash function was. Literally no idea, as in "never heard the term before". 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.
  • maerF0x0 5y ago
    security folks sometimes dont realize the connection between Hash functions (for data structures) and Cryptographic Hashing (aka digest) functions. Perhaps that was the confusion? https://en.wikipedia.org/wiki/Cryptographic_hash_function https://en.wikipedia.org/wiki/Cryptographic_hash_function
    • DoingIsLearning 5y ago
      No I have definitely seen people with fancy titles around data security and now also GDPR 'specialists/consultants', who lack the most basic CS knowledge, sometimes coming from other fields like business and administration. People will chase opportunities wherever they find them, if you have a good network and managers who are as clueless as you then you can absolutely fake it till you sort of make it (in large enough corps).
      • drw85 5y ago
        To this day i haven't met a security consultant or data protection person that had any idea what they were talking about. I'm not talking about experts, but people that were appointed and got the title "Security something". Most of them were regular business people that just parrot some buzzwords like "Encryption" and "at least 256 bit".
  • torginus 5y ago
• phendrenad2 5y ago
  No, the madness will never end. Once you've been programming in the industry for awhile, and have seen a few fads come and go, you start to get fed up with the churn and just want to do things in the simplest way. Electron? Bah, I'll just make native apps for Windows and Mac in C++ and Swift! React? Bah, I'll just write a simple pure-JS app as a .js file. 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.
• nashequilibrium 5y ago
  This gave me flashbacks of Flash before Steve Jobs killed it.
• baryphonic 5y ago
  I don't disagree with the theme, but it would be much more persuasive coming from a Lisp corner of the world. 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.
  • housecarpenter 5y ago
    This may be somewhat off-topic, but I think the point of "you lose debug stack traces!" is that with tail call elimination, you have more possibility for confusion from people who inadvertently write a tail call, or who write something tail-recursive without caring about the stack growth (e.g. if it only recurses a few times in their use cases). That's where the increased difficulty comes from; of course loops/state machines/tail-recursive functions are hard to debug either way. I guess basically the problem is that with loops you know what you're in for with regards to debugging, whereas tail-recursion is kind of implicit---you have to learn how to recognize a tail call, which is non-trivial, or at least non-trivial compared to distinguishing a loop from a function call.
• RandyRanderson 5y ago
  I call this: PLIRT - Pyric, Low Interest Rate tech. 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.
• deepsquirrelnet 5y ago
  The need for talented developers has vastly outpaced the supply. The bar has to be lowered to include a wider pool of people. There is currently no other solution for businesses. 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.
• unixer 5y ago
  Author is right. 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.
• ksec 5y ago
  I mean System / Low Level / Embedded engineering doesn't suffer ( as much ) from this. And I am not sure if the author is aware, all of his complain are about Web Development. And I dont disagree. Abstraction on top of another abstraction. 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.
• phreezerburn 5y ago
  It is to create busy work and obfuscate the process to create job security for the old and confuse the young from becoming competition to big tech. 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.
• soheil 5y ago
  Completely agree with the sentiment of the author my question is why is this happening? I see a lot of comments here mentioning things like groupthink or specialization as the reasons, but how can really smart people suffer from groupthink or how can generalist engineers not afraid to write sass/graphql/js all in the same line of their pure React component want to specialize? I hope this thread doesn't turn into a shit show, but instead sheds some light on the real reasons.
• emadabdulrahim 5y ago
  I'd bet any money the author never worked on a complex web application beyond simple CRUD apps. Absolutely no credibility when the entire post is a strawman rant with zero value from reading it. Disingenuous.
• emodendroket 5y ago
  It's worse than that, Mr. "Unix Sheikh." Look up the Unix Hater's Handbook.
• EVa5I7bHFq9mnYK 5y ago
  So basically hardware improved 1000 times, but out of that improvement, corrupt programmers took 999 for themselves, to make their lives easier. The end user got almost no benefits. Where is my Minority Report UI?
  • mrweasel 5y ago
    Perhaps not corrupt programmers, and hardware improved much much more than 1000 times, depending on your reference. It is a valid question though: "Did we spend the speedup the hardware gave us wisely?" It's reasonable enough, in my mind, that we spend some of the speed to great higher level language, so that we could solve problems faster. Besides that, in all honesty, did we spend the remaining speed all that well? Most of the problem we solve are still data input, some calculations and an output. Some times we skip the calculation bit, and just retrieve our data a little later, other times we skip that part too, and just store stuff. With the exception of video and gaming... what have we actually build in the last 15 years that couldn't be done before. Sure, we can scale to more users, but we use more servers that ever to do so. For the average office and home usage, we wasted so much speed, and it's not clear where it went. The chat applications are the best example, my Google Chat eats 700MB of RAM, yet the only added a "Create video call" button and inline images, as compared to IRC or other platforms from 2000 and earlier. Don't get me wrong, there are stuff like neuroimaging, better weather reports, climate models, simulations, CAD, all that good stuff, but that's not helping the average computer user who just wants to check Facebook and read spam.
    • EVa5I7bHFq9mnYK 5y ago
      well, ICQ from 1996 did have chat, emojis, inline images, file transfer etc. Voice and video added a little later.
• pjmlp 5y ago
  It is called fashion driven development, everyone looking for the latest fad in the hope to be the next keynote guest speaker at Conference XYZ, have the blog posts spotted on the technology news forum of the day, sell consultancy services, whatever. 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.
• vbezhenar 5y ago
  I consider it an evolution. We blindly iterating over many possible variants, we try to mix languages, yes, we throw things on a wall and see what sticks. Some things do stick, other things will be replaced. It's a chaos, but it's getting better.
• teekert 5y ago
  "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!?" 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.
• deleted 5y ago
  [deleted]
• jlengrand 5y ago
  I'm on both sides with this one. 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.
  • fgkramer 5y ago
    Getting a job straight out of a bootcamp is hard. Getting a front-end job out of a bootcamp without knowing the most popular technologies is even harder. Bootcamp's interest will always be to increase their students odds to be hired rather than foundational knowledge
    • jlengrand 5y ago
      200% behind you! My point was not to shoot at bootcamps. (Though currently in Europe my friends working in bootcamps have never seen such a fast hire rate). Bootcamps follow what the market requires. My main point was more about the market we have created for ourselves :).
• muskmusk 5y ago
  > Programming is engineering; it's not something where you throw stuff at the wall and see what sticks and just assume that programming languages, browsers, and operating systems are made of magical dust. 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.
• deleted 5y ago
  [deleted]
• bodge5000 5y ago
  As others have pointed out, its a strawman post, and the arguments being made in favour of what he is against aren't what he is saying they are. 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
• nurettin 5y ago
  Madness will only end when developers stop being bitches and start asserting your points to customers who want their web pages to look like triple-a game demos.
• _xnmw 5y ago
  Some abstractions are worth it, some are madness. The only way to know for sure is to actually try it, and gain years of experience in a particular paradigm. 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.
  • Mr_Yolokovich 5y ago
    This is just the case. It is very difficult to know up-front if added complexity will actually save you anything in the end. New concepts, frameworks or whatever are created for a reason. If you willingly adapt any new shine toy without thinking about what problem it solves you get what the author is ranting about: unnecessary complexity without any gains. I think that the problem is that a great deal of knowledge (and good guesswork) is needed to make those decisions and even then it is hard. Sometimes the removal of an unnecessary requirement will be the biggest factor in bringing the complexity down. But it is not often the case that this is obvious to the development team. I do love to listen to how different companies solve problems from friends in the IT industry. Nobody is every on target in regards to "complexity used" vs "complexity actually needed"!
• patkai 5y ago
  "it's not something where you throw stuff at the wall and see what sticks and just assume that programming languages, browsers, and operating systems are made of magical dust" 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.
• MrDresden 5y ago
  Like has been mentioned here already, its due to cost cutting. 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.
• WA 5y ago
  It's funny that Electron and web devs are blamed for "increasingly more abstraction". The thing is: You can't really build cross-platform native apps. 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.
• vladstudio 5y ago
  On every post dedicated to this topic, I feel obligated to mention these 3 links: https://htmx.org/ https://htmx.org/ https://unpoly.com/ https://unpoly.com/ https://hotwired.dev/ 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/ https://htmx.org/talk/ (scroll down and look to the right side).
  • midrus 5y ago
    Also, https://tallstack.dev/ https://tallstack.dev/
• ddtaylor 5y ago
  > it still is a templating language at the very core, yet it is apparently not good enough. Standalone PHP templating is torture.
  • tonyedgecombe 5y ago
    Yes, it didn't take long before Smarty came along. This is pretty dating considering PHP was envisaged as a template language.
• ya_throw 5y ago
  It will continue until we become unable to mass-manufacture ever more powerful yet cheaper media consumption devices. Then we will be screwed.
• paganel 5y ago
  I totally agree with the author, but I guess this strategy keeps many of us employed.
• lkrubner 5y ago
  While slightly hyperbolic, the author is going after a real enemy, the tendency use layers of abstraction where they might be overkill. In a similar vein, I wrote a comedic satire about the incredible overuse of Docker/Kubernetes: http://www.smashcompany.com/technology/my-final-post-regarding-the-flaws-of-docker-kubernetes-and-their-eco-system http://www.smashcompany.com/technology/my-final-post-regardi...
• pllbnk 5y ago
  I have the opposite feeling that because of the huge growth in the number of developers new great software tools are being released so frequently that it's hard to keep up, but also the competition and the number of options to choose from is incredible. And actually, this has been possible thanks to the tools the author blames. I am speaking from my rather conservative point of view, however it's hard to not appreciate that.
• CipherThrowaway 5y ago
  >But, noooo, you're a dinosaur, you don't understand anything 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."
• zaptheimpaler 5y ago
  Its a good rant, even if some of the details are wrong. I think what he's really getting at is just that software is flooded with bad developers. Its only become more true as salaries go up and everyone flocks to the field. 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.
  • dilyevsky 5y ago
    Don’t blame the player… The reason this happens is not the salaries but bc it is rewarded by hiring and management practices.
    • zaptheimpaler 5y ago
      I do blame the player. "Dont blame the player" is a bullshit copout. Players are all there is. If no one builds evil shit, it simply doesn't get built. People who either learn to sometimes put their self-interest below something bigger or robots who are easily bought. Concretely, candidates can choose not to enter a field they are uninterested in or make an effort to develop an interest, and managers can design hiring pipelines that test for these things.
      • dilyevsky 5y ago
        This attitude achieves nothing but quickly becoming that guy as far as peers and management are concerned (assuming you can even get through the door to begin with)
• blodkorv 5y ago
  when will we see javascript and html rendering built in onto our oses.
• mro_name 5y ago
  > 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? 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.
• deleted 5y ago
  [deleted]
• resonious 5y ago
  If the old way of doing things is really so much better than "modern webdev", then where are all the high-profile sites written using nginx routing and raw PHP?
• Dowwie 5y ago
  > In the past IT people, whether we're talking about programmers or something else, were very clever people. People with a high level of intelligence that took serious pride in doing things in a meaningful and pragmatic way. 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.
• anovikov 5y ago
  This is all done for the sake of higher speed of development. Building a native app in Qt will take a lot more time compared to an Electron equivalent, same goes for React Native vs Objective C mobile app. 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.
• felipe385 5y ago
  React native, one codebase, one team one language. Native ios and/or android app, two code base, two teams, two different languages. I don't know, you tell me. Unless you are government funded, what is more cost effective?
• rsynnott 5y ago
  > In the so-called modern day it's like everyone - except a few - has dropped their brain on the floor. They keep inventing "revolutionary new ways" of doing the exact same thing that could be done in a dozen ways already. 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....
• donymemony 5y ago
  It is surprising how the comment thread degenerates into a supposed market need, ignoring the issue. 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?
• wired_devil 5y ago
  I think over time there were more use cases for everything. People still make sites with pure html and css (myself included) but that is not always the best way to do it. For example, take a complex admin control panel thing like AWS, it would be a nightmare to replicate that without a front-end framework. A really complex business logic made with a bunch of .php files? You would end up with a code base that is a mess and hard to maintain.
• wired_devil 5y ago
  This things exist to solve "modern" problems, like the "inconvenience" of waiting 0.5s for your page to load. So you have to add a placeholder thing. But for that to be smooth, you need to have an SPA, and SSR. So you end up with a whole new approach, just to not see a blank page/appearing text for 0.3s.
• tikiman163 5y ago
  I think the problem with this article is pretty simple. Confirmation bias plus an unhealthy dose of Juvenoia. He admits in his update that the jobs he takes are cleaning up after projects that have already been recognized for their failures. He also reduces younger developers to a very basic strawman. 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.