69

Dear everyone who's not a front end dev.

Clear your fucking browser cache.

That is all.

Comments
  • 4
    Speaking of which: does the whole progressive web applications topic with service workers and stuff not have the potential for big security problems?
  • 21
    Dear front end developer, learn how cache works and how to set expiration’s correctly so I don’t need to disable cache.
  • 2
    Dear @COD4 I know how cache works tyvm. I can't set expiration on a Dev server. I'm ranting about other devs who don't know how cache works. Not clients.
  • 2
    @hashris how can you not set cache expiration up on a dev server?
  • 2
    @C0D4 I should've been clearer. The Dev server is actually a server on their own systems and the "devs" don't really know how cache works, so they call me over for every line of css they change that gets cached..

    A sensible person would just disable cache on the browser they work on.

    Our non local server is also a piece of crap from the 1990's tomcat 6, and for the love of everything holy I can't figure out how static file versioning works on it. And if I did, they wouldn't use it, because "devs" have to run their own server FML.
  • 0
    @chrishind10 Won't work if everyone runs a local server (^above comment) :/
  • 1
    @hashris
    That’s where you use something like

    .css?v=find-files-modified-date-from-server-side-dynamically

    Or output would be .css?v=2332525322

    That way all devs have no cache issues with these files, and the templates are dynamic, instead of static for the versioning so no conflicts in git.
  • 1
    @ribchinski
    Cache is basically just a local copy of assets (JS, css, images, ect) on your computer and accessing them as long as they haven’t changed, which makes repeat visits load quicker.

    However if these files need to be changed, and the browser doesn’t notice a change or the dev hasn’t added cache expiration’s or versioning then when those changes are made the repeat visitor won’t receive the latest copy of the assets.

    This can lead to some nuisance issues when changing JavaScript or Css files mostly.
  • 1
    @ribchinski you shouldn’t notice any ram difference really, you’ll just be downloading fresh copy of every file for every page you visit, so you may see some slower speeds overall if the sites you visit use a lot of assets.
  • 0
    @C0D4 I know how versioning works. But their server is local and their code is a fork. Thanks for the suggestion
  • 0
    @hashris
    I didn’t see this part, even after explaining it 🤔

    Does the code base use a back end language?

    If so can you look up the css / JS files modified dates? (Depends on language / environment ofcourse)

    If yes, then issue versioning as previously explained with the “modified date” being dynamically added from the backend.

    All devs will have a varied “modified date” but code base won’t actually be different and you would never deploy the static time stamp.

    Then in the HtML where the CSS / JS is loaded (hopefully 1 location)

    - - -
    Xyz.css?v=<?php echo fetchAssetModifiedDate(“xyz.css”); ?>
    - - -
    Then you need the function

    <?php
    Function fetchAssetModifiedDate($file){
    Return filectime($file);
    }
    ?>

    Purely example as I don’t know the languages being used.

    Now I’m not saying you don’t know what it is, but it feels like you don’t know how to implement it over multiple repos / severs in a dynamic way that won’t lead to conflicts later.
  • 0
    @C0D4 it's another project. They have a fork of my code. They run it on their own local machines. And they bitch about stuff not working because they formed my base.

    I run versioning on my nginx. I would love to ask them to setup a versioning system on their ducking tomcat 6 but I'm pretty sure if I give instructions they'd get confused and eat the computer.
Add Comment