JohnDotAwesome's comments

I can attest to the police car pulling it over. I saw a little Google car pulled over on the way to the grocery store a month or two ago.

> the problem with macros is that you sometimes realize you should have hit "Record" only after you've completed the action.

Happens to me all the time. But if using a macro was actually worth the effort in the first place, then it's probably still worth the effort to undo and record

The Vital Question. As a layman -- and an audio book listener -- this wasn't an easy book to get through! Still, it caused me to sit and think a little, and that was the whole point.

Because you did. I came to the comments wondering if this was a shameless ripoff of the original or a re-post from the same author.

Knowing where the viewport is relative to the document is pretty valuable; It means that AMP can defer loading potentially sluggish content until the viewport lands on a particular position.

As far as the scrolling goes, I'm fairly certain they're just using native scrolling (as in, not using a JS implementation that doesn't get the weighting right). The AMP Runtime needs to know scroll position, and they seem to just be capturing scroll information on the scroll event

See https://github.com/ampproject/amphtml/blob/master/src/servic...

I may be wrong on this, as I don't know enough about the codebase. However, I'm pretty sure it's just native scrolling.

I don't want to rail on the author here - lord knows I've written some JavaScript that I regret now - However, putting things on an event bus does not make modules independent, testable, or re-usable. You get those things from careful planning.

You are still going to introduce conceptual dependencies between modules. I'd personally rather have explicit control over those dependencies and their interfaces rather than passing it through a bus.

But anyway, y'all, if class A depends on class B, formalize the interface between the two (throw an error when expectations aren't met) and then inject the instance!

Yep. Who needs explicit coupling when you can silently couple interfaces?

> A lot of commentary tries too hard to invent problems with native apps to level the field with web app applications.

I don't necessarily disagree with that, but...

> Is updates a bother?

Yeah, kind of. Maybe just because I'm slow to update (my OS and my apps), but every couple of months, my apps break because I need to update (app devs apparently don't care about breaking older versions of their apps with API updates). On my iPhone5, I'll open an app (say, Facebook or Lyft), it starts up and then immediately crashes. This is how I know an update is available. I download the update, and yay, I can use the app again.

My favorite part of that:

http://storage.j0.hn/Screen%20Shot%202016-04-04%20at%209.35....

3.2 million additions, 916k deletions 20 commits.

I listened to Bill Bryson's self-narrated (and truncated) version of A Short History of Nearly Everything. It was my first time listening to an author self-narrating their book. It's probably one of my favorite narrations (I've got over 120 audiobooks under my belt now). Bryson set the bar pretty high.

Then I listened to Leonard Mlodinow's "The Upright Thinkers"; Oh god. Euclid's Window by Mlodinow was absolutely fantastic, and it was narrated by the slightly pompous-sounding -- but fitting -- Robert Blumenfield. Leonard had a somewhat slow, drawling voice, and he often stumbled over words. This was pretty disappointing because he seems like such a smart dude. He just shouldn't narrate his own books :)

The hot summer isn't bad because of the ubiquity of air conditioning in Texas. A lot of folks bring jackets to work in the summer because office temperatures are so low!

Everybody adapts to their environment, and in Texas, that means swimming when it's hot. As long as we get rain, the swimming holes are just absolutely fantastic. One summer, I went 3 or 4 times a week. Pack a bag with a few beers, bike to a trail, hike down to the water. The hotter, the better. You get super sweaty on the trek down, but getting in the water is so. damn. refreshing.

However, if you like hiking, Austin really sucks compared to Seattle. Washington has soooo many great hikes in close proximity to Seattle (less than 2hr). The best hikes around Austin feel like nerf trekking. Your best option is to drive 6 hours to Big Bend. Some folks recommend Pedernales or Enchanted Rock, but both are very popular and not at all challenging.

I love Austin, but dammit, we don't have mountains.

And in the last couple of years, from the iPhone 6 to the iPhone 6s!

Reminds me of the book, The Three Body problem

Currently-

* Babel - ESNext - JSX * Gulp * Browserify - Incremental * Express * React router * Rolled my own flux - This was interesting because I didn't truly understand flux when I started - I _get it_ now

The routes on the server are the same routes on the client. When the server renders, React/ReactRouter take over on the client and use history pushState.

And that's actually about it. There aren't any other major libs that change the nature of the project.

One thing I'm looking to do next is get hot reloading working and to somehow cut down on the initial compile times.

As a developer, doesn't it make you _itch_ when you repeat yourself? Do you feel that itch when you repeat the same application logic on the server as you do on the client? Getting the client-side validation in-sync with the server validation? This is where JavaScript is fan-fucking-tastic.

All of my recent projects have been isomorphic react apps. I build my app like it were a fully client-side single page web app, but I get server rendering when there's a new http request. Once the page has rendered, the web app takes over and uses history pushState. There are very few pieces of code that aren't used in both places. Once you get the hang of it, you very naturally create mockable interfaces that can be swapped depending on environment.

In my opinion, this is pretty much the only category that makes JavaScript "Best-in-class"; It's the easiest language to build isomorphic web apps.

Agreed! And creating a web component would be a trivial amount of code. We could definitely provide a distribution for that.

We would love to use the Polymer project at Goodybag, however, this has deterred us:

> IE8 is incompatible due to its insufficient DOM support.

https://www.polymer-project.org/0.5/resources/faq.html

How does it work? Where does it breakdown? Why are these things not in the README?

Sometimes, I felt like I was reading The Onion -

"... people basically found being alone with themselves not very fun and kind of boring."

"It seems that the average person doesn’t seem to be capable of generating a sufficiently interesting train of thought to prevent them from being miserable with themselves."

Really loving the piping example. It would be interesting to see more small composable utility web services out there. A sort of standard library of APIs