0

We want to be able to implement cross-browser compatibility by overriding markup, scripts and styles only where necessary. We want to avoid forking everything sent to the browser, as has been done in the past!

This has led me to a directory structure with one folder per "page", with "master" markup, script and style files, and their respective overrides, one per browser. The file names, both master and overrides, would be the same from folder to folder, and the code linking them all together can be shared (all the relevant resources can be pulled in with relative urls). 

MyPage(folder)
|--Index.aspx
|--Markup.xsl
|--Markup_ie11.xsl
|--Scripts.js
|--Scripts_ie11.js
|--Styles.css
|--Styles_ie11.js
AnotherPage
|--Index.aspx
|--Markup.xsl
|--Markup_ie11.xsl
|--Scripts.js
|--Scripts_ie11.js
|--Styles.css
|--Styles_ie11.js

I have a test project with all this working nicely, but I'm very nervous about so many same-named files, and the file name on its own giving no clue to it's purpose. Nevertheless, compared to our old organisation based on filetype, some advantages jump out: the files you're likely to work on together are stored together. The folder tree is flat. The folder names are much more meaningful, and I have less need to search. There are 1/8th the number of hardcoded paths in the application (scripts, styles and markup are pulled in with relative links).

Can anyone think of a reason not to do this ???

Improve this question
4
  • 1
    Can't you use toolkits like Jquery claiming to deal with browser compatibility?
    – Basile Starynkevitch
    Commented Jul 22, 2015 at 15:29
  • Our team has tried, then dropped, jquery, after version changes broke some stuff. My proposed folder layout keeps most of the same advantages, whether or not you need browser-specific overrides. And I've the impression there's always something. IE11 doesn't support the HTML5 date input, so if you want to use it where it's available, and cover for it when it isn't, straight away you need IE specific markup and scripts.
    – bbsimonbb
    Commented Jul 22, 2015 at 15:38
  • Fnd out why they dropped jQuery becuase often its "because we didn't make it" (which will be couched in terms of 'not being good enough' or similar). Sometimes its simply because they didn't spend enough time learning it because they didn't want to, because NIH. Any issues with jQuery can be fixed.. and submitted to the jQuery team.
    – gbjbaanb
    Commented Jul 22, 2015 at 15:42
  • You're right, we are incredibly reluctant to bring in dependencies of any kind. I've the feeling there are others we miss more cruelly than jquery, but it's not a fight I'm going to win today. Could you please focus on the folder structure aspect, which is independent of jqery and browser compatibility?
    – bbsimonbb
    Commented Jul 22, 2015 at 15:52

1 Answer 1

Reset to default
1

Can anyone think of a reason not to do this ?

Some very, very big ones: For one thing, browsers will not be able to effectively cache all of these files if your pages don't reference them at the same absolute URI.

That is to say, if you have:

page1/
  index.htm  -- references script.js as "/page1/script.js"
  script.js
page2/
  index.htm  -- references script.js as "script.js"
  script.js

... both .htm files refer only to their local copies of script.js, and you now have the problem that anyone coming to the site will have to download separate copies of each script.js for each page they visit.

This will cost you more bandwidth, and it will fill the users' browser cache and push other things out.

But it gets worse.

Now, you're maintaining multiple copies of the same script in multiple locations. This has cognitive and technical overhead: If someone new is hired, they're not going to realize that each separate copy of the script needs to be updated when changes are made, and you're going to have a ballooning number of copies of the script in your source code repository, which will only grow into a mess as time goes on.

This is a dozen kinds of bad idea.

It's also a bad idea to maintain completely separate scripts for multiple major browsers. This spreads your code out and increases the cost of maintenance, not to mention the added bandwidth cost of having lots of large files to send to browsers (which will cause you grief if you use a local server cache). Instead, you should abstract all of your browser-specific code into a single file (or a number of very small files, each for a given logical unit of code) where the specific code that handles browser differences is close to the code they need to execute.

This is how literally every JavaScript and CSS framework is written, and for good reason: It minimizes code size, and it simplifies maintenance, both of which save you money in the long run.

Any other approach is wrong.

Improve this answer
4
  • It could be that my idea is bad, but it's very different from what you describe. Page1/script.js contains only functions relevant to page 1. Page1/script_ie11.js contains only the subset of those functions that I need to override for browser compatibility, and will be a very small file, specific to a logical unit of code, much like what you suggest. I do in fact also have a common folder, with the same idea - scripts, styles and markup together in one place, that I can call from anywhere. You remind me that mixing filetypes in a folder will complicate setting the cache policy by filetype?
    – bbsimonbb
    Commented Jul 23, 2015 at 7:09
  • Can I be more clear? My same-named files have completely different contents. It's the path (and the filetype) that gives the clue to the content, not the filename. One idea was to make all the filenames underscores !
    – bbsimonbb
    Commented Jul 23, 2015 at 7:46
  • If each page's JavaScript file contains only the small amount of specific code relevant to the page, then there's no reason to have it outside the page itself (or, it could even be included inline in the common JavaScript files), and so the file need not exist at all. The same for browser-specific code and page-specific CSS. Each additional file you send imposes additional bandwidth overhead for the HTTP request/response and TCP packet overhead, and it's yet more stuff that clogs caches. My point stands.
    – greyfade
    Commented Jul 23, 2015 at 15:40
  • Great then. I'll put everything in one file, then I can just use ifs everywhere when I need browser specific code, and all my functions will automatically be available everywhere. Much simpler, thank you.
    – bbsimonbb
    Commented Jul 24, 2015 at 8:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.