I really want to like linear-gradient, but the implementation (and absurd memory use) really soured me on it. While for the most part vendor prefixes are at fault for this, there are other issues.
Like it actually generating a full-size image of the area in memory instead of drawing "on the fly" -- as someone with a 2560x1440 display, let's just say a full-screen gradient is NOT a great performing element.
One of the big things I use instead of linear gradient is a inset box-shadow. You don't even need to state browser prefixes (unless you REALLY care about Safari), the syntax is always the same, and you can with some trickery make it look just as good if not better. The only real issue is that the largest value most browsers will let you set is 128px, anything more than that seems to be truncated down to that size.
If you look at my JS libraries new website:
http://www.elementalsjs.com/
It looks like a gradient, but notice the bit of white on each side? (which I actually like)
#pageHeader {
margin-bottom:0.5em;
border-bottom:1px solid #68A;
box-shadow:inset 0 1.5em 1em #FFF;
background:#CDE;
}
... and IMHO if legacy versions of IE and Safari don't get the effect, OH WELL. Is the page still reasonably attractive and useable? GOOD! Anything else? Well, people who can't join us in this century should be thankful we even bother making sure the page WORKS for them. Wasting bandwidth and developer time on tools that often make things worse -- like CSS3Pie -- is just a silly waste of time.
Though there's another option for when you need a large gradient so long as you are working horizontally or vertically: background-size.
You take the code output by your average online gradient maker, and how big is it? They usually start out around a half a K, and depending on the complexity can reach 2k or more by the time you have all the fallbacks, IE filters and other nonsense in place. Well... news flash, the LARGEST ANY gradient image as a PNG should ever reach is... 1.1k. No joke. In most cases it ends up a third of a K or less.
How? Simple, the most colors you could ever have in a 24 bit gradient image IF it's the same hue top to bottom is 256 colors. Make a 1024px tall blue fade to white, do a 'count colors' -- hey... less than or equal to 256 isn't it?
A 1x256 image, sufficient for MOST mono-hue gradients, is going to be smaller than the current linear-gradient code... even stranger it seems to render faster, and use less memory. you can also align the gradient to one edge, and continue the color from the other edge as your background, so that while it might not scale in legacy browsers, it at least still works.
Let's say you had a 1x256 gradient running from #88CCFF (top) to #4488FF (bottom) (actually you could get away with in that case a 1x70 image, say hello to a 198 byte .png)
background:#4488FF url(images/test.png) 0 0 no-repeat;
background-size:100% 100%;
Other than the extra file handshake, can be just as if not more effective than linear-gradient, particularly on mobile when it comes to memory and battery use.
The only time IMHO linear-gradient really shines is in diagonal gradients -- an image of sufficient size for those in most cases is way to big to even belong on a website in the first place, but given how badly they chew on memory as a linear-gradient, it's really not something I'd do except in the rarest of cases.
Still, it's another tool in the toolbox, as are the methods I just outlined. More tools you have, the less likely you are to try and hammer that square peg into the round hole... and that's a good thing all-around.
