kylemathews

thanks Jon!

Tracking shouldn't affect performance numbers much. The main problems Instagram seems to have is a) they don't server rendered HTML (so nothing shows until the client JavaScript is ready) and b) they don't use a service worker so the repeat visit scores aren't as good.

Also planning to build a "compatibility plugin" which should make upgrading pretty easy.

Cool! Really happy to hear you've found it useful.

And yeah... 0.x is definitely too magical. A lot of the changes in 1.0 are to make things more explicit and less magical. So even if there's a bit more typing, you'll feel more in control. 1.0 will also be adding a theme system which will hopefully preserve the "really easy to get going feel" while making it much easier to program whatever your project dictates once you deviate from the norm.

That's definitely coming. Before the 1st beta for sure. Still ironing out a handful of core features...

Absolutely. The web platform and web development tools have gotten incredibly good but can require a herculean effort to understand what's possible, how to use the tools, and get good performance. As the post points out , even instagram is missing out on a lot of performance optimizations.

Gatsby aims to be a compiler of sorts to simplify making really high performance websites so even low-budget websites and webapps can join in the fun.

Definitely! I hope to write walk-throughs, etc. on how things work.

(Author of post and Gatsby)

Netlify is great for hosting static sites. Free for non-commercial sites.

I love this pattern. I've been studying web performance for a while in the context of working on my project Gatsby [0] — a React.js static site generator. The next version of Gatsby is explicitly patterned after PRPL.

Gatsby at build time generates a static HTML version of each page. Which makes the initial load time of a Gatsby site super fast. The browser then loads the minimum Javascript necessary to make that page interactive. Then in a service worker, it starts prefetching Javascript and data necessary for other pages so that when you click on a link, it takes very little time to fetch the code/data and then make the page transition.

A couple sites running 1.0 code that you can check out are my blog https://www.bricolage.io/ and an example site cloned from Instagram https://gatsbygram.gatsbyjs.org/

I wrote up the performance plans for Gatsby in this issue [1].

One analogy I came up for that which I really like is to JIT or lean manufacturing.

Quoting myself:

"There's a close analogy to just-in-time manufacturing ideas. Companies found that the way to be the most responsive to customers is to actually avoid doing work ahead of time. When they did do work ahead of time this would paradoxically slow them down as the speculative work would get in the way of getting the work done that's actually necessary (resource contention).

For both manufacturing and web apps there's high inventory cost (unused code takes up memory) and a premium on responsiveness. The car customer wants their new car yesterday and the web app consumer wants their app running immediately. Any work you do ahead of time because "they might need it" gets in the way of the app being responsive to the user.

With both you want to wait until the user asks for something and then work overtime to get it to them as fast as possible."

[0] https://github.com/gatsbyjs/gatsby [1] https://github.com/gatsbyjs/gatsby/issues/431

This is really excellent! I've been hoping for a while now that someone would build something like this :-)

A direction that'd be interesting to explore is a guided query writer. Perhaps have a floating query input box and if you click on a type, it adds a query. Then you could edit the query and as you add/remove fields & connections, it highlights the equivalent areas of the visualization.

"Bandwidth" isn't the problem on 3g generally. What does cause UX problems is high latency. Speculatively precaching content is basically the only solution.

FWIW, while I'm in the US so don't really understand developing for very poor networks, the methods I'm describing is exactly what companies in India and other places with poor networks are adopting: https://developers.google.com/web/showcase/2016/flipkart

This is also a good read https://developers.google.com/web/fundamentals/performance/p...

Another point in favor of this model is because routing is client-side, page changes are consistently fast. In best-case network conditions, normal static sites are very fast but throw the user on a glitchy 3g network and you'll soon see 5-10 second page loads. The same site built with Gatsby will still see instant page changes as page data is precached.

Sure there's diminishing returns from ~1-2 seconds page change for a DB-backed site (slower ones anyways) to the ~500 millisecond page change for a normal static site generator to the ~50 milliseconds for a React-based one but it's still a significant difference.

But in any case, client-side routing to me is a nice-to-have not the killer feature for Gatsby. Building web sites with the React component model is the killer feature for me.

Javascript doesn't affect page load (generally). What Phenomic (and my project Gatsby) speed up is clicking around within a site after the initial page load as we pre-cache subsequent pages so loading those pages is near-instant.

Static sites sit on a large spectrum from very simple to very complex. The nice thing about React is it works very well on very simple sites as well as very complex sites. So yes, for a very simple 5-10 pages site, using React might seem silly but for a site with complex theming and lots of clientside JS, using React makes things a ton easier.

