bobfunk

Lots of people use Netlify with GitLab as well. Some using our connection to GitLab and some pushing from GitLab's CI to Netlify via CLI.

We started out bootstrapping and were profitable before our first round of funding. However, we always strongly believed that the larger vision of what we wanted to build would be impossible to achieve without outside funding.

We used to have those charts per site generator on the detail page before the Middleman -> React Static rewrite of the site.

Would love to see them back myself. Pull Request at https://github.com/netlify/staticgen would be super appreciated, since it might take a while before any of the main contributors will have time to add it back in.

To me the proposal there is arguably even scarier than what AMP is doing now.

It requires changing browsers, to let people distribute Google Hosted Apps on their own domains (as long as Google approves). Sites distributed in this way will get preferential treatment by Google.

This is essentially an App store model, similar to Google Play, and the really big danger is that we end up in a place where you either distribute (and host) your website through Google's AMP registry, or you're not actually on the web (in the same way that distributing your Android app as an APK outside of the Play store is not a realistic distribution channel).

I hope Firefox, Safari and Edge will resist this.

Netlify CMS is a self-standing open-source project. We maintain it and are puring a lot of resources into it, because we think it's really important there's a good open-source solution on the market for projects built with static site generators.

However, the CMS itself is not tied to our deployment and automation platform. It can also be setup to work for GitHub pages or self-hosted setups.

The basic idea is that's its an editor friendly content management UI for persisted data stored in a GitHub repository. What you do with that data is up to you.

I've setup that flow by adding a custom script in the google doc that triggers a Netlify build hook. You can tie custom scripts to an image (so you can make it a publish button).

At Netlify we're multi cloud - currently run our infrastructure across 7 different cloud providers and are constantly expanding.

Make sure your people take vacations once in a while?

Jekyll works well with Netlify - you might just have needed a Gemfile or the like?

Have you checked the pricing recently? I think it's likely to have changed quite dramatically since after you switched to Firebase.

The features not included in free are not typically things you can't do without for personal projects (ie, password protection, role based access control, role management for team members, etc...)

Netlify as a service doesn't really affect how you do things as a front-end developer, but we do help make sure that all those assets get to your browser as fast as can be.

But yes, we all agree that we should do a better job of making our website leaner and we do have a bunch of changes planned around that (and we're hiring!).

For small/personal sites the pricing model is "Free". I think that tends to work well :)

We do support GitLab on prem already, but right now it doesn't let you trigger deploy previews and branch deploys. Currently that's something we can help with on the custom plan, but we do hope to bring it to the normal tiers as well.

Sure is ;)

We're working on that! Main challenge is in making sure we don't inadvertently get people's domains stuck in Let's Encrypts rate limiting...

Think "simplify" but with "net" :)

Co-founder here - Thanks so much!

We do use Elm for a couple of minor projects ourself, and it works great on our platform. We also have plenty of people using Typescript or Flow with Netlify.

It's a joke, we don't actually use neither left-pad nor is-positive-integer...

"do visitors mainly go to the www or no-www version of your site?"

Visitors follow links - just checked netlify.com vs www.netlify.com and over the last 3 days around 0.5% of visits went to netlify.com instead of straight to www.netlify.com

It's generally far more important to setup your site to be as performant as possible and get the best uptime than to skip the the www - there are ways to get the best of both worlds however.

It serves the HTML or assets directly

If you read the start of the article you'll see we do that as well. This only applies to people that don't use netlify for DNS.

With HTTP2 support this is not longer really a problem, since HTTP2 multiplexes requests over 1 connection.

We do run an anycast CDN network, but there's a lot of limitations on BGP routing compared to CDN based traffic direction.

We can only route BGP requests to hardware we control, whereas we can add PoPs in all the major cloud providers on our DNS based network. We can then use tools like Cedexis or DYNs internet intelligence to identify where the different cloud providers have the best networking and peering agreements and piggy back on that + their DDoS mitigation. This means we get a combination of all the best AWS/Google Cloud/Rackspace/DO, etc, etc has to offer in that aspect.

On the DNS based traffic director we can also do very quick traffic decisions (20s TTL, instant changes) whereas on our BGP routed anycast IP we have to be more conservative and force 10 minute intervals between any up/down changes for a PoP.

That would be great to see and would solve a real issue for many users of services like ours (or Heroku, GitHub pages, etc, etc, etc).

There are gotchas however, since you now depend on two levels of DNS based traffic direction and we have sometimes run into issues where DNS providers offering ALIAS records simply cached one DNS respond and sent all DNS lookups to the same CDN pop regardless of their location :/

Author here. We do actually offer all of these options.

We offer a public IP address for A records pointing to a our main load balancer. This will send all traffic to a single origin instead of serving your HTML pages out of our global CDN.

We also offer DNS hosting for pro plans and up. When you move your DNS to Netlify, the caveat about naked domains doesn't apply (as mentioned in the first paragraph), since we hook the domain record straight into our global traffic director.

For enterprise customers we also offer an anycasted IP address that lets you use our CDN with a normal A record, but we still recommend either using our DNS hosting or a www domain since the DNS based traffic direction is faster at responding to localized issues and offers more precise traffic distribution.

It's also worth noting that Smashing Magazine is not just articles (and comments), but also a full E-commerce, job board, event page, ticket checkout and introduced a new membership section with subscriptions.

Obviously all of that can still be done with a static front-end today (and with one front-end instead of 4 different ones), but that's actually what's newsworthy and it's hardly what anyone would traditionally think of as a "static website" :)

We do run our own CDN at Netlify, and that's what allow us to serve the actual HTML pages out of edge caches while handling atomic deploys and instant cache invalidation.

This matters less when you test from New York (where Smashing Magazine hosts their Wordpress version of the site).

Here's how the performance difference looks like for people in Melbourne:

https://tools.pingdom.com/#!/dbYpJA/https://www.smashingmaga... https://tools.pingdom.com/#!/exYLwO/https://next.smashingmag...

The most important part of this difference comes from Netlify delivering the complete initial HTML in less than 100ms compared to more than 2 seconds wait time for the initial HTML load on the Wordpress version.

I'm sure Smashing will see an noticeable uptick in engagement in many parts of the world due to this (it's an effect we've seen before).

(PS. Movable Type's approach was awesome, but the infrastructure around doing static deploys and full static builds was just not up to the task back then, and browsers were way more primitive, so you would end up needing a monolithic dynamic site for just about anything with some form of user interacion)

You need some kind of API layer to talk efficiently to Git with authentication, etc, from the browser, and GitHub has currently done the best job of building that.

We do have an open-source project for a REST API you can put in front of any git repository and would be happy to take contributions:

https://github.com/netlify/netlify-git-api

We do really want to build a viable workflow around this stack, and get to a point where setting up a project like this is completely click-and-go - without giving up the fundamental basis of being open-source, based on open-standards and based on an open concept of the web!

Wordpress and the whole ecosystem around the LAMP stack did a great job around this and was a big player in building an open web, but the underlying tech stack is way outdated now, and the developer experience is so far off what modern front-end tooling is evolving into, so we aim to build something for a modern stack, that doesn't give up on the fundamental openness of an open-source ecosystem.