I had an idea for "cheap" version control of the css of one of my sites, but am thinking it may not be a good idea. Thought I'd throw it out here in case someone has a similar idea that works better (besides real svn, etc.)
My thought was to create a main css file like "sitename.css" then use #import inside this file to connect to the most recent file with updates. I'd name these imported files by date, eg: 20101222_css.css so I'd know when the last update was applied. When I have a change, I could make my edits, drop the update in the respective location, change the #import to the new file, and viola... updated on the site.
After reading about issues with #import, such as it loading AFTER the page finishes, I'm not too keen on this now.
Any ideas of a way to implement something similar without a full blown system? I do a lot of small project work for various people and thought this method may be a simple way to keep track of things.
Thanks for any ideas/suggestions.
Your idea would add additional page loads to your site for no good reason, which will be a performance hit. It would also expose your versioning to the outside world. And as you say it will suffer from slow loading speeds due to the way #import works.
But the real down-side of this technique is that it only works for CSS files. You haven't solved the problem for any other files on your site.
You seem to think it would be simpler to use than a real SVN setup, but if you end up coming up with different techniques like this for every type of file on your site, you could easily end up giving yourself more headaches than you solve.
SVN is actually quite straightforward to use. With a good GUI (try TortoiseSVN), it's so easy you almost forget its there. Seriously, use SVN. There's no need to come up with 'clever' alternatives.
Its not a good idea, especially if you push this into production. If you want "cheap" version control, download VisualSVN. Its free.
The guys at Yahoo use a technique that reminds me of what you describe:
<link rel="stylesheet" type="text/css" href="http://l.yimg.com/a/combo?arc/yui/reset_2.6.7.css&arc/yui/fonts_2.6.4.css&[....]/subfooter_0.0.12.css" />
It makes sense for them because it's a caching tecnique. They set HTTP headers so stuff never expires: if you load the site one year later and you haven't removed your browser's cache, you shouldn't need to fetch again any of the files that haven't changed.
However, it's by no means a sensible version control system. You already have a good bunch of real version control systems out there!
Related
I've been trying to determine the reasoning behind what seems to have become the standard practice in Front End workflows of separating vendor JS & CSS from custom JS & CSS. I'm not sure what the benefits are over the disadvantage of an extra HTTP request, it would seem cleaner to just have a single CSS & JS file rather than having vendor.css, main.css & vendor.js, main.js.
Can anyone shed some light on this?
Vendor code typically changes less frequently than your application's code. Thus as you update your application, the vendor code can remain unchanged and cached in your user's browser.
In the scenario where vendor code is bundled with application code, the user has to download all of the vendor code every time you update the application.
The extra HTTP request from the separate vendor bundle is mitigated by the fact that the user will download less code on each application update.
I can think of two reasons.
Hosting vendor code separately from your code (e.g. Google Hosted Libraries)
Separation of concerns: the vendor code might be large and is updated independently of your custom code. Maintaining your code in a separate file avoids the need to put vendor code into your source control, makes it easier to navigate your code, makes it easy to upgrade to new vendor code since you know for certain the vendor code has not been tweaked.
Especially since you tagged the question with grunt, the end user might never see this change since you can merge vendor and user styles/scripts during the build.
However, if vendor code is large and changes infrequently, you do get a caching benefit from having a rarely changing, large vendor file accompanied by a small, fast changing custom code file. For large sites that do not use a CDN (hopefully, not yours), the impact can be noticeable.
Depending on your situation, this allows you to make your edits lower in the cascade so you can override vendor styles and behaviors without blowing away their code. This is helpful so that you always have a working version(vendor code) you can revert to. In situations like working with Wordpress, developing a child theme allows the parent theme to be updated without blowing away your customizations.
Various answers already addressed this but i'll make it very specific:
Vendor code might change more or less frequently than your code. If
vendor code changes more frequently, e.g. for bug fixes, you would
want to use the newer versions and have a better overall website.
If vendor code changes LESS frequently than your code, you may wish
to change your code w/o touching working stuff.
Vendor code is often hosted on CDNs, for example https://cdnjs.com/#q=ajax or
https://developers.google.com/speed/libraries/ These are FAST
loading. They also wont change, so the user can rely on cached
files and thus your website will load up faster.
It is generally better to make iterative changes to code. It is also easier to manage code, esp with source control when specific
things are changing. No need to swap large files when they have not
changed. Keeping things separate makes it easier to make
incremental changes, esp if the two things have different change
velocities.
I have a question about bundling. Think about a situation like this. Take jquery DataTables for example. It has few plugins that you can use as and when you need them. In some pages, just using the base script files will do the job. but in another page, I might need to use Fixed Header plugin, in another page I might need to use Fixed Header plugin as well as Table Tools plugin.
What is the best way to approach these kind of situations in bundling. Should I create just one bundle which include all of the script files (even the ones that I might not use in some pages but in others) or create bundles specifically to each page or is there a better way of doing this. I'd like to be able to do something like
Scripts.Render("~/bundles/datatables", "FixedHeader", "TableTools")
which will include the relevant files and minify them.
Any help really appreciated.
Thanks,
Amila
Part of this, no one can answer for you. Bundling is always a trade-off: you're reducing requests at the cost of a larger file that has to be downloaded. You'll personally have to weigh the additional weight added by those scripts in the initial request versus the time it will take to request them later.
As a general guideline, this will mostly be about your audience. Do you expect a high number of mobile users? At least in the U.S., mobile data is expensive and fairly limited (because of the outrageous cost, people try to choose the lowest data tiers possible). Forcing your mobile users to download a large JS file which includes code that may never be run, is a waste of their data. While, if your target will be desktop users, a big file is no problem and is in fact preferable, as there's no concerns typically over data usage and the page load times for other pages will be improved. Even with mobile, though, sometimes users prefer faster page loads over less data usage, so even that has to be judged.
That said, if you don't choose to bundle them all together from the start, you can actually create bundles on the fly.
#{ BundleTable.Bundles.Add(new ScriptBundle("~/bundles/onthefly").Include("~/Path/To/Some/Script.js")); }
And then, as usual:
#Scripts.Render("~/bundles/onthefly")
Please take a look at the Enfold project. It might be able to accomplish what you need.
Assuming you have the following views in the web project:
~/Views/Home/About.cshtml
~/Views/Home/Contact.cshtml
~/Views/Home/Index.cshtml
You can organize your Javascript files this way:
~/Scripts/Views/default.js
~/Scripts/Views/Home/default.js
~/Scripts/Views/Home/about.js
~/Scripts/Views/Home/contact.js
~/Scripts/Views/Home/index.js
With such a setup, the following bundles will be created:
~/bundles/home/about
~/scripts/views/default.js
~/scripts/views/home/default.js
~/scripts/views/home/about.js
~/bundles/home/contact
~/scripts/views/default.js
~/scripts/views/home/default.js
~/scripts/views/home/contact.js
~/bundles/home/index
~/scripts/views/default.js
~/scripts/views/home/default.js
~/scripts/views/home/index.js
I've built a complex site for a client, who wants this duplicated, and re-skinned, so it can be used for other means.
What is the best way of doing this? I'm concerned about copying every file as this means any bugs must be fixed twice, and any improvements must be implmented twice.
I'd look to refactor your code.
Move common functions into a library you can reference from both projects. As you mention that the new site is for a different purpose then you are likely to see divergence and you don't want to hamper yourself later, so extract the common parts and then modify copies (or if appropriate new files) of the remainder to complete your fork.
If you haven't applied good practice already then now is the time to do it and it'll make your work on both sites easier moving forward.
If all the functionality is the same and only the layout is different you could just create a new css file. 2 websites could have exactly the same code base but have different stylesheets and look completely different.
I think that using a version control system like subversion or preferably git, is a good way to duplicate your website. You will be able to track the changes that you make and revert to older versions if things do not work out.
You should implement some kind of instantiation, so look and feel, content and data will be shown depending of what instance of the application is accessed.
In other words, each application access to the code with a different application identifier, meaning content will be served depending on it.
Both application identifier will be pointing to different settings, so stylesheet and content will be absolutely isolated, and both domain will be living in the same IIS application.
If you want to duplicate a whole site it's probably best to copy the whole thing and amend as necessary. Obviously taking great care not to copy large portions of text or else you may be penalised by the search engines.
There are ways you could put the new site onto the same shared host (say within a subdirectory of the original site) and literally 'share' some files. If a unique change is required, you could instead reference a 'local' version of a particular file.
However that sounds like a recipe for a headache to me. I'd prefer to duplicate the whole site. It would be much easier to replace one or two functions on separate websites than it would to try and work out which website(s) are affected by a particular change to your source.
I just worked out, by trial-and-error, that IE 7 has an upper limit of 32 stylesheet includes (i.e. tags).
I'm working on the front-end of a very large website, in which we wish to break our CSS into as many separate files as we wish, since this makes developing and debugging much easier.
Performance isn't a concern, as we do compress all these files into a single package prior to deployment.
The problem is on the development side. How can we work with more than 32 stylesheets if IE 7 has an upper limit of 32?
Is there any means of hacking around this?
I'm trying to come up with solutions, but it seems that even if I loaded the stylesheets via Ajax, I'd still be writing out tags, which would still count towards the 32-stylesheet limit.
Is this the case? Am I stuck with the 32-file limit or is there a way around it?
NOTE: I'm asking for a client-side solution to this. Obviousy a server-side solution isn't necessary as we already have a compression system in place. I just don't want to have to do a re-compress every time I make one little CSS change that I want to test.
Don't support IE7.
To avoid confusion: I'm not seriously suggesting this as a real solution.
Create CSS files on the server side and merge all files that are needed for this certain page.
If you are using Apache or Lighttp consider using mod_concat
Write your stylesheet into an existing style block with JavaScript using the cssText property, like this:
document.styleSheets[0].cssText += ourCss;
More info here:
https://bushrobot.blogspot.com/2012/06/getting-around-31-stylesheet-limit-in.html
At my last company we solved this by mashing all the CSS into one big document and inserting a URL in the web page that referenced that one-shot document. This was all done on-the-fly, just before returning the page to the client (we had a bunch of stuff going on behind the scenes that generated dynamic CSS).
You might be able to get your web server to do something similar, depending on your setup, otherwise it sounds like you're stuck with only 32 files.
Or you could just not support IE7 ;)
Any time I need to write code I almost always put it in the code behind file. For some reason this has always seemed like the "right" way to write code.
Based on most of the examples I see online, a lot of other people choose to write code this way too, but it seems like putting your code in the aspx file allows you to do all the same stuff as well as offering a few advantages.
Top of the list being:
Easier to make changes since no
recompile.
You have access to all code if
you can't find the project in source
control (this recently happened to
me).
Is there any benefit to having code in a code behind file? Is there any disadvantage to putting code in your aspx file?
Separating the code from the markup results in much cleaner structure, especially for non-trivial pages.
This is one of the major benefits to ASP.Net over ASP Classic.
Easier to make changes since no
recompile.
Depends in what context, you can upload normal ASPX + ASPX.CS to the server and it will compile it for you on IIS.
I use this for my personal web site, I hate having to 'publish' the web site and then upload the files, sometimes on the server I need to make quick edits in Notepad, hence this approach is perfect.
I personally like the setup of keeping them separate.
PS. I use 'Web Sites' not 'Web Projects' which I believe has to be compiled before uploading to the server.
Maintainability. It allows the HTML part to be edited independently of the code, by and large.
When you have a very small project it is just a bad practice. They just tell you it's wrong, but it feels perfectly right.
You will hit the wall when you start working on big projects and especially when you will need to maintain them.
When your project gets big -the GUI part(the form) becomes smaller: one component here, this color there... not too complicated.
On the other hand, the logic part becomes a real pain... if I use a function in 20 pages will I change each replication of the function in each form? If they are almost identical, yet a bit different... how will I implement the solution?
OOP offers many design patterns so that your code will be as clean and efficient as possible... but you have to work with objects rather than a form.
A form is an object, yet it doesn't meet the OOP design patterns rules. And those rules are there to make your life easier.
I once had to maintain a huge system... and every change required changing many forms and testing many forms. After rebuilding the system it became a SMALL system and easy to maintain. It is easy to just build a form from scratch ignoring the entire system... but it's really hard to maintain this form.
Never think of the year you build the project, think of the 20 years you are going to maintain it.
Good luck
Asaf
Stumbled upon this link now searching for the real advantages of putting code in cb files, and to confirm SLaks' answer, see this link for those who still wondered. Really thought processing and speed could've been an advantage as well, but alas...