I'm the author of another React static site generator (https://github.com/gatsbyjs/gatsby).

I totally agree that for many sites, using Phenomic or Gatsby would be overkill.

But for something small, it doesn't really matter what tool you use as long as it's familiar. For small projects, familiarity trumps any other concern.

React came out of Facebook that needed a frontend technology that could scale to 1000s of developers.

Gatsby and Phenomic are both an attempt to port the best of the React ecosystem to the world of building web sites. They're designed so that as your website gets larger and you add more people, the code still feels simple and it's still easy to make changes and add new features.

So yes there's a learning curve and some overhead but it really pays off for larger projects.

And the nice thing is that once you understand them, they're now familiar so just as easy to use on small projects as any other solution.

SEEKING WORK | remote or onsite | San Francisco, CA

Seeking projects pushing static sites to their limits. Offline, Service workers, AppShells, PWA, etc. Working fulltime on my open source project Gatsby (https://github.com/gatsbyjs/gatsby) and am looking for people who want to build with it.

See also my blog post https://bricolage.io/gatsby-open-source-work/

You can use it with css-in-js libs like styled-components as well. It exports two helper functions, "rhythm" and "scale".

"rhythm" is a virtual unit that's the distance of one line-height. All spacing within Typography.js are based on it. Using "rhythms" for other spacings on your site ensures everything stays consistent as you make styling tweaks.

"scale" is a function to pick font sizes off the scale you setup (with scaleRatio). This let's you tweak the body font size and all other font sizes will move along with that.

Another option for creating a customizable, consistent font scale and spacing is my Typography.js project http://kyleamathews.github.io/typography.js/

It's a JS library that you provide a configuration object and it generates your type/spacing CSS. I love Tachyons and am planning on building a plugin for Typography.js which will generate tachyon-like classes.

https://github.com/kyleamathews/typography.js

Gatsby is a React.js static site generator. It transforms plaintext into dynamic blogs and websites using the latest web technologies. It makes building high-performance websites fun!

https://github.com/gatsbyjs/gatsby

Oh cool idea! GatsbyJS definitely needs one. All we've got right now is this crappy thing I throw together in Inkscape :-) https://twitter.com/gatsbyjs

Pitch: "Gatsby is a React.js static site generator. It transforms plain text into dynamic blogs and websites using the latest web technologies."

https://github.com/gatsbyjs/gatsby

Credit goes to this awesome project!

https://github.com/tleunen/react-number-editor

Thanks! Just a note, the design tools on the website are only 1/2 baked. Still need to add support for manipulating remaining options + way to export your designs.

That being said, the core engine is quite solid and the themes are ready to be used.

I've been working on a related project — Typography.js that vastly simplifies web design. It ships with 30 pre-built designs and I'm working on tools to make it really simple to create custom typography themes in-browser.

CSS is a very low-level language for expressing design intent. It's great if you want to set the background color but if you say: "I'd like to add white space to my typography" — it could take dozens of recalculations + css changes to test your idea.

Typography.js's goal is to create the most elegant/powerful API possible for defining your site's typography and remove a lot of the tedium/difficulty around experimenting with your design.

Would love feedback / help!

https://github.com/kyleamathews/typography.js http://kyleamathews.github.io/typography.js/

Curious if there's a plugin yet for adding caching headers to static assets?

What you're describing is a GUI or Graphic UI. A conf file is a UI. As is a library or service API which is what he's discussing.

It's in alpha.

"Relax isn't yet ready for production, stay tuned for releases, beta version will come soon"

RelateRocket | Full-time | SF/SLC | Remote | relaterocket.co | kyle@relaterocket.co

We're building the tools companies need to accelerate relationship and trust building in the internet age.

Hiring soon our 1st and 2nd engineers (I'm the technical co-founder). We're looking for a dataops/frontend engineer with strong preference for product oriented & full-stack capable/interested candidates.

Tech stack includes React.js, Relay/GraphQL, Elasticsearch, Redis, Node.js. Using event sourcing and soon adding Kafka + Kubernetes.

We're an early stage startup so plenty of room to own and design significant parts of the product. Work with cutting edge technology in an exploding market.

Roles: * Frontend engineer (React.js, React Native, Chrome extension) * Data engineer (Node.js (though flexible on backend language(s)), event sourcing). * Data scientist (analyze "data exhaust" from companies to help with sales/marketing).

>horse-drawn carriage

That code is more the equivalent of a digging stick. React is used to build horse-drawn carriages. I'm eagerly awaiting the JS framework that'll let me build cars.

Nice idea.

Bug report — it told me I had too many exclamation marks in a Markdown file with a number of images in it.