1. 34
  1. 42

    I suggest to the author, as I suggest to anybody who finds themselves imagining that everyone around them (except for themselves) must be pathologically stupid, that they suppose that all of the things they decry are motivated by sensible, relatable concerns, which nevertheless might not be the same concerns as are primary to the author, or which might be realized via methods which nevertheless might not be the ones that the author prefers or knows.

    1. 11

      Devil’s advocate even though I think your approach is the right default one:

      Does this mean it’s impossible for large groups of people to do “crazy” things? Empirically, historically, this seems false. How then do you distinguish between those cases and cases where you simply lack context?

      “motivated by sensible, relatable concerns”

      What if the relatable concern is wanting to feel cool, and use something fresh and new, or a thing that Google uses and people talk about at conferences? I’m not just being glib and dismissive. But if that is the impulse – and I think it drives deeper than most people admit – you don’t necessarily get sensible. Or… there’s plain old not knowing about simpler ways.

      People don’t have to be dumb to partake of sub-optimal trends.

      1. 1

        Does this mean it’s impossible for large groups of people to do “crazy” things? Empirically, historically, this seems false. How then do you distinguish between those cases and cases where you simply lack context?

        I normally try creating a Fermi Estimate for the problem. If it differs substantially from the scope of work then I assume there’s some missing context.

        1. 1

          I normally try creating a Fermi Estimate for the problem. If it differs substantially from the scope of work then I assume there’s some missing context.

          For example, how would this work to answer a question like “Are far too many companies using Angular when something simpler could have solved their problem better and saved many engineering hours?”

          1. 1

            I don’t think it would work for that kind of question; I use this approach for projects at work where there’s usually a missing context.

      2. 2

        I don’t know if the author really thinks that way about people or it’s just a way to emphasize the unnecessary growing complexity of some systems (given his personal experience).

        1. 7

          Being loud, angry, and intolerant is UnixSheikh’s whole deal, so I don’t think it’s “just a way to emphasize”.

        2. [Comment removed by moderator pushcx: Calling people you disagree with Nazis never improves a conversation.]

        3. 19

          Are these rants ever going to end?

          1. 12

            Most of it is exaggerated and based on actual issues, I get it. But one thing I believe is just wrong/misunderstood:

            All web servers have a built-in router.

            Those are not usable for an app. Nginx or caddy will not capture your url variables, will not convert them into native types, won’t be able to check your preconditions for routing, etc.

            It’s good to use the proxy router for simple decisions, but once you get to “this route, but extract the item by ID and continue routing, but just for logged in users who are owned, and endpoint depends on requested content type” it’s hell to do outside your app.

            In any half-complicated app you’d have the router split between the proxy and your app. Also you’d have to publish your app with multiple routing configs for each service separately. We already have this issue in PHP projects which assume you’ll be running Apache and htaccess rewrites is all you need.

            1. 2

              I thought about the same thing. But then I came over this: https://caddyserver.com/docs/caddyfile/directives/rewrite

              So caddy may solve some of the routing problems. But perhaps not all.

              1. 2

                Apache and Nginx have rewrite too…

            2. 10

              I’m disappointed that this doesn’t specifically and in more detail discuss the fact that thoughtlessly adding abstractions to problems often makes them worse in the long run (it certainly makes systems harder to reason about). This problem seems to be a problem peculiar to software due to the “frictionless” nature of complexity in software compared to physical machines. And it is related to just attempting to throw more power at these problems rather than improving the programmer’s ability to wield the power (i.e. the knowledge and ingenuity codified in extant tools) already at hand.

              Also it seems the author fails to reason solidly about technical debt: it makes sense to take on loads of this if the objective is to hit million x growth and then worry about the fallout later (and if the first to market advantage remains extraordinarily high). That approach is certainly used inappropriately by non-startups, but failing to see that this stems from the foolish attempt to “do things like a startup” when you can’t expect explosive growth doesn’t help make the argument.

              I agree with most of the author’s comments, I just think that the post could be a lot stronger.

              1. 10

                “Any problem can be solved by adding a layer of abstraction, except for the problem of too many layers of abstraction.” (Also seen as “…except for performance problems.”)

                1. 2

                  Sometimes a performance problem can be fixed by adding another layer of indirection which reads the information from all the other layers of stuff and generates the code that you would’ve written if there had been only one layer which directly solved the problem. ;)

              2. 6

                This blog is full of inflammatory low-effort content, I am disappointed that things like this make its way to lobste.rs.

                1. 5

                  By Betteridge’s law, no.

                  1. 2

                    :) Should I edit the title?

                    1. 4

                      I was attempting humor, although my experience in the industry thus far suggests that there’s going to be no shortage of any kind of madness any time soon.

                    2. 2

                      I don’t think Betteridge’s Law applies to blogs like this especially since this is obviously rhetorical, while Betteridge’s “Law” (which it’s really not) applies to possibly actionable (or at least evaluable) headlines about factual conditions (rather than rhetorical questions about possible future).

                    3. 5

                      While I do in fact have a lot of sympathy for the author here having worked on a few different javascript web frontends, I think he is glossing over some of the problems people are trying to solve with those abstractions. The key problem here I think is that the browser dev ecosystem, culturally, has a problem shedding abstractions as well as engaging in a large amount of premature tool choice on projects. A little more YAGNI and a little less height on the tower of abstractions would go a long way to fixing these problems.

                      The technology that actually givse me some hope is oddly enough web assembly. Where suddenly you get powerful tools like: dead code elimination, better type systems, better memory management primitives, better build systems and better packaging. It also kind of leaves the rest of the build systems, bundlers, and unnecessary frameworks behind since it’s different enough for them to not really fit. Much of this ecosystem’s madness is traceable to it’s roots in Javascript and browsers and the unique limitations of those roots. No std library, no way to only ship “part” of a framework, no batteries included. Node didn’t fix those problems it just brought them along to the server side. Webassembly creates a bridge between that world and the somewhat saner world of non-web development tooling

                      1. 4

                        I like this rant :-) But what about the solutions? How to escape this madness?

                        Related: Sane software manifesto + my series of articles on software complexity: 1, 2, 3 (in Czech language… hope I will find time for translation at least to English one day)

                        And it is a real shame that the younger generations who grow up not knowing anything else

                        Even some older/mature guys are becoming retarded today. Probably in order to „not miss the train“ and look „up-to-date“ and „still relevant“. Either way, those people, young or old, are generating overly complex software of questionable value.

                        “Programmer time is expensive; conserve it in preference to machine time”, but that does not apply here at all.

                        No, it does not. Because the additional layers, frameworks, libraries and tools often do not reduce the (programmer’s) workload but rather make the job more difficult.

                        The general idea that the abstraction/framework/library/etc. will save the work is true. But these ideas must be applied really carefully and judiciously because they might also terribly fail.

                        P.S. Your website looks good in lynx. Mine was also tested in this simple browser. But how many authors do this?

                        1. 4

                          For those sympathetic to this cause, future articles could take inspiration from Moxie’s writing methodology when he was describing NFTs the other week. What would really convince me to lay off the abstractions is some concrete examples of what the abstractions are in Electron, React, etc. and just how insane their performance and RAM use is compared with the “old ways”, demonstrated through trying to create modern apps. Complaining about people holding the opposite opinion doesn’t get us very far.

                          1. 3

                            It’s the 2020s, so no. Madness increases exponentially until we’re all dead.

                            1. 1

                              Good rant. I feel similarly in some regards. However, in regard to “electron apps”, the author says:

                              They constantly crash and have 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.

                              I hate the popularity, sluggishness and ram gobbling of electron applications as much as the next guy, however they do have one significant value over native applications: they are essentially write once, build+run on almost anything. That is why companies keep making them - they don’t really need a development team for each OS, they just need one electron dev team.