5 ms·

I like how most people blame bosses or scary big companies. No developers appear willing to admit that there is a large cohort of not that great web programmer

• dennis_jeeves2 3y ago
  >I like how most people blame bosses or scary big companies. It ALWAYS starts at the top, no matter how you slice it. Why are the incompetent devs there in the first place?
• niels_bom 3y ago
  It might also be people not willing to admit that they don’t know how to optimize website performance. And if you have a somewhat complex web app it can be complicated, especially if your stack doesn’t help you (looking at you React).
• dijit 3y ago
  "it's better for the company that I don't try, my time is expensive and any minute not spent on a feature is a waste of my salary" - is a common justification that I hear all too often.
  • autoexec 3y ago
    "It's better for the company that I don't try" seems like a convenient take for a dev without the skills to have. I'd argue that performance is a feature, and if someone can't deliver it their salary is being wasted already.
    • TheAceOfHearts 3y ago
      Performance is a feature and management often doesn't care to optimize for it. If the market valued performance more then we would probably see competitive services which optimize for performance, but we generally don't. I'm sure there's plenty of developers that could deliver improved performance, it's just a matter of tradeoffs. Maybe the people who care this much about performance should start competing services or a consulting firm which optimizes for that. Better yet, they could devote their efforts to helping create educational content and improved frameworks or tooling which yields more performant apps.
      • jamil7 3y ago
        > If the market valued performance more then we would probably see competitive services which optimize for performance, but we generally don't. I believe there is some nuance to this due to the winner-takes-all nature of modern software services. There simply isn't a lot of choice for users or switching is expensive so companies don't do it and employees are forced to suffer through horrible performance.
        • BehindBlueEyes 3y ago
          Or switching happens for 90% of the feature and is called good enough, which results in now having 2 systems to maintain because the old deprecated one actually still has critical edge cases depending on it…
      • zelphirkalt 3y ago
        One issue is, that the caring about performance is often not visible. How does management accout for or measure how annoyed people get visiting their bloated websites? How many people do not know better, how fast and snappy a not bloated website can be, because they apend all their time on Instagram, FB, and co? Even if a company does measure it somehow via some kind of truly well executed A/B test, other explanations might be reached for, to explain why a user left the website, than the performance.
        • orangevelcro 3y ago
          Isn't that what the tracking stuff is supposed to track? Measure things like how 'annoyed' people get by bounce rate and whatever other relevant metrics.
          • zelphirkalt 3y ago
            Yes, but how do you determin the actual reason for a bounce? The test would need to have all the same starting conditions and then let some users have a better performing version or something like that. But at that point one would probably rollout the better performing version anyway. Maybe artificially worsen the performance and observe how the metrics change. And then it is questionable, whether the same amount by which performance decreased would have the same effect in reverse, if the performance increased by that amount. Maybe up to a certain point? In general probably not. In general it is difficult, because changing things to perform better is usually accompanied by visual and functionality changes as well.
• bezbac 3y ago
  That's not fair. Sure, if there's an experienced dev who _values_ efficiency on the team, who pushes for the site to be more efficient or builds it more efficiently to begin with, the page would be better off. But it's mostly about incentives. If management doesn't care, they will likely not react well to programmers spending time making the site more efficient instead of spending half the time to just get it running and then crunching through their backlog.
  • zilti 3y ago
    It usually requires less time, not more, to create a slim and efficient page.
    • actuallyalys 3y ago
      It's very situational. If you're talking about writing a static site generator or handcoding a web page, that's mostly true, although if you're trying to not just be efficient, but as efficient as possible, things like optimizing assets are a small but additional step. If you're maintaining a web app over a period of years, it takes at least some effort and time to keep it slim and efficient because small inefficiencies here and there start to accumulate and these tend to be more demanding even in the best case. There are some antifeatures that Dan Luu identifies, like dynamically unloading content, that probably take a considerable amount of time to implement while degrading both the user experience and efficiency, but I doubt avoiding those is enough to ensure good performance on more complicated projects.
    • rizky05 3y ago
      but can it do feature x that generates more $$$ ?
    • rokkamokka 3y ago
      Definitely not true in my experience, and I would think if it were true, most pages would be "slim and efficient". Where is the business value in doing anything else at that point?
      • 3y ago
