1. 35
  1.  

  2. 15

    I’m convinced the real problem isn’t frameworks, but the mindset that frameworks are inevitable and necessary. They’re not. There’s a mistaken belief that software dev is best when snapping together ikea parts.

    1. 7

      There’s a mistaken belief that software dev is best when snapping together ikea parts.

      A thing I say a lot is that if you’re not on one of a handful of specific teams at a handful of specific companies, you probably should not be inventing new technology; you should be figuring out how best to apply existing technology to solve the problems you’re facing. It’s possible to be uncharitable and dismissive and characterize this as “snapping together parts”, but that’s the uncharitable and dismissive characterization, not necessarily the objectively true characterization.

      A lot of my work output is web applications. I use a backend framework to help me build them. Sure, I could sit down and, every time, write the whole thing from scratch, or by gluing together smaller libraries so I can tell myself I’m not using a framework (I am, no matter what I tell myself). But why? A huge percentage of web app development is CRUD operations against a database. Why not use something that generically implements this stuff? That way I have more time to spend on the things that aren’t such stock patterns that they’re implemented for me out of the box by a framework (which still won’t involve developing new tech, just more work hunting down the right existing tech to use and implementing it).

      1. 2

        I’m dismissive of frameworks, not libraries. I want to see more of the latter, especially those that are designed to play nicely.

        I’m hard on frameworks because they’re typically designed as ad-hoc DSLs that destroy software composition and modularity. They bundle a myriad of concerns into one single unit that you’re often told to use all of. Each feature it provides often doesn’t compete fairly in the open source marketplace due to its bundled nature. Their monolithic nature makes upgrades perilous, esp in dynamically typed languages.

        My argument is that I believe software design is better when you don’t hand over architectural responsibilities to a framework. Common functionality can be abstracted out into high level components that your app uses, rather than being used by. This view is not common. I’m not totally sure, but I think the clojure community seems to get this idea best of all: an app is a collection of libraries, some in house, some external, and a little bit of glue code.

        Edit: the web’s enormous complexity is a catalyst for framework creation. I believe the framework-centric view is largely motivated by the need to stuff this complexity under a rug that someone else worries about mostly. Also, I view most languages as not able to compose software well enough, so we end up splintering languages themselves via frameworks in order to get the expressiveness we want. There’s a lot to think about here.

      2. 6

        You can go further and question why the mindset might exist. I don’t think you can tackle the problem without doing that, but it’s tough to cover all of the situations. Do you have thoughts on that?

        This is not a complete list of what I was thinking:

        1. I learned development with a frontend framework and write my services with node.js. I’m productive in this framework. All of the feedback I have received from the stakeholders I interact with has been good.

        This person (and it could equally be a group of people) don’t know what they don’t know yet. They’re inexperienced, but have mastered one tool. Who will actually guide them? In my experience this happens a heck of a lot as soon as you get outside the tech industry and are dealing with agencies and outside contractors. Experienced people have moved on and the next generation of hires is learning on the job. The site could be developed for big brand name who don’t consider them a tech firm. There is a lead time for them to understand best practices and a tendency for management to go for bling.

        1. I’m a backend dev asked to create this flashy new site. Personally, I’d have done most of it with Rails, but they’ve got a UX designer than is looking for these specific things and a project manager who has promised the owner we can deliver it. It needs to be delivered sooner than expected. Management would flip out if they thought we were doing any homegrown framework building.

        Possibly is the closest to a case in tech where people should probably know better. There are, however, different pressures from different stakeholders. If you can work out how to influence these stakeholders then you can convince them of a better approach. You might be able to win folks over with data and analytics too because stakeholders may be sensitive to this, but not be in possession of the right information/analytics.

        1. This is just V1 of the site/product which could really have been done in Rails. We have X, Y, and Z which you’d agree would be worth the cost of such a heavy framework.

        Lots of times V1 is it. There is relatively little that can be done since it’s already legacy. No one has time to do optimisation because everyone is on to next thing because that’s going to make the organisation a success.

        1. 4

          I like these scenarios, as they are a good cross-section that covers many bases.

          1. This is the sweet spot for frameworks. I don’t see an issue here. Perhaps the meta-issue is a lot of software falls into this area, and it raises tough existential questions for full-time software practitioners when they might perceive their job is mostly color-by-number. (I’ve hit this, it is tough, it made me question why I went to school and studied hard only to play in DHH’s tiny conceptual sandbox. No offense to DHH, but Rails is boring compared to CS.)

          2. Management having a say in whether a framework is used is a red flag. Could be the case where devs just talk too much about implementation details, or a micro-manager who is unable to trust that the work will get done. Also could be the case that management in this case also does some dev, and insist on a framework as a cheap form of insurance. In that case, the dev in question could show that certain requirements can be met with less code than bolting lots of frameworks on. However, I concede that this will not impress many people as they approach software dev with a purely consumeristic mindset: “we need to use the best hash table library for our CRM [which is not CPU-bound]!”

          3. This is a common “design-failure-but-market-success” scenario. I don’t have any special wisdom for this other than I really wish framework developers would be graded on the size/coupling of their API instead of how many votes they get on Hacker News, because I absolutely believe there is a better middle ground between no framework and total framework.

          In a lot of these, the context in which the work is taking place is a leaky abstraction that bleeds over into the work itself, and sometimes even affects the end product’s usability. To me, that indicates that there is a failure of business process itself, especially WRT to the craft of development not being respected.

      3. 53

        *writes a rant about how developers are petulant little children who care more about “convenience” and “fun” than “performance”*

        *puts it on medium*

        1. 19

          I really hate this kind of response. It’s super-trolly and contributes nothing except making you feel good about yourself for somehow finding the “loophole” that allows you to ignore the valid objections raised in the article.

          We don’t all have to be perfect paragons of virtue at all times in order to be allowed to complain.

          1. 15

            They’re blaming all performance problems on moral failings. These people are too whiny and self-entitled to care about the customers, so they use convenience trash like WEBPACK and BOOTSTRAP. Their language oozes contempt.

            In that context, “you used a bloated website for personal convenience” shows how little they actually thought this through.

            1. 5

              No, it doesn’t. It shows the fact that they didn’t have the time to put up their own blog website and maintain the code for it, which is a PITA. Do you think that the author works for Medium and personally contributes code for their website? All of the people that already agree with the sentiment that “bloat is bad” are going to hoot at your epic comment and meanwhile the average person will look at it and be confused about why you’re such a dick about people not having the resources to maintain their own blog.

              1. 21

                He’s saying that people who trade performance for convenience are bad developers, and then he trades performance for convenience by using Medium. I don’t see anything wrong with trading performance for convenience. I see something wrong with him being an asshole to people who trade performance for convenience and then doing it himself.

                If he doesn’t know how to post his stuff anywhere but Medium, then he probably doesn’t know enough about web development to make sweeping critiques about web developers.

                1. 6

                  He or she knows stuff is bloated. He or she posting on Medium does not invalidate his or her knowledge of bloat.

                  She or he is not an asshole merely for pointing out that bloat is a problem and we’re all complicit.

                  1. 12

                    He’s not an asshole for pointing out bloat. He’s an asshole because he lays all blame for bloat squarely on the feet of people who use frameworks, calls them “McDonald’s line order cooks”, and claims anybody using a convenience is doing silicon valley cosplay.

                  2. 6

                    For basically every developer alive, blogging is not a job, and nobody is spending 40 hours a week doing it. What a ridiculous false equivalence. Some people have families and lives outside of work they must dedicate time to instead of idealistic puritanism, and can yet somehow still criticize the work they see happen on the job. Strange concept, isn’t it?

                    1. 4

                      That’s a lot of snark when it’s not at all obvious why work-vs-hobby is a critical distinction for determining whether or not something is eligible for criticism. In particular, software businesses (like hobbyists) also have finite resources (notably developer time) and must make decisions about how to spend those resources. Contrary to the false dichotomy put forth by TFA, these businesses’ interests are generally aligned with their users such that choosing to spend developer time on new/improved features is often a better value for the user than performance. I’m a performance hawk, but even I don’t pretend that performance is the only valuable feature–that’s patently absurd. It turns out everything is tradeoffs, and the people ranting about web performance without acknowledging the tradeoffs aren’t worth listening to.

                      1. 0

                        Did you respond to the wrong comment?

                        1. 1

                          Nope. And I’m not sure what about my comment makes you suspect I was responding to the wrong comment.

                          1. 0

                            I didn’t say anything about businesses having “infinite resources” so I was confused when you suddenly changed topic completely

                            1. 0

                              Not changing the topic; just giving you the benefit of the doubt. I was responding to the most charitable interpretation of your ambiguous comment, because while the most charitable interpretations was still clearly wrong, it is more understandable and less nonsensical than other interpretations. Feel free to clarify your position.

                              1. 0

                                So what you’re saying is that you grafted nonsense onto my statement because people using their time away from work for anything other than being productive is nonsensical to you? I don’t see why I should clarify my position when you’re obviously just being a troll.

                2. 1

                  webpack implements tree shaking. It is not a trash.

                3. 3

                  Hate it or not, but it neatly reflects the problem. Easy trumps performant.

                  1. 2

                    I disagree that this is a trolly response. It’s sarcastic and brief to be sure, but it certainly accomplishes something. It points out that the author of this article is a hypocrite, and even if hypocrisy isn’t the same thing as being wrong, it’s good to know that someone is being hypocritical when evaluating how to treat people who are wrong in the way described.

                    1. 1

                      You can make everyone a hypocrite if you try.

                      https://thenib.com/mister-gotcha

                      https://thenib.com/mister-gotcha-vs-the-green-new-deal

                      It’s a cheap and pointless tactic of Status Quo Warriors. Nothing can be changed because we’re all hypocrites for living with things as they are now.

                  2. 12

                    *writes a rant about how developers are petulant little children who care more about “convenience” and “fun” than “performance”*

                    *puts it on medium*

                    This is quite a dismissal (appeal to ridicule?). Are people who post on medium not allowed to complain about web performance, simply because they post on medium?

                    1. 15

                      They can both be right and be hypocritical, pointing out the hypocrisy isn’t wrong just because they’re right.

                      If /u/hwayne said, “You’re contributing to the problem you claim exists by putting your article on medium, therefore your argument is wrong”, they’d be committing a logical fallacy. They’re not saying that though; they’re agreeing with the author about what the issue is, and pointing out that the author is needlessly contributing to it.

                      1. 9

                        I don’t actually agree with the author, because they didn’t do anything to support their claim. They just said “it’s devs’ faults for using frameworks” and left it at that. This comment has a different explanation:

                        While frameworks add overhead, they are hardly ever the main source of bloat. In my experience, there is always lower hanging fruit than initial page size:

                        • Analytics and trackers
                        • Ads
                        • Huge third party SDKs (e.g. social login or videos with ads/DRM)
                        • Large images
                        • Fonts

                        Only the last two have to do with developers. The others are, unfortunately, the current business model of the web. )

                        1. 4

                          If developers didn’t make the decision to use the frameworks and libraries they use, then who did? Spooky ghosts?

                          1. 7
                            1. Are frameworks and libraries the primary cause of web slowness, or is it something else? How much does using frameworks and libraries contribute to slowness versus having tons of trackers and ads?
                            2. How much faster would the website be if they replicated all of the functionality without frameworks and libraries? Is it enough to overcome the extra development time?
                            3. Do devs use frameworks and libraries purely because of convenience, or are there other business constraints? Time to market? Responsiveness? Portability?
                            4. Can the developers significantly improve performance without getting rid of the framework or library? Is the problem “they use a framework”, or “they haven’t had time to optimize their code, period”?
                            1. 2
                              1. Counter-question: have you ever in your life been employed to write client-side Javascript and the requirements didn’t list experience in one of JQuery, React, or Angular?
                              2. Given that the greatest bottleneck for webpages is bandwidth and that tree shaking can only do so much, significantly faster if you’re on even somewhat poor internet (most of the US is) or a slow, congested device (a lot of the world is).
                              3. This is a red herring because you’re assuming that because there are a multitude of justifications for development decisions that the developers making those decisions have no agency, which is absurd.
                              4. Tree shaking has been mentioned many times on the page, but the moment a developer uses a scroll-based effect JQuery plugin or starts requiring DOM to be rendered through complex javascript, they are not only doing so because the architecture of the framework has inspired them to do so, but because the design of those libraries tell developers they don’t have to understand what the framework is doing. The problem is multitudinous, just like the justifications that you think relieve the developers of their agency in their decisions.
                              1. 3

                                Counter-question: have you ever in your life been employed to write client-side Javascript and the requirements didn’t list experience in one of JQuery, React, or Angular?

                                Not the person you were asking, but yes, I have. Back when we called this stuff “DHTML”, and lamented that too many people copy/pasted snippets of JavaScript without understanding what they did.

                                because the design of those libraries tell developers they don’t have to understand what the framework is doing

                                There is no “bare metal” anymore. There is nobody who genuinely understands the entire stack anymore, and probably only a handful of people who even understand any single layer of it.

                                Once, nearly two decades ago, I used to think I did, but even then it turned out I really didn’t. Everything from the JS library/framework to the language runtime to the browser itself to the operating system to the CPU it’s running on is full of too much deep magic for any one person to understand even with a lifetime to study it all. We are at the “if you want to make a pie from scratch, first you have to create the universe” stage.

                                1. 1

                                  I mean, I wouldn’t equate the need for web developers to at the very least know the actual Javascript DOM API’s to a fancy for trying to understand “the entire stack” down to bare metal.

                      2. 11

                        I’m not dismissing them because they posted on medium! I’m not dismissing them because they complained about web performance on medium. I’m dismissing them because they say web devs are “an army of McDonalds line order cooks who fancy themselves as Michelin star chefs” on medium. If you’re going to be that contemptuous of web devs, you should at least show an iota of self-awareness about where you’re posting.

                        1. 12

                          1.2 MB transferred, 16.84s. That’s with an adblocker.

                          No, they are not allowed to complain. A blog post this length easily fits in 200kb, with the worst CSS framework imaginable included, 10kb would probabaly be possible.

                          1. 12

                            They can complain all they like. I agree completely that Medium is a technologically subpar and gluttonous medium, but there are clearly non-technical reasons to use it, which (as evidenced) many people feel outweigh its shortcomings.

                          2. 4

                            I think it’s a form of whataboutism. Everyone lives in a glass house, so everyone should shut up and stop complaining, I guess.

                            It’s a really cheap put-down, and I’m with you that it’s a ridiculous dismissal.

                            1. 1

                              There are many that do not like medium. To read content posted on medium I use a proxy that will leave only the content. Application is a of 10 minutes effort and the result is good enough - https://github.com/husio/readium

                              Deploy your own instance or use https://readium-demo.herokuapp.com/@CM30/putting-devs-before-users-how-frameworks-destroyed-web-performance-6b2c2a506aab

                              1. 2

                                I think you’re correct to notice the mismatch in the medium and the message, but perhaps the channel was chosen specifically because the folks who may benefit most from the advice would read it on Medium instead of elsewhere.

                                1. 6

                                  If they were choosing Medium specifically for that reason, they should have used Medium as an example. There was an essay a while back that did that: it said “you have to read this on Medium” and timed the complaints about medium’s UX to the exact points those UX problems manifested. Anybody else know what I’m talking about? I’m having trouble tracking it down.

                                  1. 2

                                    That sounds like a slick way of making a point!

                                    1. 2

                                      Found it! https://lobste.rs/s/bn30zs/medium_is_poor_choice_for_blogging#c_udeux9

                                      Turns out we both commented on it, haha

                              2. 5

                                I am not sure why third party components (as opposed to “from scratch”) are blamed for page size. Isn’t the problem tree shaking? Using a big library for a single function is absolutely fine, there is no technical reason that should increase page size.

                                1. 1

                                  Not sure I understand your argument. Big libraries (presumably in javascript) require downloading said libraries. Each of which can be hundreds or thousands of KB.

                                  1. 5

                                    JavaScript has a build system so that only required parts are included in the final download. That is called tree shaking.

                                    In other words, the right reaction is “let’s fix bugs in tree shaking”, not “let’s all reinvent wheels from scratch”. The latter will be a disaster.

                                    1. 8

                                      Javascript has a build system

                                      There are tools devs can use to shake these trees, but this doesn’t happen on it’s own.

                                      1. 1

                                        Thanks for the explanation, I didn’t know that was a thing.

                                  2. 4

                                    It’s true that the end user should be given due attention (UX), but fiddling with the “developer (un)happiness” slider doesn’t seem to me to be the right approach. Why not both-and? You could argue that increased developer happiness could lead to tighter development iterations/cycles, which would lead to better UX sooner.

                                    1. 2

                                      The fact that my node_modules folder is > 100MB in size and my rendered assets are less than 80KB per page seems to render this rant moot.

                                      1. 7

                                        Your particular circumstance is not representative of the wider community and ecosystem.

                                        1. 2

                                          My point being that with adequate tree shaking the framework used shouldn’t matter as the “compiled” assets should only be big enough to contain functionality that is used. The problem I often see is websites loading MB of assets to only use a tiny percentage of it overall which to be fair to the author of this piece seems to largely be the point they are getting at.

                                          In reflection calling it a rant feels dismissive, that was not my intent; its a well written article on an important subject that more of us should pay attention to.

                                          1. 6

                                            I think this depends a little on defaults and how much effort it is to achieve this. If 90% of the people are “using it wrong” as you say, I’d still say it’s the framework’s fault for having bad defaults or bad docs.

                                            1. 5

                                              The point is dev fun and user performance is not opposed. Let’s improve tree shaking, so that devs can continue to use fun frameworks and users can get fast web performance.

                                              1. 2

                                                Although in this case people who use/like medium may make the point that it’s also optimized for author fun in writing and publishing, to the detriment of the readers ;)

                                        2. 5

                                          I don’t particularly enjoy having to pull down 100MB of failes in order to generate 80kb, especially when that infrastructure results in loss of time, generation of waste, and damage to the climate.

                                          Additionally, it’s remarkably hard to secure such a situation.

                                          1. 1

                                            I feel totally uncomfortable with it as well, it’s incredibly wasteful, but people don’t give it a second thought, brushing it off with ‘but hard drive sizes these days’. I just want to add a testing framework (though the same applies to many popular libraries/frameworks) to my project and I end up pulling in 300 dependencies weighing in the hundreds of megabytes (how???). There’s something very wrong with this ecosystem. I guess it is not so far removed from our attitudes towards disposable, single-use plastics and other forms of waste.

                                          2. 3

                                            If that 80k does computationally slow things, then the end result is still going to be, well, slow.

                                            1. 2

                                              From GitLab:

                                              $ du -hs node_modules
                                              689M
                                              $ du -hs public/assets
                                              109M
                                              

                                              Loading https://gitlab.com/gitlab-org/gitlab results in 1.51 MB of assets being downloaded. Without caches that becomes 4.44 MB.

                                              Mind you that this includes images, but the point is the same: the output size will vary greatly per project, but there definitely is a trend of websites becoming more heavy every year.

                                            2. 1

                                              The real problem is the laziness that becomes easier to achieve with a framework that – more likely than not – provides more functionality than you need. That doesn’t mean that modern frameworks are inherently bad, it just means you will probably have to spend more time optimizing than if you had written everything from scratch for a hyper specific use case.

                                              In an environment where pragmatism is valued, web frameworks really shine. You will probably have to do some post-optimizations though.