I have a lot of legacy CSS files from what was a Rails 2.x app that got upgraded to Rails 3.2.8, and I want to switch over to using the Rails asset pipeline for stylesheets. The issue is, the CSS stuff is messy in terms of huge lines of code, duplicate file names, and unorganized folder structure.
After looking through individual pages, and trying to add individual stylesheets and folders into the asset pipeline and spending some cycles debugging, I realized there's probably a better approach.
Is there a way to test to make sure the old CSS matches up with the asset pipeline CSS? What are some good tools for testing and debugging CSS?
that is actually a pretty good question. i just know of one tool called wraith that takes screenshots of your page and compares diffs them. that allows for regression testing of your design. you will need to have a test for every page though.
if you look into your browser you also have the possibility to see which css selectors are not used. you could start by deleting the styles that are not used throughout your page.
i think that you will have to take the bitter pill and refactor your css bit by bit. sass and scss might help you with that.
at some point it might be better to start of with a clean slate though. just start with one page and create the css from scratch. at least you know how it has to look like...
I'm in a similar situation with a large legacy application. While I haven't made the transtion yet, here are the steps I'm anticipating:
Upgrade to latest Rails 3.2.x with asset pipeline disabled (done but still testing now)
Upgrade to latest Rails 4.x (because asset pipeline changed between versions)
Divide my css pages between those that apply to every page, and those that are page specific. For the asset pipeline, include ONLY those that apply to every page, and activate the pipeline.
Over time, rewrite the CSS so that page specific rules can be included in the global rules, until everything is in the first category.
I'm seeing advantages in upgrading to rails 3.2 that have nothing to do with the asset pipeline, so that's a win. I have a number of CSS and JS files that do (or could) get loaded on every page without conflicts, so getting to that stage should be some improvement. Transitioning the remaining stylesheets can be done over time and hopefully in a safe way.
Hope this helps. I look forward to seeing any other answers from people that have made this sort of transition on a less-than-trivial web application.
Related
The end result of what I'm trying to achieve is rather than having a single applications.css file, I want to split it into two sections -- a section I'm going to inline into the <head> tag, and then everything else. The reasoning behind this is that we want to inline the portion of our CSS that applies to above-the-fold elements of the page.
What I'm wondering is if there's a way to leverage the asset pipeline to remove the portion of the CSS that's inlined from the application.css file?
I feel like this is one of those problems where the way I'm thinking about the problem may be the biggest blocker, so totally open to alternative ways to think about this (i.e. not using the asset pipeline).
Just to make the problem more interesting, ideally I'd like a way to do this that's independent of the project itself, because there are multiple Rails front-ends where I'll need to apply this technique.
NOTE: Determining which part of the CSS I want to inline is not the problem -- that I have solved. What I'm looking for is a way to, as we continue to update our CSS in the future, make generating the two parts of the CSS a simple rake task, or integrated into the asset pipeline so it's done on deploy, etc.
Seems like the most straightforward way of doing this, if we assume that the asset pipeline (a.k.a. sprockets) is the right approach, is extending sprockets via an exporter -- the thing that actually writes assets to disk.
Update: I've instead looked at css-purge as an off-the-shelf solution for identifying which CSS is used on a given page. Having this as a separate tool that doesn't care that a given page was generated via a Rails app helps make it more useful.
I'm thinking about changing the processCSS gulp task that Aurelia CLI creates to create physical css files, instead of including it directly in the app-bundle.
Are there any major drawbacks within the Aurelia framework to doing this?
I'm more comfortable with separate css files after preprocessing, but I don't want to do it if I'd be missing out on some performance benefits, or create other troubles down the road.
I don't think there's any major drawback that can't be reasonably overcome. However, I would try to evaluate the benefit of doing it your way, instead of bundling it together.
I'll list a couple of points I can think of, in no particular order.
It can be challenging to get the modules and paths set up correctly if you are requiring CSS from standalone CSS modules. If you are using plain CSS files, then you will need to included and maintain the Link tags in your host HTML page. All this is easier if the CSS is bundled directly into the app bundle. Especially when adding more CSS due to 3rd party libraries etc.
if you are using the organizational pattern where you create css-per-component instead of having one monolithic CSS file, then there are potential performance impacts to making http requests for each individual css file, although the impact is probably more thoeretical than practical.
when deploying, it is really nice to just deploy a minimum number of files.
when all css is bundled, you can add comments at top of each CSS source file to help identify the source file when looking at the CSS in the browser inspector.
One last thing, it may be worth your time to experiment loading the CSS in different ways, including as individual files and see which way works best for your environment.
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'm developing a web app using python and twitter-bootstrap, and my CSS would really benefit from using LESS in order to generate my styles and themes. I want to inherit from classes provided by bootstrap, which means I've got to get the bootstrap source, and compile my LESS stylesheets against the boostrap .less files.
My question is two-fold:
1) The simplest way it seems to use LESS is not to actually compile stylesheets "on-the-fly" but to have a build step that I run each time I make changes to the styles. Is this typical? It seems like a lot of people run LESS dynamically in their server process, but it's an extra headache that I probably don't need, and I don't want to run less on the client side.
2) Thanks to LESS, my project now depends not just on bootstrap, but the bootstrap "source" - What's the best way to handle this in terms of my project management? I don't want to just absorb the whole of whatever the current version of bootstrap is into my git repos, because it seems like it would be a hassle to update it as newer versions of bootstrap come out (also feels icky!) Still though, I need to have at least the minified js/css in my project tree in order to deploy my app. How do people typically handle dependencies like this when developing web apps?
There are a couple of shoices:
You could use less.js in development, so you don't have to
compile each time you change your less code. You just use *.less files instead of *.css
You could use any of the GUI tools that will automatically recompile less code. I prefer LESS.app.
I use git submodule
I would have linked you to the same post as Pavlo above. Maybe there is no best CLEAN practice for this? Neither there is any magic "package manager" i think.
I went updates BS once and it was a bit of a hassle to find out all the variable names that have been changed in the LESS files.
What are the best ways to use LESS for CSS.
Basically should the Devs write a Less File and then have it compile for production
Should I link the LESS code and the javascript file.
Or should I skip the LESS rout altogether and just remake the classes
I am trying to wrangle together some rather sloppy css and want to get control of it before making major improvements. I think it would be very good to have site wide variable so Less seems like a good thing with the variables and nesting.
I am replacing a lot of the background images with css gradients and box shadows so I am also trying to get rid of the vendor prefixes.
Sometimes I see what kindof looks like class overload but is it bad to append a lot of classes to an element such as
<div class="comment dark-shadow round-corners"></div>
Less is a great styling language. I use it extensively, and it really helps with code maintainability, as well as with speed of writing the styles.
I personally feel that your styles should not be dependent on javascript to render, so I use the less.app to compile all my LESS into CSS. I rest more peacefully knowing that all my CSS is there and that it works correctly before I put anything "live".
If you are interested I have also been compiling a LESS mixin library that can be very useful: https://github.com/jdmiller82/-lessins-
I agree with Jonathan, I don't think you should depend on the users browser to render the styles.
I came up with a solution that uses node.js on the server to intercept requests like styles.css and try to find the equivalent .less file (in this case styles.less) and parse it and return it as CSS.
So on your server you would just have styles.less but you could request the URL example.com/styles.css and get the parsed LESS file. That way the integration is seamless for the rest of your application and it doesn't require the user has JavaScript enabled either.
You don't have to be using node.js for the rest of your app either. I did this in a PHP application.
You can read my tutorial here: http://programming-perils.com/155/parse-less-files-on-the-fly-and-serve-them-as-css/
I realize this answer is about two years later than the above ones but I think the question is still relevant.
I think there are use cases where compiling some LESS client side is a good idea (provided you aren't supporting IE 8 or below) and you have a use case that validates it. For example, an application I've worked on recently has a customizable, theme-able interface where text colors, etc need to be modified based on whether the background color they're on is light or dark and may eventually need to support the ability for the user to change them and see those changes reflected on the site in realtime. This is a great use case for client side LESS I think. Note that only a small LESS stylesheet is compiled and the rest of the application LESS that's not related to theming is precompiled. I haven't seen much of a perceived difference in performance.
So when you see comments like "you don't seriously think any decent developer uses less clientside do you?", I'd take them with a grain of salt.
The way to use LESS for a production website is to compile LESS files into CSS files.
For local development you can have a file-watcher that rebuilds the CSS files for LESS files that were changed.
If you have multiple CSS files to produce from LESS, you should separate them out.
For example, if you have 30 less files and they produce two CSS files a.css and b.css, you will want to separate those two jobs so that you can compile faster. It's faster for developing because you will only compile a.css if you change any LESS files that affect it.