• john61 3y ago
  Usually bad web software correlates with bad content. Therefore having a slow device is an excellent filter helping to avoid garbage.
  • teamonkey 3y ago
    Unfortunately the modern web has consolidated to a point where you need to use them. For example, small local businesses that don’t have a web site but do have a Facebook page.
    • geraldhh 3y ago
      seems fair to correlate "small local businesses that don’t have a web site but do have a Facebook page" with "bad content"
      • teamonkey 3y ago
        My local butcher provides good content without being terminally online. Unfortunately this means needing to use Facebook to find out if they’re open on a national holiday.
        • geraldhh 3y ago
          idk if "only facebook" is worse than no online presence at all
    • john61 3y ago
      Having only a facebook page and forcing people on that toxic platform, is a strong indication that they do not value freedom (of the web) and ethics. Again a good filter for business / people I want to avoid.
      • BehindBlueEyes 3y ago
        I don’t think lack of technical skill implies not valuing freedom. There isn’t really alternatives that are as easy to use and have their clients already on it. They are as much a captive audience as anyone else.
• tdudhhu 3y ago
  You are right. I browse the web on Firefox with uBlock Origin, 3rd party cookies disabled, and so on. So I am missing the bloat most people talk about. But still apps like Clickup are really slow. It's just bad software.
• ksec 3y ago
  Probably a bit of both. Client Side Rendering ( Regardless of Frameworks ) is hip, and gets more media attention. Sometimes backed by VC. It is new, it is complex. And fits both the hype cycle, software engineers complexity attraction, and Resume Driven Development model. And just like the article stated, it is suppose to bring so many good things in its idealogy to the table. Since majority of software developers wants to works on it, so their Resume gets a tick and could jump to another job later. Management now faces lots of application for these technology and zero for old and boring tech. >great web programmers who don’t know much (and appear to not WANT to know much) about efficiency. Remember when Firefox OS developers thought $35 dollar Smartphone will one day take over the world and CPU will be so much faster due to Moore's law, performance will soon becomes irrelevant. I mean that is like Jeff hates Qualcomm, without actually understanding anything about Mobile SoC business nor the CPU behind it. And how ARM's IP works. A lot of people dont want to know "why" either. A more accurate description and also a general observation. Most software developers and especially those on Web Development have very little understanding of hardware or low level Software engineering. Cloud Computing makes this even more abstracted.
• atoav 3y ago
  I have worked with such people. When I asked them specifics about the "result" (HTML, CSS, JS) they looked at me as if I was talking another language. They came from javascript framework world, and there they didn't really think all that much about that. My philosophy is nearly completely different, I ask myself what the minimum maintainable code is that would produce the equivalent of a well hand coded HTML+CSS+JS website. Usually the result is magnitudes smaller. One of those people asked me how I did realtime list filtering on 1000 table rows and still have it load fast ans perform well on mobile. While that isn't really a feat, all I sid was deliver the whole data on the first request and then hide non-filtered data dynamically. That means the webserver didn't have to do anything wild, orher than deliver the same cached data to everybody who filters that list and because this was the only javascript going on on that site it was (to them) unusually performant. If you look at a comparable table row from their solution (some framework, didn't have much insight into it) the resulting html was 80% boilerplate that they didn't even use. Web development is too entrenched and many wandered too far from the essentials of web technology.
• arp242 3y ago
  About 5 years ago I applied for a job at a company that enabled people in rural Africa to more easily sell the goods they produced (farmers, basket weavers, what-have-you). If you mainly target people in the US or EU, there's perhaps something to be said for not optimizing too aggressively for low-end hardware and flaky low-bandwidth high-latency connections. But if you're targetting rural Africa fairly aggressive optimisation seems like a no-brainer, right? Their homepage loaded this 2M gazillion by gazillion pixel image downscaled to 500 by 1000 pixels with CSS. It got worse from there. I don't recall the exact JS payload size, but it was multi-MB – everything was extremely frontend-heavy, which was double ridiculous because it was mostly a "classic" template-driven backend app from what I could see. I still applied because I liked the concept but the tech was just horrible. I don't really know why it was like this as I never got to the first interview stage, but it's hard to image it's anything other than western European developers not quite realizing what they're doing in this regard.
  • carlosjobim 3y ago
    The website was never intended for people in rural Africa, it was intended for donors and governments in Western countries, so that the company could get juicy grant money and pay themselves to pretend to empower African farmers.
    • janice1999 3y ago
      Believe it or not people outside the US actually buy and sell things too! Africa is a primarily mobile first continent with the fastest growing mobile infrastructure and 100 million new handsets sold a year (and that is predicted to double by 2025).
      • carlosjobim 3y ago
        You better believe that I believe it. However, if they were actually trying to get rural people with bad internet connections as customers, they would make a website that was fast and efficient.
