Shallow Thoughts

because deep thoughts smack of effort

Back in my day…

Posted in Personal Declarations,Web Stuff by Bridget on May 3rd, 2012

Those of us who came into the Front End Development profession approximately 5 years ago had the ability to learn it in a much more stable environment, if you will. Mobile wasn’t a “thing” like it is now. CSS3 wasn’t a thing yet, it was just a dream we drooled over. Preprocessors weren’t a thing. Responsive Web Design wasn’t a thing. This field of study is so much broader with so many more considerations.

I know it can be argued that there was always a lot to learn or that the topics we consider “things” today were always important. We’re just more vividly aware of it now, thanks to device proliferation. Regardless, people coming into the Front End Development specialty today have so much more to grasp at the onset than we did 5 short years ago. I dare say we had it a little easier, even if IE6 made us cry bloody tears all the time.

And it isn’t going to get easier, imo.

14 Responses to 'Back in my day…'

Subscribe to comments with RSS or TrackBack to 'Back in my day…'.

  1. Nate Klaiber said,

    on May 3rd, 2012 at 10:01 am

    I think the toughest part right now is that people aren’t learning the core (HTML, CSS, JavaScript), they are learning the layer on top. While I understand everything is a layer of abstraction, this makes it hard to understand the connection points between all of the players.

    Newcomers learn SASS, they learn HAML, they learn CoffeeScript. They learn the abstractions (which are great in certain environments), without an understanding of the technologies at the core.

    The same is true for programmers. They pick up a language (which is an abstraction of core programming principles) without learning the core principles.

    Don’t be afraid to learn something new, and don’t be afraid of the different abstractions – just be aware of how you are using the abstractions.

    That’s a lot of abstractions.

  2. Bridget said,

    on May 3rd, 2012 at 10:37 am

    Nate, I can agree with that of course. I read the folks claiming that learning jQuery before learning Javascript was going to be the end of the world… :)

    I agree with the sentiment, but maybe not the prescribed order of learning something (this “before” that). We all have deadlines and things we need to get done. If jQuery, as just one example, helps someone accomplish that task before they understand Javascript, I can live with that. But it behooves that person to better understand what jQuery provided them the ability to do. It behooves them to take the time to learn Javascript, at least enough to grasp how jQuery is getting us from:

    “element = document.getElementById(myID);”
    to
    “element = $(‘#myID’);”


  3. on May 3rd, 2012 at 11:32 am

    I sometimes wonder if all these abstraction layers end up adding complexity while trying to make things simpler. I agree with Nate in that you need to know how to walk (CSS) before you try to run (SASS).

    I’d heard of SASS (http://sass-lang.com), HAML (http://haml-lang.com) or CoffeeScript (http://coffeescript.org), but hadn’t looked into them until Nate posted above. Looking at SASS makes me wonder why “$blue” set as a variable is really any better than “#3bbfce” when I can easily search and replace for the hex code if I want to change the color blue. Also, using “darken($blue, 9%)” probably wouldn’t work for me, since I am usually matching the color in the Adobe Photoshop or Fireworks file and it would be easier to use the hex code than figure out the percentage lighter or darker. I can kind of see the nesting feature being nice, but once again it is adding complexity to the standard CSS concept. If someone always used SASS and then got a project that needed plain old CSS they might be lost.

    I have also been throwing around if I should try to use an HTML and CSS framework like 960 Grid System (http://960.gs), HTML5 Boilerplate (http://html5boilerplate.com), Twitter Bootstrap (http://twitter.github.com/bootstrap/), etc. in my projects. I have been using some of HTML5 Boilerplate’s concepts, structure, and features in my more recent projects, but don’t use it fully. I would like to say I am going to use one of these frameworks for all of my projects, but it seems like all my designs end up not falling in line with what they offer and I end up changing the framework’s code.

    I feel like I end up spending more time trying to figure out how to modify the framework to work the way I need it instead of just developing the code that will work from the start. Maybe I am missing something or maybe I need to start making my designs conform to these frameworks instead of designing something that makes using them harder.

    In reality I already have my own framework that I start all my projects with based off my previous projects. When I begin a new HTML and CSS project I end up copying over the code from a previous project and take it back to the base HTML and CSS that has all the standard HTML elements already laid out and setup. I start with these files and work from there to create the new templates. My starting templates based off my previous projects have all the different code I have added over the years based off research I have done. This code has the Eric Meyer CSS Reset (http://meyerweb.com/eric/tools/css/reset/), some of the HTML5 Boilerplate concepts, the Internet Explorer 7 and 8 form fieldset and legend fixes and other things. So I use my own framework, but should I be trying to use someone else’s framework instead?

    I guess maybe I need to learn more about what the frameworks can and can’t do, so I know what my design limit is when creating a layout. If everyone starts using these frameworks then could they lead to all the sites designed using them looking similar?

    I also ran into the problem of having to modify more things than just doing it myself with a few client projects recently. They bought WordPress themes from ThemeForest (http://themeforest.net) and ElegantThemes (http://elegantthemes.com) before contacting me to modify them. I ended up spending a lot of time trying to figure out the theme code and switch it to look the way they wanted it instead of just creating a theme from scratch the way they wanted it.

    I also agree with Bridget that there are a lot more “things” to know now than before, but it seems like as we move forward that at least with all the web browsers trying to follow standards now it might get easier to develop designs for one web browser and not have to pull your hair out fixing it for the others (Internet Explorer I am looking at you!). I think more than ever designers need to know the capabilities of HTML5, CSS3, JavaScript, etc. to be able to know what is possible. Maybe they don’t need to know how to code it, but they need to understand all the “things” that are possible and not possible.

    The web design and development industry seems like one of the fastest changing industries on the planet. If you take a few months off you feel like you are years behind. Our industry requires that we constantly research and continue to learn new things. This makes our careers challenging and interesting everyday, but I agree that sometimes all these new “things” coming at us on a daily basis can get overwhelming.

  4. Bridget said,

    on May 3rd, 2012 at 11:54 am

    Chris, this is a great article that addresses the woes you describe above using frameworks.

    If you haven’t read it, do so. RIGHT NOW! :)

    Regarding SASS and preprocessors, I understand what you are saying, but I can’t wholesale agree with you. I can say you aren’t necessarily wrong, but it completely depends on the situation you find yourself in.

    I’ve found myself working on projects that would absolutely benefit from being able to replace simple variables in a stylesheet and have it populate out to the complexity that makes up the rest of the styles. Situations where templates remain the same, but get applied to various brand identities or communities or microsites.

    Using preprocessors does require a whole different layer of strategy and planning, though. So even when opting to go down that path, it requires forethought. :)

    I don’t think preprocessors are necessarily right for all situations – because I haven’t been in ALL situations. I’m willing to leave room for it to be overkill in some scenarios, but invaluable in others.

    Here’s one article about a circumstance where it had a tangible, positive impact.

  5. Nate Klaiber said,

    on May 3rd, 2012 at 2:11 pm

    Chris:

    “If everyone starts using these frameworks then could they lead to all the sites designed using them looking similar?”

    It’s always been this way. It’s how people can look at a site and say “That’s Blogger” or “That’s WordPress” or “That’s Twitter Bootstrap”. I would encourage you to not fall into the trap that a design framework will solve all of your designer woes. It can’t replace your brain and skill.

    Bridget:
    In my opinion, variables in CSS directly would be bad (and unnecessary). They would cause yet another parsing engine (layer) in the browser, that could impact performance. Preprocessors help solve this by letting you do what you need in development, and packaging it all up for production so it’s fast.

  6. Bridget said,

    on May 3rd, 2012 at 2:24 pm

    Nate,

    I agree with you about preprocessors doing the heavy lifting before making a browser parse any of it for now. However, I’m sure the same thoughts were brought up regarding box/text-shadows, border radii and gradients before those came to be.

    If browser makers (note I didn’t mention the W3C) opt to have variables directly in CSS, it will be on them to optimize performance — and for us to learn how to use these things responsibly. I don’t think that will happen overnight by any means. There are still performance issues with the things we got out of CSS3 thus far and I think both sides have a lot of work to do to optimize performance. :)

    As an aside to this tangent I’m on, I recall the days when there were arguments over CSS transitions and animations. Strong declarations emerged that those types of things belonged in the Javascript layer because “Javascript is for behavior!” And over time, opinions softened. Opinions even did an about face for one reason or another.

    It’s part of evolution, though. We are best served by viewing things with an open mind (to the degree that we can) and be willing to change past assertions as new information and circumstances come to light.

  7. Nate Klaiber said,

    on May 3rd, 2012 at 4:15 pm

    “box/text-shadows, border radii and gradients”

    Supporting those is very different than supporting an entire parsing engine (variables, iteration, constants, etc).

    I wonder: did opinions soften, or was it that some of the skills needed were out of the scope of those holding the opinions? Seems easy to say ‘JavaScript is for behavior’ and ‘CSS is for presentation’ from the outside – actually sticking to that is different if you don’t know CSS or JS.

    I do agree we need to have an open mind, but I also think people need to know why they stand for what they stand for. There are so many articles recently of one person taking one extreme, another person taking the opposite extreme, and then someone coming in saying ‘they are both right, and there’s a happy middle ground’. Wash. Rinse. Repeat.

    There are things we need to be flexible with, and there are others where we need to stand firm and help make something useful for everyone. New JavaScript frameworks come out daily (maybe even twice a day). Everyone is trying to re-invent the wheel in their own little ways, without looking at the bigger picture of everything (the larger ecosystem). My mind is a little more skeptical when I see people doing that. I am less impressed with the new and shiny, when I see it’s history.

  8. Bridget said,

    on May 3rd, 2012 at 7:07 pm

    “I wonder: did opinions soften, or was it that some of the skills needed were out of the scope of those holding the opinions?”

    Fair question, but I think this guy (Jonathan Snook) is strong enough in JS to debunk the idea that only the weak in JS would prefer animations move to CSS:
    http://snook.ca/archives/html_and_css/shifting-opinion-css-animations

    Even still, let’s be honest — CSS animations aren’t actually a cake walk to implement — meaning, they don’t implement themselves. Either way, adding the ability to animate something to one’s toolbox was going to have a learning curve no matter where it permanently landed. :)

    “There are things we need to be flexible with, and there are others where we need to stand firm and help make something useful for everyone.”

    Everyone? Not literally everyone, right? Because if that is what becomes a requirement, then whatever it is we are standing firm on must meet the needs for the lowest common denominator allowing no alternatives for that which is not the lowest common denominator.

    Progressive enhancement has proven that focusing on the lowest common denominator isn’t necessary. It’s possible to accommodate a broad spectrum of things while doing our best not to burden the realm of the lowest common denominator. It may seem like I’m off on a tangent about the end result of the project (the displayed website/app), but I’m actually referring to the process by which that project can be built — meaning tools or specifications, too.

    Not every project would benefit from CSS variables. That’s a given. But just because every project wouldn’t benefit from them, should all projects go without them? Of course not. So, just because not all projects would make use of them, should that dictate that those who do use them must remain in the realm outside browser parsing?

    If a website’s guts don’t utilize CSS variables, there would (theoretically, of course) be no performance hit on that site. A site that does opt to use them, would have to weigh the benefits and the costs to provide an optimal experience for their users and use them responsibly. Think border radius, gradient, and opacity today: they can lessen the number of HTTP requests (improving performance) but impede rendering (inhibiting performance), so balance is key when using these CSS niceties.

    Because we’ve already lived in a world where CSS variables were created and compiled outside browser parsing, that could continue to be a tool to optimize the site just as it is today. However, it doesn’t seem reasonable to me that CSS variables, parsed by a browser, should never be an option. Advancement in technology has shown us this pattern on the web: Improvement in power and capabilities, then be disrupted — improvement in power and capabilities, then be disrupted; with each disruption introducing a kind of innovation from which we believe we benefit.

    I think there is room in the future for browsers and devices to get this stuff worked out so that we can use methods that improve productivity and make maintenance less cumbersome. Just because it might be difficult, doesn’t mean it isn’t worth exploring. That’s all. :)


  9. on May 3rd, 2012 at 8:09 pm

    I have a question about the CSS frameworks like SASS and LESS…

    I haven’t researched this, so I might be out of the loop, but I would think that they would require that the web browser download their framework and then your code you create using their framework. With all of this talk about Google and other search engines ranking websites based on page load speed, is it is a good idea to introduce another layer that needs to be downloaded potentially slowing the site down?

    Maybe I am totally clueless and they have somehow optimized their code where their framework code plus your code based on their framework is still smaller than using CSS by itself, but it seems like this wouldn’t be the case.

    The other fear I would have with using a CSS framework is that if I run into problems with a layout or other things do I truly know that it is something I did wrong or is it something that the framework left out or doesn’t support the way I expect.

    In relation to the HTML5 Boilerplate, Twitter Bootstrap and other design/development frameworks, I have been hearing a lot of buzz about them over the past few years and that is why I keep thinking I need to use them. Heck, the Akron & Canton Web Meetup is having a meetup about Twitter Bootstrap (http://www.meetup.com/akroncantonweb/events/60850542/) in a little over a week and maybe we should go to it.

    I feel like I might be left behind if I don’t jump on the latest web development trend buzzing around the industry, but I read the article by Rachel Andrew and I seem to agree with her and that is what I have been doing, but you start hearing the buzz and think you are doing the something wrong or inefficient. You start wondering if you could design and create better, faster, and more powerful websites or web-based applications quicker and easier if you used these frameworks. They make it sound like they will solve all of your development problems and allow you to offer your clients all the latest bells and whistles without taking anymore time. Is this really the case or do they really introduce bloat to your sites and applications that aren’t even needed?

    I really need to do more research on all these different frameworks, but lately I have been too busy getting things done for clients to actually worry about trying to see if something may or may not make things better.

  10. Bridget said,

    on May 3rd, 2012 at 9:56 pm

    Chris,

    SASS and LESS aren’t frameworks in and of themselves. They are CSS extensions. Essentially, they provide features (with special syntaxes) for writing and maintaining CSS that CSS alone doesn’t provide. You don’t start out with any code (CSS) that is pre-written for you just by choosing to use SASS or LESS.

    Compass would be considered a SASS framework and Twitter’s Bootstrap would be considered a LESS framework. There are others. Those are just examples.

    These frameworks provide pre-written code that you can opt to use/include when writing what you need for the project you have. These types of frameworks are often organized in groups of files that you include before the precompiler spits out regular .css files. So, you can choose to include or exclude pieces based on your needs.

    I have no doubt there are devs who include bootstrap.less, in the case of Bootstrap for example, before they write their specific styles. Doing so brings in the entirety of modules that Bootstrap has to offer. That doesn’t necessarily make sense if you don’t need all the styles they provide out of the box (like Rachel Andrew mentions). Don’t plan to use breadcrumbs, carousels, or accordions on your site? You could choose not to import the breadcrumbs.less, carousels.less or accordions.less, for example. The nice thing about having those things in Bootstrap is that if you need styles for those kinds of page components, they are there for you. (Just like the benefit of any framework of pre-written modules.)

    So, as I’ve been saying in a lot of my responses between you and Nate and I, it would take some planning and some critical thinking to choose what to include or exclude to strike the balance between keeping the payload of your CSS reasonable, while making use of pre-written features for speeding up development time. Maintaining a healthy balance is the key!

    “The other fear I would have with using a CSS framework is that if I run into problems with a layout or other things do I truly know that it is something I did wrong or is it something that the framework left out or doesn’t support the way I expect.”

    We all run that risk with any framework that we don’t take the time to learn well. Some frameworks are really well documented. Some are not. If you wrote your own framework, one would hope that you understand why you made the choices you did — or bothered to document those choices to remind you if you forget! :)

    At its core, an HTML/CSS framework is a set of reusable snippets of code that you know work well and are portable from project to project. Frameworks such as Twitter’s Bootstrap or Compass usually include all sorts of stuff to cover a wide range of features/modules/widgets. The smart thing is not to throw the kitchen sink at every site you plan to build. Choose your pieces wisely as a baseline and build out from there.


  11. on May 3rd, 2012 at 11:35 pm

    Gotcha on LESS and SASS not being frameworks. I read some more about them tonight and realized that, but I guess I was just lumping them with everything that is supposed to make our developer lives easier and calling them a framework.

    Have you used any of these things yet and which ones would you recommend using if I was going to look into them more?

    I need to read more about them and maybe try to use one on an upcoming project, I would just hate to choose one and spend a lot of time trying to figure it out and then realize that what it has to offer will not work for what I am trying to do.

    I definitely would pick and choose what I wanted loading and remove anything I am not using. I did the same thing with the HTML5 Boilerplate when adding its concepts to my base framework. Now that I think about it I have used the HTML5 Boilerplate framework concept for some things like directory structure and libraries on a few of my more recent projects, but I haven’t developed a full site using all it has to offer or following their exact guidelines for everything.

    For some reason Twitter Bootstrap keeps calling me, but is it because it is made by Twitter and getting some buzz lately or because it actually might make life easier?

  12. Bridget said,

    on May 3rd, 2012 at 11:48 pm

    I’m becoming more familiar with Twitter Bootstrap because we are using it at work. It’s a nice bundle of things, but my heart lies strongly with building your/my/our own framework. The reason why I feel that way is because there is always something in any framework that I’ve looked over that I would have done differently. There’s a lot of good things to glean from each framework out there.

    You know how you took the “best parts” of HTML Boilerplate because they fit with what you’re after, but left behind the stuff that you wouldn’t use or would do differently…like that. Steal, err, borrow from other people’s concepts but compile something useful to you.

    If you are in a team setting, get the whole team involved. If you are on your own, you have the luxury of not needing to make any compromises to make sure everyone is satisfied in the end. :)

    There are plenty of things in Bootstrap that are worthy of theft, err, I mean, borrowing so I recommend playing around with it to see if it would work out for you rather than building your own.

    Jonathan Snook’s book/site Scalable and Modular Architecture for CSS (SMACSS) http://smacss.com/ is a really great resource for how to think of elements on a page as modules. He doesn’t offer a pre-built framework, which is nice. It’s just the philosophy on how to do it — so that you can work on creating your own. I highly recommend reading it!

  13. Nate Klaiber said,

    on May 18th, 2012 at 10:54 am

    I am behind on my response. Yes. *Everyone*. When I say that, I mean that there is a solid foundation that is built at the core that allows everyone to get your content. That shouldn’t change. I shouldn’t be rejected because you choose to use the latests and greatest, brightest and shiniest JavaScript framework that will solve world hunger and cure cancer, yet block me from viewing and consuming your content on the web (remember Flash?).

    That’s part of our job as application developers. We scowled at people in the past building obtrusive applications, yet now we say it’s OK because framework X will solve all of our (design/client side/application) woes. Getting caught up in the new and shiny, we forget how to build the solid foundation.

    So, yes. Everyone. I choose to stand firm in that belief, and then build on top of that – remembering the.

  14. Bridget said,

    on May 18th, 2012 at 11:21 am

    Nate, I absolutely without question, agree that content needs to be accessible by *everyone*. And in that sense, *everyone* means *everyone*. You will get no argument from me on that.

    But I wasn’t talking about *everyone* in that sense of the word. I’m talking about tools and methods that web developers use to provide the experience the end user gets.

    I believe *everyone* is allowed to be at a different level of skill, a different playing field, so to speak and we should not limit the technology used to arrive at the best possible end result (the one described in the above paragraph) based on that lowest common denominator of “web authors” (term pulled from the hierarchy of constituencies from the WHATWG).

    I think it is a mistake to blame the tools for the shoddy workmanship in a products end result, unless there is a documentable technical barrier assisting that crappy end. (Like Flash.)

    I don’t believe that frameworks (the concept, I’m not talking about a specific framework here) used to build a site, in and of themselves, provide a bad user experience or poor accessibility. Poor use of a framework provides a bad end user experience. Not understanding accessibility considerations or choosing to dismiss accessibility concerns as only 1% of the user base is to blame. Not the framework alone.

    It takes a shitty carpenter to craft a shitty table. It is isn’t the fault hammer that he used to make that table. It could have been a high end hammer and he still failed to do a good job. Conversely, a well skilled carpenter can use a low end hammer and create a masterpiece, if that term applies to tables. I don’t know these things. :)

    That is the reason I am ok with frameworks. But, it is possible for frameworks to lull people into a sense of security that isn’t helpful. I’ll grant you that. But I think that is what separates the good developers from the bad. Just like every profession out there. There will always be those who are conscientious, cautious and thoughtful and those who don’t give a crap. They just do the job and call it a day.

Leave a Reply