ndreckshage

I'd be really interested in adding Twitter (etc) support to Lumenette with help of Keybase, if possible. Hoping there will be an API for other wallets to interact with the features Keybase is working on.

I've been using Keybase git and file storage for some time now. Really excited about this partnership!

Lumenette wallet, for reference: https://galactictalk.org/d/1159-lumenette-android-ios-stella...

what theme is used in the screen shots?

Next is great. I would love to deprecate my SSR starter kit - Sambell - https://github.com/humblespark/sambell - once it supports a layout file, for animated transitions, etc. Right now, React Router seems fundamentally more powerful as a SPA framework.

Congrats Luke!

Really nice work with all this! Great blog post on update

Next best - http://www.techrepublic.com/article/pro-tip-dim-your-ios-scr...

Correct, not rendering on the server removes the bottleneck.

Still relies on JavaScript server side rendering - which will be the biggest performance bottleneck, by far, for both this and React.

If you really want a framework that is faster, check out Tungsten (https://github.com/wayfair/tungstenjs), which is as fast as this client side, and can render in vanilla Mustache using Go/C++.

Blanket statement: anyone that makes blanket statements like 'React sucks' or 'Ember sucks' should not be taken seriously.

This mentions using Node/Express to help with concurrency. Ok. But this also mentions using 'isomorphic' javascript with React, and also not completely reliant on cache. React.renderToString (and all other isomorphic options -- Rendr, etc) are synchronous and slow. (rendering a large page in React w/ static data would take ~600ms; whereas the same page with with Mustache in Go for example would take ~30ms). End result, decreasing concurrency, and hurting overall performance.

OP - can you shed any light on how this is actually impacting your performance? Or maybe things that you had to do to get around the problem (ex - details of 'module level' cache with Redis etc).

Everyone is copying everyone. Grow up.

Confidence in returning the minimum to render a view. By default, without having to worry about over / under fetching data. Not having to worry about cleaning up endpoints when the needs of the consumer changes. A client that requests exactly what it needs, rather than hitting an endpoint with 'something', is extremely efficient.

Also, this is as interesting as React Native. And React Native is pretty interesting.

This is the biggest thing for JSON payload control since...JSON APIs became a thing?

This article is pretty naive.

1. m dot sites are not a thing of the past. Many sites benefit from a pure mobile experience.

2. The Boston Globe (while impressive) does not show that 'that responsive design worked for more than developer portfolios and blogs'. The globe is largely text / image based, and that does not translate to a site like Amazon / Facebook.

isnt this what storify is for?

interactive compared to a psd/basic mockup. to get a feel for how site could actually feel, which is quicker than building the backend features. can change description if misleading

good point. reason i didnt was several lorem ipsum sites dont have nice apis, or output in different json styles. but i agree with the idea