• 5350-uiop-1130 3y ago
  we need some html tag or attribute for slow network detection. instead of this nasty js feature detection that 99% of time no one does. prefers reduce motion was a good start. although its rarely respected.
  • aembleton 3y ago
    Should be easy enough for the server to detect when the connection is slow. That could be done now without having to update the clients and give them more things to process.
• keybored 3y ago
  The whole point of hierarchical organizations is that those higher up have more influence than those at the lower tiers. Cutting the blame in half doesn’t make sense.
• _fat_santa 3y ago
  Having worked with the "big scary companies", I can say they are 100% to blame. It doesn't start with the developers but rather the budget. Unless folks at the top are tech savvy and/or have an engineering background, they typically only budget for new features and either under-budget or don't budget for maintenance and tech debt removal. And when they do budget for maintenance, it's handled almost exclusively by "maintenance teams" that are offshore and cheaper. So you have a feature team that works on a feature for 6 months, does a 1 hour "KT Session" with the offshore maintenance team and hands them the code. The offshore team has some information on the feature but not enough to really manage existing tech debt, just to keep the lights on. And on top of this they know they are the lowest totem on the pole and don't want to get fired so they don't go out of their way to try and fix any existing code or optimize it, again just enough to keep the thing working. Then this cycle repeats 100-1000x within an org and pretty soon you have a scenario where the frontend has 2M lines of code when it really should be 250k max. A new feature team might come on with the brightest engineers and the best of intentions, but now they have to work within the box that was setup for them. Say they have a number of elements that don't line up with their feature mockups. The mockups might be incorrect, there might have been an upgrade to the UI kit, or the existing UI kit might need refactoring. Problem is none of that is budgeted for so the team is told to just copy the components and modify them for their own use. And of course on handoff to maintenance team, the new team does not want to mess with the existing feature work so they leave it as is. Management is non-technical so they don't know the difference, and you end up with 50+ components all called "Button" in your codebase from years and years of teams constantly copy/pasting to accommodate their new feature.
• p_l 3y ago
  People who never worked with some of the bloated sites often forgot third party in the bloating. Marketing team mandating inclusion of at least one "Tag Manager" (if they are especially bad, there will be multiple). A "Tag Manager" is a piece of JS that is installed together with an API key in the site... and then it downloads whatever extra JS that was configured for given API key. The actual site developer often has absolutely no control over it (the closest I got once was PoC-of-PoC where we tried to put even inclusion of tag manager behind an actually GDPR-compliant consent screen). Marketing team gets to add "tags" (read, tracking, chat overlays, subscription naggers, whatever), sometimes with extra rules (that also take time processing!), all without involving the development team behind the site.
  • andai 3y ago
    So marketing department is responsible for web being such a sad and painful experience?
    • geraldhh 3y ago
      money is the top reason for ppl doing stupid shit, yes
    • p_l 3y ago
      Not the only department. But consider how much of the bloated JS tends to be from external parties, and pretty much everything that isn't CDN-ed frameworks will be stuff either required by marketing, or flat out added through the use of a tag manager.
  • youngtaff 3y ago
    Blaming tag managers and marketing departments is quite common and yes while they are problems on some sites many developers overlook the impact of their technology choices e.g. client side rendering, JS based components etc
    • p_l 3y ago
      There's a reason why I speak of "third party", though I guess it might be unclear in english - my bad. There are three parties involved in the bloating. Management prioritising certain things is one. Developers (including here both programmers and designers and others etc.) not caring enough or otherwise making choices that lead to bloat is second. Marketing team with power to require problematic things added or just going crazy with tag manager is third. All three are involved in the "bloating crisis".
• titzer 3y ago
  Is it really hard to believe that the solutions on offer are usually giant piles of steaming crap that do way more than they should but are nevertheless easy to get set up and get going? When programming ecosystems get big, they accumulate a ton of ways of doing things and people keep trying to put a layer on top on top of a layer on top of a layer (like floors in an old house). It doesn't matter if a thing underneath is O(n); someone will put another O(n) thing on top of that that represents all its data as strings and uses regex or horribly-inefficient JSON or something. Very few people ever think things from the ground up.
• _gabe_ 3y ago
  > there is a large cohort of not that great web programmers who don’t know much I think you mean “programmers” not just “web programmers”. I’ve worked with plenty of bloated over-engineered Java and C# codebases that take several minutes to start on a very fast developer machine with 32 gigs of RAM. Sometimes, the worst offenders use “lower level” languages! The performance averse problem is endemic in the entire field, not just in the web.