1. 9
  1. 34

    A poor blog post. The author notes that the source of modern web development issues is based in economic reasons and yet continues to insult the devs as if they are solely responsible.

    All in all, full of hyperbole, limited actionable advice, and gliding directly past the source of the issue to land some weak insults.

    1. 9

      I was going to say something similar. The author almost gets to the realization that the major problem driving the “bad” things about the web are economic in nature, but none of their so-called solutions address that, other than saying “don’t do that”.

    2. 11

      With regard to Rails and Django specifically then that is a matter beyond comprehension. Neither Ruby nor Python should ever have been utilized for web development. They are simply ill-suited because they are too slow.

      Such a broad statement seems very shallow. Slow in what way? Development is MUCH faster in Rails than using whatever Go framework the author has in mind. And in many applications this is the “speed” that matters. There are too many billion dollar companies doing just fine providing services with Rails, your tiny web app doesn’t need to scale to millions of users.

      I don’t disagree that people could learn a lot from coding a Go web application, to broadly pronounce Ruby (or really even Python) as the wrong tool for any web development job seems ignorant.

      I agree with the author on the sentiments regarding super heavyweight front-end JavaScript, though. The JavaScript/SPA model is a scourge.

      1. 12

        Yes, the author completely misses that the reason that Ruby+Rails and Python+Django became popular is that developer time has been more costly than computing resources for decades now.

        1. 3

          Whose computing resources? Why is wasting the time of users with old computers or phones and slow connections, considered such an acceptable tradeoff?

          1. 5

            Ruby and Python run on the server, not the client. The speed would not be affected by the user having a fast or slow computer.

          2. 1

            Actually the author doesn’t miss it, but explicitly meetings it.

          3. 5

            They also miss the fact that can have a super slow back-end and still a fast experience overall. My work’s service is running on rails and is not very fast, but most likely you’ll never notice, because almost every site will be served from a cache PoP close to you almost immediately.

            For many services it’s viable to literally rebuild affected views after an update and almost never hit the path that does database queries. Most services are not big enough for this to matter though…

          4. 13

            Ugh, UnixSheikh, same guy who says that systemd is a government conspiracy. Every one of his opinion pieces is flamebait, and any kernel of truth you see in them is guaranteed covered a million times better by someone who doesn’t think “sending JSON from the backend to the frontend” is a sin.

            1. 10

              It must be so nice to be so confident and have all the answers.

              1. 6

                There are some ok suggestions in here but suggesting folks used to the expressiveness of Ruby and Python switch to Go is a bit rich. And also suggesting use of C for web exposed work in 2022, yeah that’s… not good.

                1. 6

                  None of them are developed with performance in mind. Rather, they are mostly developed by theory.

                  Actually, none of the popular web frameworks were developed by theory but rather by practice and that’s why they traded off app performance for developer productivity.

                  I agree with @NoahTheDuke that the write-up is bad and with @basus that none of the solutions address the economic problems. I think we are in the times of rapid evolution like the beginning of the industrial age when it comes to the web and things are bound to settle in a few decades. Still, there are things we can do:

                  1. Stop putting new technologies into projects just to learn them or to pad the CV. If When CFOs realise this, they will tell heads of HR to stop hiring on a list of keywords because it just propels the hype cycle and leads to pretty funny situations. There was a story somewhere that Uber produces so much NIH-like projects because promotion there was somehow linked to spearheading innovative projects but can’t find the link quickly. This covers the point about using wrong tools for the job that the blog post tried to make.
                  2. Insist on longevity and interoperability of software, especially given that it now starts to permeate all of the hardware. GDPR requires data portability, though it didn’t go far enough to mandate API interfaces for data export so that an Uber driver could export all their reviews to Lyft, for example. In US seems like there are rumors to mandate IoT devices to release software updates at least for 5 years if I recall correctly. In research, Cyber-Physical Systems’ (the academic counterpart of IoT, without a missing S for security) safety is a big thing and there are suggestions to make formal methods mandatory in safety-critical CPS projects in transport and smart city areas, at least in EU. I have an idea of my own, related to the announcement by the European Commission to commit publishing some of its software under the EUPL. If the Commission further commits to supporting some of its software for 10 years, it can lead to consulting jobs for people to maintain the OSS dependencies of that software. This way, Log4j v1 would not have to become EOL if so many people are still using it.
                  1. 4

                    This is- as others have noted- more or less complete nonsense. Every assertion is hyperbolic and none is justified.

                    That said, there is a tiny kernel of an interesting idea here.

                    Arguably, the current distribution of web browser usage is Bad. Google has done quite a few questionable, embrace-and-extend sort of things in the recent past, and even if you don’t think that they’re evil, you might want to avoid a monopoly in the browser market considering its centrality to modern life.

                    The interest point that the author glances across is that, because web development is so complex today, it’s highly unlikely that the incumbents will be realistically challenged… ever? Who can we imagine writing a new HTML rendering engine or JavaScript virtual machine in the year of our lord 2022?

                    On the other hand, if the standards for web development were simpler, if the standard method involved more reliance on vanilla HTML and CSS, we might imagine that it would be easier to compete and to diversify the browser market. Which would arguably be a good thing.

                    1. 4

                      It could be summarized as “develop for Gemini, not for the Web”.

                      Which is really fine for me but something tells me I’m kind of a niche market…

                      1. 5

                        Suggest adding [2004] to title.

                        1. 0

                          Claiming that no framework is developed with performance is ignorance at best and denial for the sake of argument at worst. Svelte, Elm and others on the frontend and Hyper and Actix on the backend have made their names on combining developement and runtime efficiency.

                          1. 0

                            My favorite (paraphrased) WTF moment in this meandering pile of nonsense: “We need to move to [blockchain based] web 3.0 because the current web uses too much power and is bad for the environment”

                            1. 1

                              That’s some solid, reasonable advice, right there!

                              1. 0

                                That’s not paraphrasing, that’s outright misrepresentation. And you even got a reply out of it, nice.