What are CSS Shaders?
dstorey.tumblr.com
dstorey.tumblr.com
Developments like this along with the rise of WebGL would suggest we are going to be seeing a lot more shader files being served to browsers in the near future.
It's not about web development - developers will be fine. Actually, a few more things to learn for a common 'jQuery/CSS guy' could only be a good thing. My point is: without this simplicity the web could transform from being a fast and accessible source of information into heavy, bloated piece of multimedia provider which drains your batteries, CPUs usage and - foremostly - your patience. The ability to load a "Quake 3" level with a web browser is amazing but the internet made with websites that load some sort of "Quake 3" levels 90% of times is not a lovely perspective.
Well, I think I can sum up my "rant" saying it's another "books versus TV" type of conflict.
filter: is still used for the various PNG fixes out there.
This is going to cause endless issues and confusion and I just hope IE copes with a filter: it doesn't understand or we will be back to browser-sniffing and serving different markup to different browsers.
IE 10 will support filters in SVG [1], so IE should be able to cope with it ok.
[0] http://www.w3.org/TR/SVG10/filters.html#FilterProperty [1] http://msdn.microsoft.com/en-us/ie/hh440437
My thinking is that this is shoveling yet another spec that fellows like me have to learn and support.
For years, css2.1 wasn't quite enough to really do what we needed. To do even slightly advanced layouts we had to come up with all kinds of crazy html/css/image arrangements to do things. css3 was a welcome addition finally, especially as its widely supported in modern browsers now. It filled in many of the gaps that were missing.
css3 also added some interesting new features relating to animations. We got transitions, translations, animations, etc. The specs on these are fairly simple and really powerful once you learn them.
But unfortunately css isn't the only thing we have to know to do our jobs. We have to know html(5) layouts and rules. We have to know all of the in's and out's of how every popular browser implements the layout of html and css and all of their bugs. We've had to learn to use the newer html5 features, almost all of which were welcome. Even here though, we run into insanely stupid cross-platform issues like dealing with media formats for video and audio tags. Can you name support matrix of browsers for video and audio? I can, and it sucks that I had to learn that.
And lets also be honest, you can't truly be a well-rounded frontend engineer if you don't have at least a moderate amount of experience writing javascript. These days, you can't just get by only being the member of the team that lays out html & css. You need to be able to write javascript to make our increasingly interactive pages come alive.
Not only is javascript a lovely yet tricky language to learn, the bigger issue is dealing with the DOM api's for each and every interactive DOM element. And you have to know those DOM api's and how they differ for the most common browser platforms. Yeah, older versions of Internet Explorer are still popular enough to need supporting and their DOM api's can be insanely buggy and inconsistent.
To layer on top of that, now that we have awesome css3 features we also have to learn the DOM api's for those too!
At this point, many people reading this might start the valid argument that we have good javascript libraries (ok, only one and that's jQuery) to smooth over lots of those rough bits. Yeah, they help tremendously but its yet another thing that has to be learned to be effective.
Another thing is that css is really meant for layout and styling. While I truly love css3 animations and transitions, they're right on the border of needing to be somewhere else. They're wonderful for spicing up a page and doing cool designs that were impossible before but if they were even slightly more complex then I'd start arguing they shouldn't be in css.
Finally, getting back to the proposed css filters, I feel those are finally crossing that line. Like I said earlier, I may well be a stick in the mud Luddite but adding yet another css feature that literally lets you run code on the GPU is just too much. Its not layout any more and its moving into something further out than the css3 animation line.
One of the few reasons that I am up to speed on all of this stuff is that I've been doing it for years. I was able to learn this stuff gradually as it came out and get pretty good at it. However, if I were a younger version of myself getting started now I might read this comment I'm writing at length and get totally turned off from even trying to do frontend development.
I know there have to be others who disagree with my position. I'd love to get some other points of view that tell me where I'm wrong so I can re-analyze my thoughts on this. I'm open to change. Its just one more thing I have to learn.
Which is easier, maintaining rounded corners applied via CSS3, the old-school sliding doors, or JS? See also: text shadow, and box-shadow.
But...
Unless the styles are integral to the functionality of a certain component (usually layout or box model), I prefer to keep the styles where they belong. To me, it is much easier to maintain styles in a stylesheet - especially if you have jr. devs or designers working with you. Yes, CSS easily becomes a big ball of mud. But if you organize it properly - and maybe even use something like LESS or SASS - it is much more maintainable.
It is also the responsibility of a good developer to know when to apply certain techniques. For instance - a simple "grow on hover" is very easy to achieve via CSS animations - with a fallback to non-animated grow on IE etc. But a "grow on hover and then do crazy animations" is probably better accomplished with JS.
Don't worry, it doesn't take your comment to turn people off from front-end development. For me it just took the dual experiences of a) knowing what normal programming looked like, and b) trying to apply anything that I had learned about good software development to CSS.
Quite frankly, CSS has been a misguided mess since day one: if a layout engine is so weak and underpowered at doing layout that we need to rely on HTML and Javascript anyways in order to do common layout tasks, then why shoot for the separation at all?
Further, we end up relying on things like SCSS to be able to productively and maintainably use even the limited functionality that's there, which just makes me nuts. Now instead of a single full featured view layer, I'm dealing with four different types of code, that all end up touching each other, and that's even assuming I have managed to comprehend the insane positioning model that CSS uses in the first place, which makes even simple everyday layout tasks require extensive fiddling and debugging...?
Screw that, I'll stick to programming using actual programming languages, and leave the CSS to someone that doesn't despise every goddamn character that makes up the spec that it (sometimes, at least when the browser makers can follow enough of it to implement it correctly) follows.
- Real drop shadows! It turns out that many modern UIs have objects with irregular shapes. box-shadow only does...boxes. Not terribly useful.
- Real glow! See above. Lots of times you just want to be able to say "make that thing glow". Oh, it's not a rectangle? You're screwed. Time to make a sprite. Which you will have to edit and upload every time you tweak the glow. Ugh.
- Blurring effects! You can do all sorts of neat things with this.
- Color manipulation! Say you want to darken an element when a user clicks on it? Can't do that right now.
- Distortion filters! Very useful for making games. You can create all sorts of crazy scene-warping explosions.
Yes, browser inconsistencies suck. But other than that...you know, HTML/CSS/Javascript isn't that bad. Flex/Flash/WPF/Android/iOS are really not that much better. They're all good at certain things, but in the general realm of "creating interfaces" they all have issues.
I don't think you have to worry about the young developers, to them (us?) it's one more tool we can use to make cool things.
Things move fast, I just came back to web app development after 2 years doing GPU programming in school. I'm super excited by how far things have come, and I see an accelerating trend for the better.
There is an excellent library called d3.js for manipulating SVG, the learning curve is steep but it is really powerful. More libraries like these are/will surface to abstract away the painful DOM interfaces.
I guess it's a matter of perspective, the web looks richer than it ever has and it's still more convenient to program for than a cross-platform native application. Just my 2 cents.
The web is quite different from the games industry though,and just because the technology is there it doesn't mean you have to use it. We’ve had the power of SVG available to us for at least 5 years (except in IE), and few devs can develop using it (it's not that hard once you try, honest!).
The web is expanding to one of apps, where we can create native like experiences. That isn’t a bad thing. It means people can pick up and use web technologies to make apps when before they would have had to use C++ or Java or whatever. Just because people can write apps on the Web though, doesn't mean there will not still be the demand for web pages, based around pages, articles and content rather than the app model. Both will stand side by side for quite a while yet.
And back to games. They can be made using web tech now, and that along with mobile platforms, and online stores on games consoles and the like have breathed new life into the indie development scene. It seems it is now possible for a few people in their basement to make top selling games again. These is no reason why it can't stay the same for the web too.
Its always better that the capabilities are there for when developers need it, than not being available at all.