Jonkman Microblog
  • Login
Show Navigation
  • Public

    • Public
    • Network
    • Groups
    • Popular
    • People

Notices by Nolan (nolan@toot.cafe), page 26

  1. Nolan (nolan@toot.cafe)'s status on Wednesday, 12-Sep-2018 22:53:10 EDT Nolan Nolan
    • Eugen

    @Gargron lol this is really real, I am not that good at Photoshop :)

    In conversation Wednesday, 12-Sep-2018 22:53:10 EDT from toot.cafe permalink
  2. Nolan (nolan@toot.cafe)'s status on Wednesday, 12-Sep-2018 22:51:48 EDT Nolan Nolan
    • Eugen

    @Gargron outed by Minecraft

    In conversation Wednesday, 12-Sep-2018 22:51:48 EDT from toot.cafe permalink
  3. Nolan (nolan@toot.cafe)'s status on Wednesday, 12-Sep-2018 10:15:56 EDT Nolan Nolan

    Couple of good posts from the Chrome team looking at the past 10 years of JavaScript and browser performance: https://blog.chromium.org/2018/09/10-years-of-speed-in-chrome_11.html https://v8project.blogspot.com/2018/09/10-years.html

    In conversation Wednesday, 12-Sep-2018 10:15:56 EDT from toot.cafe permalink

    Attachments

    1. Invalid filename.
      10 years of Speed in Chrome
      from Chromium Blog
      Speed has been one of Chrome’s four core principles , since it was first launched ten years ago. We’ve always wanted to enable web devel...
    2. Invalid filename.
      Celebrating 10 years of V8
      A blog by the V8 team for JavaScript enthusiast that want to get a glimpse 'under the hood' of Chrome's JavaScript engine.
  4. Nolan (nolan@toot.cafe)'s status on Tuesday, 11-Sep-2018 10:25:32 EDT Nolan Nolan

    "Jaron Lanier interview on how social media ruins your life" https://youtu.be/kc_Jq42Og7Q

    Great interview, and once again can't recommend his book on social media enough. The main problem he cites is algorithmic manipulation, although I think many of his points are also relevant for non-algorithmic social media like Mastodon. https://www.goodreads.com/book/show/37830765-ten-arguments-for-deleting-your-social-media-accounts-right-now

    In conversation Tuesday, 11-Sep-2018 10:25:32 EDT from toot.cafe permalink

    Attachments

    1. Invalid filename.
      Jaron Lanier interview on how social media ruins your life
      By Channel 4 News from YouTube
    2. File without filename could not get a thumbnail source.
      Ten Arguments For Deleting Your Social Media Accounts Right Now
      'A blisteringly good, urgent, essential read' ZADIE SMITH Jaron Lanier, the world-famous Silicon Valley scientist-pioneer and 'high-tech...
  5. Andy Bell (hankchizljaw@toots.hankchizljaw.io)'s status on Monday, 10-Sep-2018 05:29:13 EDT Andy Bell Andy Bell

    You're probably aware of the recent Twitter hot drama about CSS, so instead of accusing people of doing front-end wrong, I thought I'd explain it all in a little tutorial instead.

    Hopefully, this will make folks who did get it wrong feel a little better.

    https://hankchizljaw.io/wrote/css-specifity-and-the-cascade/

    In conversation Monday, 10-Sep-2018 05:29:13 EDT from toots.hankchizljaw.io permalink Repeated by nolan
  6. Nolan (nolan@toot.cafe)'s status on Sunday, 09-Sep-2018 23:53:32 EDT Nolan Nolan
    • Shyju

    @kshyju Thanks!

    In conversation Sunday, 09-Sep-2018 23:53:32 EDT from toot.cafe permalink
  7. Nolan (nolan@toot.cafe)'s status on Sunday, 09-Sep-2018 20:17:08 EDT Nolan Nolan
    • Nick

    @nick Nope, they have an office in Bellevue (near Seattle). Although they're pretty friendly to remote work as well.

    In conversation Sunday, 09-Sep-2018 20:17:08 EDT from toot.cafe permalink
  8. Nolan (nolan@toot.cafe)'s status on Sunday, 09-Sep-2018 20:15:29 EDT Nolan Nolan
    • Eugen

    @Gargron "welp" is definitely the first thing that popped into my head when I saw that.

    In conversation Sunday, 09-Sep-2018 20:15:29 EDT from toot.cafe permalink
  9. Nolan (nolan@toot.cafe)'s status on Sunday, 09-Sep-2018 16:27:31 EDT Nolan Nolan
    • David Anson

    @DavidAnson That's too bad. Then again, I always have to visit the documentation for awk, grep, and sed because I can never remember how they work. 😂

    In conversation Sunday, 09-Sep-2018 16:27:31 EDT from toot.cafe permalink
  10. Nolan (nolan@toot.cafe)'s status on Sunday, 09-Sep-2018 16:18:50 EDT Nolan Nolan
    • ElfLord aka "Bone Daddy"
    • Johnny Normality

    @ElfLord @probgoblin freedom.horse doesn't have a relay set up yet. Also still needs to upgrade to Mastodon v2.5.0, been putting it off because lazy. 😅

    In conversation Sunday, 09-Sep-2018 16:18:50 EDT from toot.cafe permalink
  11. Nolan (nolan@toot.cafe)'s status on Sunday, 09-Sep-2018 16:02:32 EDT Nolan Nolan
    • Nick

    @nick Yup, just posted about it today. https://nolanlawson.com/2018/09/09/moving-on-from-microsoft/

    In conversation Sunday, 09-Sep-2018 16:02:32 EDT from toot.cafe permalink

    Attachments

    1. Invalid filename.
      Moving on from Microsoft
      By Nolan Lawson from Read the Tea Leaves

      When I first joined Microsoft, I wrote an idealistic blog post describing the web as a public good, one that I hoped to serve by working for a browser vendor. I still believe in that vision of the web: it’s the freest platform on earth, it’s not totally dominated by any one entity, and it provides both users and developers with a degree of control that isn’t really available in the walled-garden app models of iOS, Android, etc.

      “This is for everyone”, a tribute to the web and Tim Berners-Lee (source)

      After joining Microsoft, I continued to be blown away by the dedication and passion of those working on the Edge browser, many of whom shared my feelings about the open web. There were folks who were ex-Mozilla, ex-Opera, ex-Google, ex-Samsung – basically ex-AnyBrowserVendor. There were also plenty of Microsoft veterans who took their expertise in Windows, the CLR, and other Microsoft technologies and applied it with gusto to the unique challenges of the web.

      It was fascinating to see so many people from so many different backgrounds working on something as enormously complex as a browser, and collaborating with like-minded folks at other browser vendors in the open forums of the W3C, TC39, WHATWG, and other standards bodies. Getting a peek behind the curtain at how the web “sausage” is made was a unique experience, and one that I cherish.

      I’m also proud of the work I accomplished during my tenure at Microsoft. I wrote a blog post on how browser scrolling works, which not only provided a comprehensive overview for web developers, but I suspect may have even spurred Mozilla to up their scrolling game. (Congrats to Firefox for becoming the first browser to support asynchronous keyboard scrolling!)

      I also did some work on the Intersection Observer spec, which I became interested in after discovering some cross-browser incompatibilities prompted by a bug in Mastodon. This was exactly the kind of thing I wanted to do for the web:

      1. Find a browser bug while working on an open-source project.
      2. Rather than just work around the bug, actually fix the browsers!
      3. Discuss the problem with the spec owners at other browser vendors.
      4. Submit the fixes to the spec and the web platform tests.

      I didn’t do as much spec work as I would have liked (in particular, as a member of the Web Performance Working Group), but I am happy with the small contributions I managed to make.

      While at Microsoft, I was also given the opportunity to speak at several conferences, an experience I found exhilarating if not a bit exhausting. (Eight talks in one year was perhaps too ambitious of me!) Overall, though, being a public speaker was a part of the browser gig that I thoroughly enjoyed, and the friendships I made with other conference attendees will surely linger in my mind long after I’ve forgotten whatever it was I gave a talk about. (Thankfully, though, there are always the videos!)

      “Solving the web performance crisis,” a talk I gave on JavaScript performance (video link)

      I also wrote a blog post on input responsiveness, which later inspired a post on JavaScript timers. It’s amazing how much you can learn about how a browser works by (wait for it) working on a browser! During my first year at Microsoft, I found myself steeped in discussions about the HTML5 event loop, Promises, setTimeout, setImmediate, and all the other wonderful ways of scheduling things on the web, because at the time we were knee-deep in rewriting the EdgeHTML event loop to improve performance and reliability.

      Some of this work was even paralleled by other browser vendors, as shown in this blog post by Ben Kelly about Firefox 52. I fondly recall Ben and me swapping some benchmarks at a TPAC meeting. (When you get into the nitty-gritty of this stuff, sometimes it feels like other browser vendors are the only ones who really understand what you’re going through!)

      I also did some work internal to Microsoft that I believe had a positive impact. In short, I met with lots of web teams and coached them on performance – walking through traces of Edge, IE, and Chrome – and helped them improve performance of their site across all browsers. Most of this coaching involved Windows Performance Analyzer, which is a surprisingly powerful tool despite being somewhat under-documented. (Although this post by my colleague Todd Reifsteck goes a long way toward demystifying some of the trickier aspects.)

      I discussed this work a bit in an interview I did for Between the Wires, but most of it is private to the teams I worked with, since performance can be a tricky subject to talk about publicly. In general, neither browser vendors nor website owners want to shout to the heavens about their performance problems, so to avoid embarrassing both parties, most of the work I did in this area will probably never be public.

      A slide from a talk I gave at the Edge Web Summit (video link, photo source)

      Still, this work (we called it “Performance Clubs”) was one of my favorite parts of working at Microsoft. Being a “performance consultant,” analyzing traces, and reasoning about the interplay between browser architecture and website architecture was something I really enjoyed. It was part education (I gave a lot of impromptu speeches in front of whiteboards!) and part detective work (lots of puzzling over traces, muttering to myself “this thread isn’t supposed to do that!”). But as someone who is fond of both people and technology, I think I was well-suited for the task.

      After Microsoft, I’ll continue doing this same sort of work, but in a new context. I’ll be joining Salesforce as a developer working on the Lightning Platform. I’m looking forward to the challenges of building an easy-to-use web framework that doesn’t sacrifice on performance – anticipating the needs of developers as well as the inherent limitations of CPUs, GPUs, memory, storage, and networks.

      It will also be fun to apply my knowledge of cross-browser differences to the enterprise space, where developers often don’t have the luxury of saying “just use another browser.” It’s an unforgiving environment to develop in, but those are exactly the kinds of challenges I relish about the web!

      For those who follow me mostly for my open-source work, nothing will change with my transition to Salesforce. I intend to continue working on Mastodon- and JavaScript-related projects in my spare time, including Pinafore. In fact, my experience with Pinafore and SvelteJS may pay dividends at my new gig; one of my new coworkers even mentioned SvelteJS as their north star for building a great JavaScript framework. (Seems I may have found my tribe!) Much of my Salesforce work will also be open-source, so I’m looking forward to spending more time back on GitHub as well. (Although perhaps not as intensely as I used to.)

      Leaving Microsoft is a bit bittersweet for me. I’m excited by the new challenges, but I’m also going to miss all the talented and passionate people whose company I enjoyed on the Microsoft Edge team. That said, the web is nothing if not a big tent, and there’s plenty of room to work in, on, and around it. To everyone else who loves the web as I do: I’m sure our paths will cross again.

  12. Nolan (nolan@toot.cafe)'s status on Sunday, 09-Sep-2018 15:57:23 EDT Nolan Nolan

    Even when I was at Microsoft I never really learned PowerShell, but it seemed to have some interesting ideas. I'm lazy, so I just clung to using the Windows Subsystem for Linux ("Bash on Windows"), even though it's still rough around the edges.

    In conversation Sunday, 09-Sep-2018 15:57:23 EDT from toot.cafe permalink
  13. Nolan (nolan@toot.cafe)'s status on Sunday, 09-Sep-2018 15:55:08 EDT Nolan Nolan

    Interesting interview with the creator of PowerShell https://www.heavybit.com/library/podcasts/to-be-continuous/ep-37-the-man-behind-windows-powershell/

    I like this bit: "What's interesting is that the pattern on UNIX is you start writing it in some dirty Bash, and then you get 30 lines, and realize you're completely over your head, and so, you rewrite it in Python. Or in the old day, Perl, today, Python."

    In conversation Sunday, 09-Sep-2018 15:55:08 EDT from toot.cafe permalink

    Attachments

    1. File without filename could not get a thumbnail source.
      Ilya Sukhar
      By Ted Carstensen from Heavybit
      Ilya is an investor, entrepreneur, and advisor to startups, both individually and as a part-time partner at Y Combinator. Previously, Illya founded Parse, a mobile infrastructure company acquired by
  14. Nolan (nolan@toot.cafe)'s status on Sunday, 09-Sep-2018 14:42:03 EDT Nolan Nolan
    • Dave "Skippy" Crampton

    @skipfordj Oh cool, thanks! I don't even know what DMP is yet. 😜 I start on Monday.

    In conversation Sunday, 09-Sep-2018 14:42:03 EDT from toot.cafe permalink
  15. Sorin Davidoi (sorin@toot.cafe)'s status on Saturday, 08-Sep-2018 18:35:06 EDT Sorin Davidoi Sorin Davidoi

    Styled scrollbars have finally landed in Firefox Nightly (still off by default though), no more eyesore in Mastodon.

    https://github.com/tootsuite/mastodon/pull/8653

    In conversation Saturday, 08-Sep-2018 18:35:06 EDT from toot.cafe permalink Repeated by nolan
  16. Nolan (nolan@toot.cafe)'s status on Sunday, 09-Sep-2018 13:58:00 EDT Nolan Nolan

    New blog post: "Moving on from Microsoft" https://nolanlawson.com/2018/09/09/moving-on-from-microsoft/

    A bit of a self-indulgent post, but I felt compelled to write it. I'm leaving Microsoft and joining Salesforce. Gonna miss all the friends I've made at Microsoft over the years, but excited for what's next!

    In conversation Sunday, 09-Sep-2018 13:58:00 EDT from toot.cafe permalink

    Attachments

    1. Invalid filename.
      A brief and incomplete history of JavaScript bundlers
      By Nolan Lawson from Read the Tea Leaves

      Ever since I read Malte Ubl’s proposal for a JavaScript bundle syntax, I’ve been fascinated by the question: does JavaScript need a “bundle” standard?

      Unfortunately that question will have to wait for another post, because it’s much more complicated than what I can cover here. But to at least make the first tentative stabs at answering it, I’d like to explore some more basic questions:

      • What is a JavaScript bundler?
      • What purpose do bundlers serve in the modern webdev stack?

      To try to answer these questions, I’d like to offer my historical perspective on what are (arguably) the two most important bundlers of the last five years: Browserify and Webpack.

      A bundle of bamboo, via Wikipedia

      What is a bundle?

      Conceptually, a JavaScript bundle is very simple: it’s a collection of multiple scripts, combined into a single file. The original bundler was called +=, i.e. concatenation, and for a long time it was all anyone really needed. The whole point was to avoid the 6-connections-per-origin limit and the built-in overhead of HTTP/1.1 connections by simply jamming all your JavaScript into a single file. Easy-peasy.

      Disregarding some interesting but ultimately niche bundlers such as GWT, RequireJS, and Closure Compiler, concatenation was still the most common bundler until very recently. Even fairly modern scaffolding tools like Yeoman were still recommending concatenation as the default bundler well into 2013, using lightweight tools such as usemin.

      It was only really when Browserify hit the scene in 2013 did non-concatenation bundlers start to go mainstream.

      The rise of Browserify

      Interestingly, Browserify wasn’t originally designed to solve the problem of bundling. Instead, it was designed to solve the problem of Node developers who wanted to reuse their code in the browser. (It’s right there in the name: “browser-ify” your Node code!)

      Screenshot of the original Browserify homepage from January 2013 (via the Internet Archive)

      Before Browserify, if you were writing a JavaScript module that was designed to work in both Node or the browser, you’d have to do something like this:

      var MyModule = 'hello world';
      
      if (typeof module !== 'undefined' && module.exports) {
        module.exports = MyModule;
      } else {
        (typeof self !== 'undefined' ? self : window).MyModule = MyModule;
      }
      

      This works fine for single files, but if you’re accustomed to Node conventions, it becomes aggravating that you can’t do something like this:

      var otherModule = require('./otherModule');
      

      Or even:

      var otherPackage = require('other-package');
      

      By 2014, npm had already grown to over 50,000 modules, so the idea of reusing those modules within browser code was a compelling proposition. The problem Browserify solved was thus twofold:

      1. Make the CommonJS module system work for the browser (by crawling the dependency tree, reading files, and building a single bundle file).
      2. Make Node built-ins and conventions (process, Buffer, crypto, etc.) work in the browser, by implementing polyfills and shims for them.

      This second point is an often-overlooked benefit of the cowpath that Browserify paved. At the time Browserify debuted, many of those 50,000 modules weren’t written with any consideration for how they might run in the browser, and Node-isms like process.nextTick() and setImmediate() ran rampant. For Browserify to “just work,” it had to solve the compatibility problem.

      What this involved was a lot of effort to reimplement nearly all of Node’s standard library for the browser, tackling the inevitable issues of cross-browser compatibility along the way. This resulted in some extremely battle-tested libraries such as events, process, buffer, inherits, and crypto, among others.

      If you want to understand the ridiculous amount of work that had to go into building all this infrastructure, I recommend taking a look at Calvin Metcalf’s series on implementing crypto for the browser. Or, if you’re too faint of heart, you can instead read about how he helped fix process.nextTick() to work with Sinon or avoid bugs in oldIE’s timer system. (Calvin is truly one of the unsung heroes of JavaScript. Look in your bundle, and odds are you will find his code in there somewhere!)

      All of these libraries – buffer, crypto, process, etc. – are still in wide use today via Browserify, as well as other bundlers like Webpack and Rollup. They are the magic behind why new Buffer() and process.nextTick() “just work,” and are a big part of Browserify’s success story.

      Enter Webpack

      While Browserify was picking up steam, and more and more browser-ready modules were starting to be published to npm, Webpack rose to prominence in 2015, buoyed by the popularity of React and the endorsement of Pete Hunt.

      Webpack and Browserify are often seen today as solutions to the same problem, but Webpack’s initial focus was a bit different from Browserify’s. Whereas Browserify’s goal was to make Node modules run in the browser, Webpack’s goal was to create a dependency graph for all of the assets in a website – not just JavaScript, but also CSS, images, SVGs, and even HTML.

      The Webpack view of the world, via “What is Webpack?”

      In contrast to Browserify, which was almost dogmatic in its insistence on Node compatibility, Webpack was cheerful to break Node conventions and introduce code like this:

      require('./styles.css');
      

      Or even:

      var svg = require('svg-url?limit=1024!./file.svg');
      

      Webpack did this for a few different reasons:

      1. Once all of a website’s assets can be expressed as a dependency graph, it becomes easy to define “components” (collections of HTML, CSS, JavaScript, images, etc.) as standalone modules, which can be easily reused and even published to npm.
      2. Using a JavaScript-based module system for assets means that Hot Module Replacement is easy and natural, e.g. a stylesheet can automatically update itself by injection and replacement into the DOM via script.
      3. Ultimately, all of this is configurable using loaders, meaning you can get the benefits of an integrated module system without having to ship a gigantic JavaScript bundle to your users. (Although how well this works in practice is debatable.).

      Because Browserify was originally the only game in town, though, Webpack had to undergo its own series of compatibility fixes, so that existing Browserify-targeting modules could work well with Webpack. This wasn’t always easy, as a JavaScript package maintainer of the time might have told you.

      Out of this push for greater Webpack-Browserify compatibility grew ad-hoc standards like the node-browser-resolve algorithm, which defines what the "browser" field in package.json is supposed to do. (This field is an extension of npm’s own package.json definition, which specifies how modules should be swapped out when building in “browser mode” vs “Node mode.”)

      Closing thoughts

      Today, Browserify and Webpack have largely converged in functionality, although Browserify still tends to be preferred by old-school Node developers, whereas Webpack is the tool of choice for frontend web developers. Up-and-comers such as Rollup, splittable, and fuse-box (among many others) are also making the frontend bundler landscape increasingly diverse and interesting.

      So that’s my view of the great bundler wars of 2013-2017! Hopefully in a future blog post I’ll be able to cover whether or not bundlers like Browserify and Webpack demonstrate the need for a “standard” to unite them all.

      Feel free to weigh in on Twitter or on Mastodon.

  17. Nolan (nolan@toot.cafe)'s status on Sunday, 09-Sep-2018 12:52:06 EDT Nolan Nolan
    • GCU Prosthetic Conscience 🍞
    • Kirschn
    • codesections

    @codesections @Kirschn @gcupc You provide a redirect URL, then Mastodon redirects to that URL with a query param containing the code: https://github.com/nolanlawson/pinafore/blob/fc46835decdab0dbadaa9ea25f0edd9a249c49e2/routes/_pages/settings/instances/add.html#L74-L77

    In conversation Sunday, 09-Sep-2018 12:52:06 EDT from toot.cafe permalink

    Attachments

    1. Invalid filename.
      nolanlawson/pinafore
      from GitHub
      Alternative web client for Mastodon. Contribute to nolanlawson/pinafore development by creating an account on GitHub.
  18. Nolan (nolan@toot.cafe)'s status on Sunday, 09-Sep-2018 12:14:56 EDT Nolan Nolan
    • GCU Prosthetic Conscience 🍞
    • codesections

    @codesections @gcupc I can't remember exactly what I did, but I based my code on mastodon.js (https://github.com/Kirschn/mastodon.js/blob/master/mastodon.js) and you can see how I did it in Pinafore here: https://github.com/nolanlawson/pinafore/blob/fc46835decdab0dbadaa9ea25f0edd9a249c49e2/routes/_api/oauth.js

    Just glanced at your code, but is "read:favourites" actually a thing? I thought the only scopes were "read", "write", and "follow". https://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#registering-an-application

    In conversation Sunday, 09-Sep-2018 12:14:56 EDT from toot.cafe permalink

    Attachments

    1. Invalid filename.
      Kirschn/mastodon.js
      from GitHub
      Javascript Mastodon API for Web Browsers with streaming support - Kirschn/mastodon.js
    2. Invalid filename.
      tootsuite/documentation
      from GitHub
      Full documentation repository for Mastodon. Contribute to tootsuite/documentation development by creating an account on GitHub.
  19. Nolan (nolan@toot.cafe)'s status on Sunday, 09-Sep-2018 12:10:35 EDT Nolan Nolan
    • Daniel Lowe

    @dl hah yeah that's the other thing; he really looks like Goku with red hair.

    In conversation Sunday, 09-Sep-2018 12:10:35 EDT from toot.cafe permalink
  20. Nolan (nolan@toot.cafe)'s status on Sunday, 09-Sep-2018 12:10:12 EDT Nolan Nolan
    • Doc Edward Morbius ⭕
    • Woozle Hypertwin
    • Hugh Messenger

    @cheesegrits @dredmorbius @woozle I'm not really interested in trying the experiment again. I'm starting to think maybe it's normal for admin moderation talk to stick to channels like Discord where it stays off of public timelines. Also I think a lot of people just don't want to check multiple Mastodon accounts.

    In conversation Sunday, 09-Sep-2018 12:10:12 EDT from toot.cafe permalink
  • After
  • Before
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

Jonkman Microblog is a social network, courtesy of SOBAC Microcomputer Services. It runs on GNU social, version 1.2.0-beta5, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All Jonkman Microblog content and data are available under the Creative Commons Attribution 3.0 license.

Switch to desktop site layout.