1. Had many basic software development lessons hammered in by personal experience over the last couple of years: hierarchy bad. side effects bad. many moving parts bad. undue complexity bad. inconsistency bad. SQL databases fragile. always be reducing.

    It’s amazing just how seductive complex, unproductive tools can be. Successfully overcome+abandoned:

    • Codeigniter
    • Doctrine ORM
    • Bootstrap
    • Backbone, Ember, Angular
    • Symfony Security component

    PHP remains productive and speedy (with composer, delightful dependency management), python nice with some irritations. jQuery useful when absolutely necessary, plain with small libraries loaded via requirejs handle most progressive enhancement concisely. node.js nice for some things, preferring go’s approach to async programming but still not much everyday need for it.

    Avoiding middlemen: LESS, SASS, Coffeescript. Unnecessary for most of my work, and more moving parts is bad.

    Now bothering me is the frameworky nonsense accumulating in . Need to cleanse.

  2. jQuery and jQuery UI are amazing tools. They shouldn’t be used everywhere by default, but they do allow some complex stuff to be made extremely fast.

  3. This evening: documented Yahoo! Pipes UI in case of sudden shutdown, built first mockup of web dataflow UI using jsplumbtoolkit.com — really excellent library, exactly the right balance between functionality and framework. It gives you a lot but doesn’t dictate how to use it.

  4. Facebook use shady javascript to replace legit-looking link URLs with their own tracking endpoint.

    I made a browser extension which removes this: facebook-anticlickjack.

    It uses javascript to remove javascript from what should just be HTML. I call it “aggressive degredation”.

  5. Why not to make assumptions about where your site visitors come from send to do a hyperlink’s job:

    (That link didn’t work, obv)

  6. And the lesson of the day is: bean.fire(el, 'click') doesn’t work in Firefox Nightly, but turns out it’s unnecessary, because HTMLElement.click() does exactly the same thing and already works cross-browser. Always use the browser-native APIs if you can.

  7. My take on generic prev/next controls on keyup, using only bean for events, based on previous work by Aaron Parecki and Tantek Çelik:

    
    // Generic prev/next navigation on arrow key press
    bean.on(document.body, 'keyup', function (e) {
      var prevEl, nextEl;
      
      if (document.activeElement !== document.body) return;
      if (e.metaKey || e.ctrlKey || e.altKey || e.shiftKey) return;
      
      if (e.keyCode === 37) {
        prevEl = document.querySelector('[rel~=previous]');
        if (prevEl) bean.fire(prevEl, 'click');
      } else if (e.keyCode === 39) {
        nextEl = document.querySelector('[rel~=next]');
        if (nextEl) bean.fire(nextEl, 'click');
      }
    }); 
    
  8. Need to use require.js to load a bunch of scripts compiled via assetic into a PHP file, annoyed by auto-append of .js, don’t want to set up irritating routing? Add a ? to the URL, require.js will add a .js to the query string, loading the file correctly.

  9. Kyle Weems: I dislike having to deal with kludgy browsers too. But I also know my clients aren't interested in turning away many of their customers.

    cssquirrel Zepto is nice for browser extensions, where the browser will always be modern and capable

  10. Kyle Weems: function awesomeWorkday(tasks){if (tasks instanceof coolJsonStuff || tasks instanceof coolApiStuff) { return true; } else { return false;}}

    cssquirrel even the if/else is redundant ;)

    
    function awesomeWorkday(tasks) {
      return (tasks instanceof coolJsonStuff || tasks instanceof coolApiStuff) ? true : false;
    }
    

  11. Cross-browser selection UI injection flow:

    1. Listen for mouseup on body
    2. When triggered, let s be window.getSelection()
    3. If s.isCollapsed === false, return
    4. Else, let r be s.getRangeAt(0)
    5. Create a new element e
    6. Call r.surroundContents(e)
    7. e.innerHTML and e.textContent now return useful values, and e’s coordinates can be used to inject UI into the page

    To resolve: what element should e be? Or more accurately, what display property should it have? Possibly inline-block (inline mucks up if selection is across block elements, block mucks up selections within text nodes)

    Turns out there are problems with r.surroundContent, namely that it does not handle partial element selections. See MDNs explanation and solution.