
Building the next generation web - gk1
https://a16z.com/2017/08/09/netlify/
======
mynewtb
Original title is 'Netlify\n Building the next generation web', please do
include the company's name here as well so people can notice the advertisement
before gratifying it with a visit.

------
currywurst
> _" the web is still clinging on to monolithic backends — with their high
> costs, slower speeds, and huge surface area for attacks"_

Hmm .. I've observed that microservice architectures often end up having large
deployment footprint, higher usage of the network _and_ a larger surface area
for attacks since the "edge" is orchestrating more of functionality..

Does investing in Netlify really warrant such BS bingo? It's a really neat
product in its own right.

------
dguo
The first time I heard of Netlify was when I was making a change to the
documentation for Yarn and noticed deploy previews for pull requests[1].
Here's an example[2], if you expand the status check.

That alone piqued my interest. For static sites, I've been using a combination
of GitHub Pages and CloudFlare, mainly for SSL support on custom domains,
since you can't do that with just GitHub. I used Netlify for the first time on
a small side project a few days ago, and the experience was awesome. I plan to
move all my static sites to them in the future.

For dynamic sites, the idea of a frontend being served up from a CDN and
having just an API backend is so appealing. My big concerns are SEO impact and
users who have JS disabled. There is prerendering[3], but I need to learn more
about how well it really works and what potential edge cases exist. I went to
the trouble to implement server side rendering for my day job website (React
frontend), but it adds a fair amount of complexity. It almost certainly wasn't
worth it for a MVP product.

[1] [https://www.netlify.com/blog/2016/07/20/introducing-
deploy-p...](https://www.netlify.com/blog/2016/07/20/introducing-deploy-
previews-in-netlify/)

[2]
[https://github.com/yarnpkg/website/pull/389](https://github.com/yarnpkg/website/pull/389)

[3]
[https://www.netlify.com/docs/prerendering/](https://www.netlify.com/docs/prerendering/)

------
cageface
_It’s ridiculous that the web is still clinging on to monolithic backends —
with their high costs, slower speeds, and huge surface area for attacks — in
an age of microservices._

Microservices have plenty of downsides. Choosing between a monolith or a bunch
of microservices is an engineering decision that needs to be made on a case by
case basis, not a rejection of an obsolete architecture.

------
e12e
> By using microservices to help create faster, more secure, and more flexible
> websites/apps, we can bypass the static server-side approach.

Goes on to describe deploying static sites. Maybe they meant: by avoiding
_dynamic_ server-side stuff we can push microservice routing and integration
to the client (trading away some levels of cache for more demand on clients
and microservice providing dynamic content)?

[ed: the statement does make some sense if the intent was to contrast _static
server provisioning_ with _dynamic server (vps /container/PaaS) provisioning_]

------
piotrkaminski
At first glance this looks very much like Firebase, minus the real-time
datastore. What's different/better about Netlify, and how are you supposed to
use it for sites that need to persist data (i.e., pretty much anything non-
trivial)?

~~~
dguo
Firebase, from what I understand, includes a lot of backend products and
features to help you develop mobile apps. Netlify is focused on the web
frontend, which leads to both crucial and nice to have features for that
specific context. For example, you can just drag a folder containing static
assets into its interface and make a website out of it.

Features off the top of my head:

* SSL support (through Let's Encrypt), even with custom domains

* A global CDN

* Instant cache invalidation

* Redeploy with one click

* Roll back support

* Custom build commands (whereas with GitHub Pages, you either have to use Jekyll or commit generated files)

* An API

* Preview websites for GitHub pull requests, so you can easily view changes in browser before merging

For sites that persist data, you could still use Netlify to deliver the
frontend and then use Ajax to talk to the backend.

~~~
piotrkaminski
Hmm, Firebase does all of the above except custom build commands and preview
websites for PRs. And while they're certainly focusing their marketing on
mobile apps these days, they actually have a pretty good value proposition for
web apps as well.

Sounds like Netlify is competing either on simplicity or on price, with a
(likely temporary) advantage in developer tooling integration.

------
reaperducer
> building and deploying applications involves just a few clicks without
> requiring developers to build everything themselves.

That's exactly what's wrong with the web today: Too many "web developers" that
only know how to point and click. Schools are churning out thousands of people
with degrees who were taught to start with the trendy framework du jour, then
keep piling on JavaScript libraries until the given problem is solved. The
result is a disaster of bloated, conflicting, accessibility-hostile code. But
that's OK! Just run it through a post-processor and everything LOOKS
professional.

The world doesn't need another Angelfire. It needs more web developers who
understand programming.

~~~
shinamee
Except the world is built around business and business needs to make money and
making money is by making product development faster and simpler.

~~~
klez
Yes, but if you were building a car and used materials that were cheaper,
easier to assemble but resulted in a 10-metric-tons car that consumes 200 l of
gas for 100 km, would you still think your customers would be happy? Because
that's, _mutatis mutandis_ the state the web-app space is in, today.

