gniquil's comments

I think you miss the point of having Next.js being based on React. Although I think handlebars/htmlbars are great (I'm a big ember user), the cool thing about React is it's component based. So pretty much everything you mentioned above, replace BarsHtml to react components, you have Next. However, the react components though in my opinion is much better than handlebars. It is more powerful, more flexible and at the same time more disciplined.

Haven't watched through the entire video, but the first part, analyzing dependency bottom up, and claiming version doesn't work, really reminds me of graphql. We've been doing traditional rest with /v1/..., /v2/.... This sucks for so many different ways. Graphql's solution of providing contract at the lowest level and just evolve the "graph" really feels a bit like what he was talking about in this video. And note that Facebook by not "provide less" or "require more" in their API is how they made their API still compatible with older clients. This talk is very interesting! (note I could be spewing BS here as I've not finished the video)

I use imgix at work and love it. However, there's one more downside which the article didn't mention, is no protected or authenticated assets, Say if you only want to serve an user some image if he's logged in. Other than, it's a perfect service.

Increase/decrease font size, adjust window height/width. I know you can do it with keyboard, but perhaps touch bar could make it more "natural" and free up key bindings for something else. Escape can be mapped to a double width button on the left.

So who's gonna be working on Sublime/Atom/Vim/Emacs integration on this. Shit, imagine all the things one can do with that bar (multi-touch, slidable, swippable).

I don't understand why there's so much backlash against the "bar". Personally I'm actually really excited. I'm a programmer. I can imagine all sorts of plugins and addons one can make for one's favorite editor. Imagine writing a plugin for vim or sublime text to inc/dec font size, mapping short cut functionalities to "named" buttons rather than F9. Don't like it contextually changing on you? Just program it to stay static. Some here complain that there's no escape key. But what prevents you from putting it there (better yet, maybe we could make it twice the width so you won't accidentally hit F1?).

In fact, extrapolating further, perhaps in 10 years, the entire keyboard (and touchpad) will eventually become one giant touch screen, with location specific haptic feedback. By then, the younger generation of programmers who grew up in the age of touch screen phones and ipads will not miss the real keyboards (like we don't miss the blackberries). And that one giant touchscreen will be infinitely more customizable.

Got too much on my hand

  var OVERLAP = 2500;
  var RECENTLY_PLAYED_NODES_LENGTH = 21;
  var recentlyPlayedNodes = [];
  var audioDurationFix = function(audio) {
    if ($(audio).attr('id') === 'ive-13') {
      return 3.0;
    }
    return audio.duration;
  }
  
  var randomNode = function() {
    var newNode = $('#ive-'+(1+Math.floor(Math.random()*$('audio').length)))[0];
    if (recentlyPlayedNodes.indexOf(newNode) === -1) {
      recentlyPlayedNodes.push(newNode);
      if (recentlyPlayedNodes.length > RECENTLY_PLAYED_NODES_LENGTH) {
        recentlyPlayedNodes.shift();
      }
      return newNode;
    } else {
      return randomNode();
    }
  }
  
  var playNext = function() {
    var audioNode = randomNode();
    $(audioNode).on('timeupdate', function() {
      if (audioNode.currentTime * 1000 > audioDurationFix(audioNode) * 1000 - OVERLAP) {
        $(audioNode).off('timeupdate');
        playNext();
      }
    });
    audioNode.play();
  }
  
  playNext();

It's sad that you capitulated. I agree with your original point more. Is this thing really flexible, composable, and implementable? How long do we have to wait for people to provide solid implementations on top of all the popular programming language and database backends? Feels like SQL all over again. Someone will be writing layers on top of this in javascript in the frontend and ruby/python/javascript/etc. in the backend. Then we are in another ORM hell. (Perhaps I am being too pessimistic here, it could very well be great, but I have some serious reservations...)

It not said explicitly, but I believe, for us, long term growth means users change their behavior. We need them to stop using Craigslist. We have the same challenge as early AirBnB.

perhaps the way to make it wow, is to connect 100,000 led to it, and each controlled by a separate browser socket. V8/node folks will cry a little.

Thanks for the comment. Our goal is to succeed in the Linkedin/Facebook sense of the word (excuse our enthusiasm, but if not this, we would self fund and be content with organic growth). But I don't want to dismiss their wisdom, as we could be spending our next year building something that will eventually amount to a semi-success/failure, and face a much more difficult pivot.

Your Meet me at "noon" placeholder got cut off (reads "no" right now). Had to pull up the trusty inspector to resize the input element to see the full word... Otherwise awesome!

Great job! Like the concept. But here's another nitpick.

I see when you activate a file, the animation first shrinks the file a bit and then expands it out. Is it possible to remove the shrinking? It makes the app "feel" a bit jerky. I think the reason is when you shrink the activating file, all other files expand by a bit. This causes the whole screen shifting a bit, leading to a somewhat jarring experience for a split second.

And of course someone should make storify for this once it gets popular.

So I just looked at the quick start demo code. Did everyone notice the irony in it? We created some fake people and some fake orders and randomly let the people see the fake orders. Then we try to predict based on this data. A bit silly isn't it?

But anyway, the whole thing seems pretty cool.

in 15 slides. :)

I have a very noob question. For most databases, suffix search is always super slow. However, can't someone just build an index based on the string reversed, then treat suffix search exactly the same way as prefix search? This doubles your index storage requirement. But index storage is generally not a problem. Finally this could be perhaps extended to cover any wildcard searches (hell*world)