Building the next generation web(a16z.com)
a16z.com
Building the next generation web
https://a16z.com/2017/08/09/netlify/
7 comments
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.
> "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.
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.
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...
[2] https://github.com/yarnpkg/website/pull/389
[3] https://www.netlify.com/docs/prerendering/
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...
[2] https://github.com/yarnpkg/website/pull/389
[3] https://www.netlify.com/docs/prerendering/
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.
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.
> 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]
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]
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)?
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.
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.
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.
Sounds like Netlify is competing either on simplicity or on price, with a (likely temporary) advantage in developer tooling integration.
> 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.
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.
Except the world is built around business and business needs to make money and making money is by making product development faster and simpler.
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.
It sure is annoying, but that has more to do with the programmers ourselves, not the Web.
If anything I think the push button web app publishing has done more good than bad. For example I can't imagine how I would have taught myself to program if there weren't things like AWS or heroku.
We shouldn't make value judgment on the technology because of the bad actors that take advantage of it.
If anything I think the push button web app publishing has done more good than bad. For example I can't imagine how I would have taught myself to program if there weren't things like AWS or heroku.
We shouldn't make value judgment on the technology because of the bad actors that take advantage of it.
> 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.
What schools award CS degrees with this kind of curriculum?
That sounds more like what I'd expect from a programming boot camp.
What schools award CS degrees with this kind of curriculum?
That sounds more like what I'd expect from a programming boot camp.