20 comments

  • Darth BaneDarth Bane, over 6 years ago

    It's obviously perfectly fine to use old-school non-tooled HTML/CSS for one-off small projects. But when working on something day in and day out, the tools ultimately become very handy.

    10 points
  • Sacha GreifSacha Greif, over 6 years ago

    I'm not sure I understand why you wouldn't use Markdown and Sass, except out of misplaced nostalgia for the "good old days" where "everything was simpler".

    But I would argue HTML brings in far more overhead than Markdown, and the same with Sass vs pure CSS.

    So I'll keep my tools, thank you very much.

    8 points
    • Marc EdwardsMarc Edwards, over 6 years ago

      Yeah, I’m the same. (For the tools I like, anyway.)

      2 points
    • Art VandelayArt Vandelay, over 6 years ago

      I think he's referring to building things for clients. Say you're working for a small company and the folks there are knowledgable enough to hire someone with the chops to make some great things but they may not be interested in learning a new thing (on top of everything else they have to do).

      I do agree with that sentiment in terms of markdown. Outside of tech (dev, really) its gibberish to most.

      0 points
      • Sacha GreifSacha Greif, over 6 years ago

        How would editing raw HTML be easier than editing Markdown?

        If we're going down this road then the client will probably want some kind of WYSIWYG editor like WordPress, which is the opposite point that the original article is arguing…

        I feel like it's one of those articles that takes a nice-sounding idea but doesn't really add any substance to it. We have far too many of those in the design world…

        2 points
    • Jake ChapmanJake Chapman, over 6 years ago

      I completely agree with you.

      Most of the tools, and when I say 'most' I mean about 99.9% of them, help create things that are less error prone for clients with less technical knowledge.

      I didn't find anything about reading this that I thought, ah thats a good idea. lol

      Our jobs are to make things better and easier for clients, and when working for clients we want to be as efficient and cost effective / profitable while doing it. Hence tools that speed up production of those things.

      Thinking of someone whos going to be taking over a project somewhere down the line can be a double edged sword. Just because you don't think someone knows the skills you have, then not doing something specific due to that is a terrible way to think of it. The client paid you to do a job, the best / fastest way possible. Who they hire after you to do something should not put you in the spot of stopping you from doing what you do best.

      1 point
    • Diego LafuenteDiego Lafuente, over 6 years ago

      I totally agree. I've coded manually since 1996 but every time I have to do something simple like his, I would still use tools for compiling and code faster.

      I would use Cactus or other dozen of static generators, but I would be a total idiot if I go full manual HTML/CSS. Unless it's a page or two, of course.

      0 points
    • Sergie MagdalinSergie Magdalin, over 6 years ago

      I'm with you there man. I'm sticking to my hammer. I think this article is about "the thought of it". Not practical at all.

      0 points
  • Clark WimberlyClark Wimberly, over 6 years ago

    I'm a little bummed someone had to put this into words.

    7 points
  • David MDavid M, over 6 years ago (edited over 6 years ago )

    I am incredibly interested in the current vibes in the front end dev/design field..perhaps I'm more attuned to them as they ring true in my own feelings, but think about it:

    • the signal v. noise article on making the web more home-spun
    • the articles on both DN and HN on 'no new tools', 'no more build tools please'
    • Frank's recent articles on unneccessary tooling and personal feelings regarding his age and the industry
    • this signal v. noise article
    • the article on 'no more js frameworks' *Google's push to make Angularjs the de facto JS framework

    There's something to all of this.

    4 points
  • Rex FengRex Feng, over 6 years ago

    This brings up a good point. While it's cool to use the latest shiny tools, it can bring up too much overhead for maintenance (which is where most of your time will be spent for the site lifetime).

    4 points
  • Lauren WilliamsLauren Williams, over 6 years ago

    I could not agree more with this article. Things can get so complicated and overwhelming sometimes. If something simple is the best solution, why fight it?

    2 points
  • Diego LafuenteDiego Lafuente, over 6 years ago

    One Jekyll installation (1 min) and you can write dozens of pages, repeat the layout only once. It's brainless.

    1 point
  • Oz ChenOz Chen, over 6 years ago

    I don't think that Jim is arguing NOT to use tools. I think the bigger picture is "what process will help me reach my design goal?" and tools are part of that process.

    Self-plug: I write about this specifically for the UX audience here:

    http://www.uxbeginner.com/how-to-move-beyond-ux-tools/

    0 points
  • Andreas DruschelAndreas Druschel, over 6 years ago

    true story bro

    0 points
  • Colm TuiteColm Tuite, over 6 years ago

    The overall sentiment makes sense; use the right tools for the situation. Take into account the client's needs as well as the user's needs.

    Beyond that though, I don't see much sense to the article. It seems like he's longing for something that no longer exists for good reason. Larger teams, higher security, responsive design, internationalization, multiple programming langauges, user-specific views and slower connections are just some of the problems we face now that were not so prevalent years ago.

    So, if I were working on simple, static sites, I might drop some my tools. But I'm not, and I don't think many of us are. So, I'm struggling to see the relavance.

    0 points
  • Adam T.Adam T., over 6 years ago (edited over 6 years ago )

    I guess it's OK to not use indentation or paragraph breaks normally either. Reading experience aside, it's a great article. People tend to throw the book at a small design project.

    "So what if I have to repeat the navigation markup 8 separate times? It’s not that hard."

    Beautiful.

    0 points