I think this person is trying to say they moved from Netlify to Render, with some moderately insane, vague anecdotes, like:
> Things which used to take hours or days to accomplish in standard Rails or Laravel or Django apps—most of this stuff isn’t rocket science, folks—now took weeks or months! Progress!
This article is too much of a narrative to be coherent about issues with Netlify + the Jamstack... and also too verbose of a narrative to be readable. I'd skip it, but maybe you'll find it entertaining.
i completely agree. use the right tool for the job. if you need significantly dynamic content, you should consider another framework such as rails (as the author indicates).
if netlify is being portrayed as the only platform to deploy a statically generated site from git commit, then i suppose yes, the sane defaults of these frameworks are not the right tool _for you_.
I used to have my static website on Netlify. I was using their form submission API and webhooks to trigger AWS lambda functions to run some scripts and send emails to users upon replying their comments. The website would then be rebuilt using new comments.
I replaced all this crazy setup with vanilla tools. I moved my webpage (a bunch of html pages and other files) to my VPS. I modified nginx to submit incoming html form submissions to my CGI bash script which then in turn adds them to a sqlite database and emails me.
There is no automatic rebuild. I wrote makefiles to rebuild and publish my pages in a few seconds.
It turns out I didn't need anything else, and above all I didn't need to spend time learning someone else's APIs.
But you did spend time learning unix, nginx, bash, CGI, SQLite, etc.
Sure I can agree these tools are worth learning, I'm just pointing out it's not the same thing. Netlify allows you to setup a static website with data collection, e-mail dispatch and whatnot all without code and much faster.
But the customer that needs that is arguably better off on Squarespace. Most modern point-and-click platforms let you build arbitrary forms with mail services.
Netlify wants developers to live and breathe microservices that they meter to developers. In order to get the benefits, you have to change DX, which the entire JAMstack community has been doing for a decade or so. The downside is now putting stuff on the web is often needlessly confusing and forces you to be dependent on a middle man.
> But you did spend time learning unix, nginx, bash, CGI, SQLite, etc.
True, and it's been a rewarding decision ever since. For a corporate or a community Netlify or similar JAMstack content management systems might make sense, but for a indie developer? I don't think so.
Although it may work brilliant minds in the Perl community such as Lincoln Stein and Randall Schwartz spent a significant amount of their career in the late 90s hunting down all the edge cases you're probably unaware of and produced CGI.pm. You can still learn a lot about CGI from this module but your exposure to vulns will be that much lower with something tried and tested.
> submit incoming html form submissions to my CGI bash script which then in turn adds them to a sqlite database and emails me.
'Sounds like something out of the pre-Perl era. Not saying you can't get it to work but .... why when there's a ton of micro-frameworks such as Roda (Ruby) and FastAPI (Python) which can handle this in a couple of lines of code?
I was making a static site and my boss asked me to find a free form submission and email service I can embed into the site. It was supposed to be in an nginx server so I proposed PHP like its 2005, but this had to be bikeshedded for weeks.
This article isn't the best, but I'm glad it is attempting to foster a conversation about the future of JAMstack.
I've been developing with React for 10ish years now. My most recent startups have been a mixture of React front-ends that call to a variety of backend services. Most recently using Vercel and Next.js to host our frontend codebase.
One of our lead engineers setup an NX monorepo. We deploy an API to AWS and our front-end to vercel. This has honestly added so much unnecessary complexity, I really regret it. Here's the main issue as I see it:
Conflating a fullstack web application, with a decoupled UI and a standalone API.
It's the same old conversation about "microservices" and knowing where to draw the boundaries. In my experience "frontend" and "backend" are not really good boundaries.
Sometimes there needs to be a high degree of coordination between frontend and backend. In this case, they should probably be part of a fullstack deployment like Rails or Django, or my personal favorite: Remix.
Personally, I think all web applications should start out with the assumption they are a monolith. Only after the product is starting to reach maturity, and weaknesses in the monolith are revealed, should a backend api or a decoupled front-end be split off.
Vercel and Netlify (among others) try and avoid the basic necessity of databases and other backend complexities as if a front-end developer can exist in some shining, pretty land free of that yucky backend stuff.
There are lots of ways to build a monolith that runs great and needs little maintenance and has only a few moving parts. See PHP with Symfony or Laravel for example…
NX with a Nest.js backend, and Next.js front-end. These tools just aren't very nice to jam together into a fullstack app. I'm really not a fan of NX itself. Lots of people love it, but I think it's way too much for most use-cases.
Furthermore, in our case, the front-end and backend are really coupled, so having these as separate systems is just a big headache. All of the web app's views are tied into specific backend functionality, and our API doesn't really stand on it's own without the front-end.
Yes this is poor architecture. I'm just pointing out a case where JAMStack was a mistake. Rails (or similar) would have been a smarter choice.
Ok I've never used Rails, but personally I've enjoyed my experience with a monorepo (pnpm workspaces) consisting of a Node.js API server and Next.js frontend server. You could try doing everything in Next.js, but I prefer keeping my backend separate. Love having everything in a monorepo though.
If you want more coupling, perhaps you could try something like ts-rest to add API types to your frontend. Or if you're feeling more adventurous, GraphQL or tRPC, though I personally prefer to avoid being tied to overly experimental frameworks.
Thanks! Yes, pnpm workspaces and turborepo are both far superior to NX IMO. They hit that sweet spot of providing the nice aspects of a monorepo without all the nightmarish configurations and complexities.
Next.js has saddened me since the move to SSR. I think remix is light-years ahead to be honest.
> Vercel and Netlify (among others) try and avoid the basic necessity of databases and other backend complexities as if a front-end developer can exist in some shining, pretty land free of that yucky backend stuff.
They are creating the disease and selling you the cure. You see less monoliths in the node community because it's the only ecosystem where the attempting to build a monolith takes you off of the happy path. Most tools and frameworks not-so gently nudge you in the SPA + back-end-as-a-service direction and make the simple thing hard.
> You see less monoliths in the node community because it's the only ecosystem where the attempting to build a monolith takes you off of the happy path.
As i understand you guys, you're talking about the difference between writing an API server vs writing a web app, that delivers the view, instead of an API.
What exactly makes one leave the happy path? Using a template language?
I'm not making a value judgement on rendering strategies, spa, etc. I'm arguing that for most js frameworks, building a full stack app with your own database, auth, etc without third party services is not the happy path. These are table stakes in php, ruby, and python. There are exceptions like remix. I'm just deriding a general trend.
Sounds like your lead engineer setup NX too soon. we made it about 5 years in to our monorepo before having to use tools like that. Once we were at a point where our codebase included multiple products, apis, frontends was when build and test times became unbearably slow and only then did we add NX to conditionally build changes and their dependants. I wouldn't recommend starting a new project with it by any means.
Agreed. I think NX is a big powerhouse of a tool that should only be used in mature engineering orgs with complex codebases and deployments. A seed-stage company is not the right fit.
Wonder how much of this is driven by the hundreds of millions of dollars of VC money put into stuff like vercel and similar.
All that complexity is not that useful imo.
If you need SSR you probably should pick the right tool for the job (not react) to begin with. If you need a simple static site you don’t need all this cruft either.
Am I wrong? I just don’t see where I’d use these tools and I’ve used them all before to try it out.
Fwiw my startup is keeping it simple with a go backend, sveltekit, and flutter iOS/android.
React can be super nice to use for SSR. When the site is small and/or simple (or even medium sized), React is definitely overkill. But if you have a big site (like lots of pages, or complex pages) then the component model that React brings can make it a ton easier. The rule of thumb I use is basically if I'm including/importing more than a few template pages, React can make it a lot more manageable.
Now that said, I think a ton more stuff can (and should) use SSG than SSR. This is IMHO the killer feature that Next.js makes easy to do.
I heard everyone saying 'react is for large complex project', somehow I think react is good for small project too: use a few components and its context api and dom-router to build a small site, the learning curve is actually not much comparing to other frameworks, what am I missing?
tried svelte, vue, I don't feel react is more complex, if at all.
Yeah compared to svelte, vue I think React is the way to go. For me the alternative for a small or medium project is a standard template system like Liquid (Jekyll), ERB (Rails) or EEx (Phoenix).
as a former advocate for Jamstack (https://www.swyx.io/ideas?filter=jamstack) this has been on the cards for a while, and I'm glad that enough consensus has gathered that it is not impolite to talk openly about what it did and did not get right. I should do a full writeup on this as a personal reflection as it was a very major phase in my life but I could not be fully honest about my feelings on why I left since I had so many friends still working on it.
all i will say for now is that the Jamstack movement was a champion of simplicity on the web, and I hope that there's an equally powerful voice in the current move towards React Server Components and distributed-system-in-your-frontend trends.
I spent a week moonlighting on a project that needed some help. We were both competent devs and just trying to make enough shiny and functional for a working demo. I did all my front end coding in vanilla JS with a little typescript parser he made (my first exposure to TS).
Readers, it was so AWESOME to write spaghetti JS in one file. Do a little manual code organization. Name things sensibly. Write comments. Communicate.
Everything we did could be shimmed into a react app fairly quickly, but why? Our goal was to get something out the door that performed an intuitive feature-set and we did it. We didn't have to fiddle with dependencies, or start thinking in 'library mode' when you search NPM for something instead of just coding it yourself. Just make the thing that works. If you suddenly have to scale your team and need to refactor to a common framework in order to support dev onboarding, that is an incredibly fortunate position to be in and a good problem to have.
Sure eating carbs feels great, and it doesn't stop you from building a healthy diet that includes spaghetti, but you're in for a world of hurt if that's all ya got.
Duh. Don't try to ship gmail in one file. But there's so much about working the DOM with vanilla JS that is very intuitive, and HTML <templates> are a thing now.
My point, which I'm sure I articulated poorly, was that we found ourselves highly productive by simply using the tools and API provided in the modern browser and a text editor.
Once you have an admin panel and a CMS and a WYSIWYG editor, maybe get yourself a framework you'll start hating in a few years.
No dependencies, you become the best, you become sovereign.
wikipedia:
Sovereign is a title that can be applied to the highest leader in various categories. The word is borrowed from Old French souverain, which is ultimately derived from the Latin superānus, meaning 'above'.
The roles of a sovereign vary from monarch, ruler or head of state to head of municipal government or head of a chivalric order. As a result, the word sovereignty has more recently also come to mean independence or autonomy.
but then you have to actually make it a functional part of a business with tests and regulatory compliance and integration with other products and customer requirements, and new developers who didn't build the original demo start working on it, and then you remember why all that complicated and inconvenient tooling exists. just building demos and then abandoning them doesn't pay a whole lot of bills, unfortunately.
Like the author I have been using a static site generator for my personal website. It hasn’t had a new commit for 6 years and I’m not entirely sure I have the code to reconstruct my site. But the best feature it has was s3 deployment into a bucket and the hardest part for me was getting DNS working and pointing it to the S3 bucket. It can deploy directly to S3 with a really old graphical UI for a Mac but as long as you have it the right access token it would work. If you really want to get past the issues that the author faces I would look into using S3 to deploy .
A couple weeks ago I did my portfolio site with React/Gatsby, while its performance was relatively good and better than say a wordpress page, but later I tried Zola and the performance is just much much better, in development or even as a user, plus now it works even with no JavaScript enabled in the browser.
So I think react and the likes can be used but only when it’s the only tool that can make it, else, there are plenty of better tools.
Honestly, frontend development especially with all these crowded frameworks and libraries always confused me so pardon my ignorance, which is why in a project I’m working on right now I’m trying not to use js, instead I’m using egui [1]
Zola is a static site generator and it’s crazy fast, using one binary only [2], also there’s Blades [3], same concept but supposedly faster, never tried it though.
That's only true if you have low traffic in which case why not host from a $50/mo (at most) VPC? If a business can pay your salary then surely they can afford an extra $50/mo cloud costs.
>you don't have to manage servers
However now you have to learn to write serverless functions that will execute in an environment fundamentally different from your local machine making it more difficult to develop. So you've reduced time spent in devops and increased time spent in development.
I've found some great use cases for serverless. None of those have involved hosting a backend for a website / web application. It's been a useful solution for automating some cloud management tasks though.
Regarding cost, it can depend a lot on your traffic structure. If traffic is bursty, or substantially different between intraday peaks and troughs, it can be more cost effective. Solving this yourself costs dev time.
>reduced time spent in devops and increased time spent in development
This may be true if you’re trying to figure out how to do something you already know how to do outside of serverless, but IME many developers benefit from serverless eliminating boilerplate and nudging them away from state where it’s not necessary.
Also regarding cost and devops: I see serverless as an insurance policy against “my startup/product got a once-in-a-lifetime lucky break by going viral while I was asleep” causing you to fall over from a flood of traffic. Not only do you get to skip implementing your own scaling to go from 0-1 but you only pay substantially (vs the regular price diff) extra for it when it happens.
People waste so. Much. Time. On shiny tech, often just because it ends up on HN (or Tiktok or Insta).
I remember evaluating the JAM stack years ago, and was underwhelmed. Like so many shiny new techs it didn’t really offer any big leaps forwards under the marketing and hype. People who lapped it up should think more critically about why they adopt tech.
It seems like something that was designed to sell more cloud SaaS services: content hosting services, build services, etc. Instead of having one host for your site you now need three.
I don't mind the churn, adopting new tech can be its own form of personal enjoyment.
What I dislike is the hype, people with sizeable bases acting irresponsibly about new tech. Encouraging early adoption, and spending so much time promoting it, funding conferences, and then after 5 years dumping all of it so you can "learn from your mistakes" to push for some new thing. It feels so dishonest, why would their current choice be any better if they made such reckless decisions not too long ago?
So you're right we really do need to think critically about new tech and give people the means to assess things critically without the hype.
The problem with this attitude is that sometimes shiny new tech is awesome. I remember when nginx was shiny new tech and I had to deploy it into prod (back in 2007-2008) to prove that it was superior to Apache + mod_python.
You need to be able to take the good with the bad and analyze everything objectively.
The author continues to push the message that Jekyll is dead and irrelevant. I will have a hard time taking anything he says seriously until he acknowledges that Jekyll is still a useful and relevant tool for many developers (including me).
The author's problem arises from the inability to understand that JAMStack is tailored towards static content / client-side apps. That's it. Postgres, server logic, services etc all represent something else.
He also discusses Netlify and Render feature sets. While both services allow to do more than just a stateless JAMStack, they both have too much vendor lock-ins, and offer too little to make people take that functionality seriously. For example, Render supports Docker containers, but they are tied to a single region only. This is probably enough for hobby projects, but it's a show stopper for commercial deployments.
In my opinion, author drank too much Heroku-aid in his conclusions.
I'm getting a similar impression. This seems like a classic case of blaming the tools rather than figuring out the right tool to use. I have a suspicion that their journey isn't over.
> For example, Render supports Docker containers, but they are tied to a single region only. This is probably enough for hobby projects, but it's a show stopper for commercial deployments.
The vast, vast majority of commercial deployments are single region, as evidenced by the occasional failure of us-east1.
The next time I try and do a serverless site I'm going to use SST. The last time I tried making one, I got all the way to the end of the project using Pulumi only to realise that I couldn't do any tests of the severless functions locally which would have made things an absolute nightmare. I think the only way you can do this is using AWS SDK or SST. Something to be aware of for anyone wanting to go down this route.
I would actually argue that Jamstack has won to the point of basically just being "Modern Web Development" by now.
In the 7 years since I first presented the term at Smashing Conference in San Francisco, I can't think of a single new successful commercial CMS that hasn't been headless or API first. I can't think of a single new successful commerce platform that's launched in that period, that hasn't been headless or API driven.
On the contrary, big existing players have mostly changed their strategy. Shopify is more and more embracing a decoupled approach of building globally distributed shop UI's with Remix (running either on their own platform or places like Netlify or Cloudflare) pulling in products, pricing and check out flows from their API layer. Most existing CMS companies have started integrating API first approaches into their strategy and in the data space we've seen an explosion of "Database as API" from Neon, to Supabase, to Xata or Converx, etc...
Part of the confusion has always been the conflation of Jamstack with "static" when even my first presentation on Jamstack back in 2016 had a big slide with the word static crossed out to underline that I personally didn't intend to conflate the two. The real game changer for treating the web UI as it's own decoupled application, and the backend as a set of API and services where some are your own running your core business logic, but a lot of them are provided by external providers.
At Netlify we're now focusing less on evangelizing the Jamstack approach of treating the web UI as it's own decoupled, independent layer, running on top of API's rather than stuffed into your backend systems - and more on helping really large companies adopt this at scale for their core web architectures (Composable Architectures). But not because we're any less bullish on the first part, on the contrary - because we don't really have to anymore!
And the article's conclusion that we somehow failed is absurd. Sites and apps on Netlify are visited by more than a billion unique visitors a month, we delivered more than 10 Petabyte of
data out of our network in December alone, have onboarded more than 4 million developers to our platform, and continue to prove that we can scale this architecture to some of the largest and most complex companies in the world, running big complex projects with faster time to market, higher productivity and higher conversions and revenue.
The author never actually articulated what his beef was with Netlify. So yeah I think you're just as confused as the rest of us. Apparently Netlify was supposed to become Heroku, but Heroku is bad, but Render (which is... Heroku with a fresh coat of paint) isn't? I dunno.
Render seems to have autoscaling with a reasonable round-robin load balancer [1], whereas Heroku only has autoscaling in (expensive) Private Spaces [2] with a dumb load balancer [3].
JAMStack isn't modern web development. 80% of the internet still runs on PHP on traditional servers. Netlify is needless complexity (nevermind the vendor lock-in) 99% of developers will never need.
You also don't address the OP's points where Netlify has suffered the same fate of "enshitification" where features slowly get stripped out and moved into pay to use buckets, likely at the behest of needing to payback 100+ million dollars in VC funding.
Objectively speaking our free tier today have far more features, higher limits and more capabilities than it's ever had before.
We are also building a real, longterm sustainable enterprise business. We're not a non-profit and we're here to create a big lasting company that can keep investing into the future of the web.
Almost every feature you charge for is something you can achieve for free inside of a basic VPS. I understand you have the classic SV "Hotel California" model where you can check in but you can never leave. But frankly this makes the internet worse in every way possible and part of the point of the original article.
The difference is I'm not out touting using a VPS as "The next generation of web development" and having payola articles written that if you don't use a VPS then your career is going to get left behind.
Setting up a VPS is pretty easy. Ensuring your VPS is configured to restart your app when the server restarts, maintaining OS and library updates, maintaining security, updating the app itself with simple-enough conventions, and configuring monitoring is not so necessarily easy. That’s not including documenting (even if only for your own future reference) how things are configured.
Digital Ocean in particular has great guides to get you from the starting line to something that in most cases will work okay, but as a long-term solution to “I have an app I want to run on some infrastructure”, I agree that there’s a non-zero cost to managing a server that, like you, I’d much rather not deal with.
I gotta say, this comment really comes across as being written by someone who has quite literally never tried Netlify, or doesn’t understand the value prop at all.
Seriously, it is orders of magnitude faster to deploy a static website on Netlify - simply drag and drop a folder from desktop - than it is to spin up just a single VPS on Vultr… and by the time you’ve configured that VPS, I could have done a dozen revisions to the website, and it would still be more difficult to deploy updates to the VPS than to Vultr. Don’t even get me started on the complexity of a global CDN.
Do I wish all of Netlify was free? Sure, yes I do. Does this mean it’s not valuable? Of course not.
The irony of this is that you seem to be saying that (a) Netlify locks the customer in with useless features, and (b) it can be trivially reimplemented in an entirely custom but otherwise “free” VPS.
The real question is, which “free” VPS are you going to use that will serve the same capacity as Netlify’s paid plans? AWS? Do you think you can avoid lock-in using AWS - of all things?!
No, you asked for a free comparison. If you want to go to paid features netlify loses by a mile. You can search all of this yourself with all of one google query.
I didn't ask for anything. I am just responding to your comment. You said:
> Almost every feature you charge for is something you can achieve for free inside of a basic VPS
I have plenty of experience with both Netlify and VMs, and I don't think they are even remotely comparable.
> You can search all of this yourself with all of one google query.
You're the one making the claims - I'm not even sure what I would be searching for since the parameters of a VM are vastly different to those for Netlify. How could I even find TTFB for a free Oracle VM? In fact, my personal experience with Oracle VMs (granted it's from before 2018) is that the jitter would be very high, such that any TTFB would probably be meaningless. And it would depend on the deployment region, too. Not to mention the HTTP server being used.
Words are cheap. Unless you're willing to substantiate your claims with some actual facts, nobody learns anything.
You are definitely getting much much more with a free VPS than with netlify. Netlify's value is in being easy, not cheap. If your argument is for being cheap then you will lose that argument all day, every day.
You really need to explain this. Honestly. Actual numbers.
Netlify’s free plan is awesome. You might get more bandwidth with a VPS. But you won’t get a CDN and you won’t get atomic deployments without a bunch of work. You’ll use half your VPS storage on the operating system. You’ll need to keep updating your software and maintaining backups. You’ll spend hours or weeks a year maintaining this thing, versus zero for Netlify.
It’s not just about the cost of bandwidth or storage. You gotta compare like with like.
You can't compare like with like. How will netlify compare with the below?
1. Full server control (install any package)
2. Host any kind of server - Django, Rails, etc. etc.
3. Run database servers: MySQL, PostgreSQL, MongoDB, etc.
4. Background processes (cron or systemd)
5. Run VPNs and proxy servers for personal use at the same time.
6. Host email servers
7. Multi-purpose usage (Use for remote dev environments, cloud storage, AI/ML platforms, etc.)
You know you have to secure, patch, and monitor a VPS right? Why pay for a VPS at all? You can get more compute, memory, and storage with a dedicated server for the same price and even setup multiple VMs on that server, each with all the features of a VPS “for free”.
Your comment doesn’t refute the idea that JAMStack isn’t modern web development. All you did was pull up the over-used statistic of “80% of the web is PHP” which I’ve heard for well over a decade. It may have been true at one point, but I highly doubt it is now. (Citation needed)
Netlify has done nothing but innovate and push the needle forward for front-end devs. I’ll be there until there’s a VERY strong reason not to be.
PHP is know for being very leaky about being PHP (and since PHP + ecosystem have a bad history of CVEs, being leaky about being PHP is not cool).
Java/Kotlin/Go/Rust/Ruby/Python/JS/TS are a lot less leaky about what language the server-side is written in. Usually the webserver used advertises itself name and in a server string, but it is considered bad practice and thus often switched off.
Reading "php" extensions in paths is a clear giveaway, so are "htm" extensions for microsoft products. Tools usually guess the language/framework based on some of these giveaways and the better the tools the less this is evident.
I jut checked some web apps I worked on, and only the one I last touched 10+ years ago is detected with buildwith.com; it's a Rails site.
All the Java/Kotlin/Rust/Hasura+Elm apps I worked on since are now shown as "Nginx" (the rev proxy in front of it).
While it kind of is security by obscurity, it's a very basic piece of server hardening to stop telling potential attackers what software you're using (within reason).
Back in the day (!), server software used to honestly respond with things like the software name and exact version number it was running.
Naturally, that meant scanning for vulnerabilities was a lot easier than it needed to be.
Not true. There are some real cryptographic realities that are based in "open" math principles.
There's also the way of most using runtimes/libraries that (constantly) have CVEs in them; and understanding why it is that these languages have CVEs in the first place (see my comment on "eval()").
obviously being properly secure is better. but if you leave your unlocked, it's better to not also hang a sign above it saying "this door is unlocked".
obscurity is absolutely part of good security practice, as long as it's not all you're relying on.
> How is being “leaky” in any way bad or even good?
Information-gathering is a common early step in any attack against a system; knowing the language & libraries involved (especially their versions) allows you to search for any existing CVEs that apply.
> Are you advocating “security by obscurity”?
I don't think OP was implying that security by obscurity alone is sufficient, just that it's unwise to advertise information that's not relevant to end users, that could help would-be attackers.
If you languages has "eval()" or something similar, it is a lot easier to attack. Same for when it allow you "upload a file in some place where it gets executed".
These things are not so easy, say, with a C++/Rust/Go app. Or even in most JVM configurations. JS has similar issues, that Deno is trying to mitigate to some extend.
I just checked the day gig site... builtwith claims it's using Webflow and Apollo GraphQL (Neither of which it is) and doesn't mention at all the language it's actually implemented in (Python), although that's not surprising since it's an in house framework.
If people are picking up non-JAMstack solutions for greenfield web development, then that means JAMstack is just one of many options for "modern web development". (Along with Laravel, Rails, Django, and even/especially Wordpress, depending on how we gatekeep what we mean by "web development")
>80% of the internet still runs on PHP on traditional servers.
Do they? Or do they just use Wordpress? This is important to differentiate because people's idea of PHP on traditional servers ITT is a far cry from setting up wordpress.
what vendor lock in? Netlify at its core is still quite simple: pull stuff in from GitHub/Lab, run the build commands in an Ubuntu VM and publish the results.
Sure, there are some plugins that you can use to transmute the result builds and there's Edge functions, but nothing is hard to move to another provider.
Netlify worked for me when all we did was basic static hosting for about $500 a year. Then they wanted to up us to about 10k a year and suddenly the cost was significantly worse. The only reason we didn't dump it is because we didn't have enough engineers to swap it to something else because we had projects that needed to be done, but it was our top optional priority.
Unfortunately netlify went from loved to hated overnight.
Yo. Thanks for Netlify. It’s legit and I, for one, welcome our new overlords.
All jesting aside it’s easily one of the most pleasant developer experiences you can have as a modern web dev in 2023. Everything just works and failures are loud, obvious, and usually dead simple to fix.
I've been doing web development since 1997, but posts like these let me know how far out of the loop I have become. I have no idea what Jamstack, Netlify, Headless CMS, etc. even are. I'm still in the: here is a webpage (html, css, js) that makes an ajax/fetch call to a webservice that SQL queries a Postgres database and returns the results as a JSON string.
Honestly, I've just finished 5 years as CTO with an e-com company with our CMS built on Elixir and I can't tell you how wrong you are. Jamstack, headless CMS and SPA frontends etc are just a massive waste of time. There's no joy in having separate code for your API and frontend.
Sure: key idea is pages are documents. Each page contains a JSON blob which specifies the blocks it's made up of and the content for each block. Each block is just a module with a schema specifying the data it takes and an associated template and a render function. Rendering a page is a URL resolution -> Controller -> DB lookup for the page -> pass the block list to a master render function and done.
The thing some people don't realise is EEx is compiled to a function call, which means no string interpolation, regex whatever. Getting a bunch of HTML is just a function call.
I worked at an ecom that used Elixir instead of an spa, with the backend being the older legacy app, and elixir rendering pages based off API data from the backend. This was well before live view
It worked amazingly fast. Some things were painful, and would have been better served with some progressive enhancement via a dollop of frontend js, but they were rather small exceptions
When I left a few years back they'd undergone some leadership turnover and the new wanted to migrate to some messy jamstack thing. They had millions of SKUs. Last I heard they migration hadn't gone anywhere
Tale as old as time lol. Elixir is uniquely great at content sites due to the fast template rendering - but it’s really not about Ex at all. Just don’t drown in unnecessary moving parts and build tools. It’s just a website.
LiveView wasn’t ready yet when I started our startup (react on front, Elixir and Hasura on back).
But man, I wish it had been. React is nice enough but the idea of not having to redefine my types at several different layers and fight with npm sounds like a dream.
We were in a similar position. CMS ran on dead views with a bit of progressive enhancement first, and then we had a couple of react apps around for interactive parts. When liveview was released we tried it out and it basically “just worked” as much as a software lib can, so set about getting rid of the react.
Jamstack is "Modern Web Development"? Are we back to that point in the webdev rollercoaster where everyone pretends like embedding business logic in a client using javascript is a good idea?
FWIW, I love you, Netlify CEO. I've got a bunch of different static-ish websites hosted with you---my personal site, the sites for three different books, etc., etc. Everything is build using the CI, with a different frameworks and/or build processes (essentially whatever I felt like playing with at the time), and it makes it incredibly easy and cheap. So don't listen to the haters.
> I would actually argue that Jamstack has won to the point of basically just being "Modern Web Development" by now.
Don't you think there might be just a little bit of hubris creeping in here? JAMSTACK is such a niche/fringe it's not worth talking about. I'm a solo dev and network with many others. I don't think I've ever heard JAMSTACK mentioned let alone adopted. You're living in a self-generated bubble.
I don’t really understand the concept of Jamstack or why it’s new. Isn’t it just HTML+JS (whether built with a framework such as Angular, React, Svelte, Gatsby, etc) that uses a backend api? What exactly are we discovering? What is the innovation here? Markdown?
I used to teach computer science to kids, and I had middle school kids setting up their own website with GitHub pages and buying their first personal domain. Firebase is also pretty amateur-friendly (although certainly more bloated than its early days) and I've seen novices deploy real-time apps with authentication, storage, server-side functions, etc.
For professional software work, the dominating reason I favor a decoupled architecture is so I can have a frontend team and a backend team. I want the frameworks and existing libraries/processes/tools to lean on, so I can minimize how much engineering time is spent on reinventing wheels.
In my experience, the web has bifurcated between "web applications" (owned by React) and content sites (owned by Jamstack).
One dilemma I've faced is when you find yourself in the middle of those two areas and might want to develop an MVP in Jamstack to later add more web-appy features. Jamstack always left me feeling like it was sufficient for my current use case, but with much more complexity I was always one errant feature request away from running into something I couldn't do and having to rewrite everything.
Furthermore, just doing simple things can require significant creativity on how to achieve that. It's fun, because the end result is something that's significantly more performant than anything you could squeeze out of React. I happily use Jamstack for my blog (FCP of 0.8s, Lighthouse score of 100!), but would feel reckless suggesting it for any professional work that I do outside of company blogs or something.
2. The complexity he's talking about isn't obligatory. No one is forcing you to use any complex architectures, when markdown + a SSG is what you need for your use case. Neither is Netlify, they would support that actually.
3. JAMStack is a very elegant solution for a big chunk of websites, compared to having a dynamic server rendering the webpage again and again for every request.
I'm not sure what his beef with github pages is either.
I host my personal site on ghp. It's a nuxt.js app. I push code up, a Github action sees it, builds it, and deploys to the pages. The end. The build yaml is maybe 30 lines total
Okay, I probably didn't understand JAMstack, even though I say to folks that I use JAMstack. I am not a professional web developer, but this is the reason why I thought I was using JAMstack:
The reason I like JAMstack is because:
- It is free.
- It adds modularity to a static site.
- If you want to provide an API service and your website just makes the API data look pretty.
It is free.
Netlify is free to sign up without a credit card. What else would you like me to mention? Everything else costs $5 a month or more. I am cheap. Cloudflare is free, Firebase is free, etc.
Modularity in a static site generator.
You know what is really cool and just works? Good static site generators. But sometimes, I would like to add some technical features to it, for SEO or fun. I would like to add components that focus on server-side computation a bit. However, it is not easy to do when you start with a static site.
So, what I will do is simply write an API and connect it to the site with a simple API call. I can handle all the complicated tasks in the backend and send some data to my website, where it will be displayed in a table.
If you want to provide an API service and have your website display the API data in a visually appealing way, this may not apply to most people. However, in my line of work, I used to focus on building APIs exclusively. People were not interested about the how site looked. They sometimes required authentication, a table, and some visualization and sorting features.
To simplify the process, I would handle most of the tasks on the backend, with the website mainly fetching data from the API. It would consist of templating syntax and occasionally handle state management, as it was not practical to filter the data on the backend.
---
So, that is how I used JAMstack. Can I do better? Eh, not really. I am not a web developer. I build APIs that sometimes need some visual representation. With Netlify Auth, Netlify Function supporting Go, Cloudflare Pages, etc., I don't see myself throwing in the towel on JAMstack, even though I might be missing the entire point here.
Embracing the two-year cycles that web developers have about everything being bad and everything being shit is not for me. And yes, this is a cycle, and this is a fit. You will see after two years, some dude with 120K followers on Twitter will announce "we have re-embraced everything that is wrong with PHP because of 4chan memes, and here is this web5 stack that will fix everything."
In web development, the only people I respect are those who have been using a 5-20 dollar/month VPS for more than a decade. They are not on Twitter, don't check HN except for weekends and they don't even do webstack-evangelism.
(Render CEO) Funny story. I first used Netlify in 2017 after being thwarted repeatedly by S3+Cloudfront deploy hacks. I loved the product so much I became a vocal advocate and eventually decided to build the same DX for the entire application stack. When Render first launched, it didn't have static sites because we assumed developers would just use Netlify with their Render backend; unfortunately at the time (but fortunately these days) our customers have always wanted everything under one roof, so I begrudgingly built static sites into Render in late 2018.
However, to this day, Netlify's static site product remains ahead of Render, and we haven't invested as heavily in it as other products in our portfolio. Why? Because static site hosting is now a commoditized market, and we can differentiate ourselves better elsewhere. Netlify sees this too and is changing course accordingly (based on bobfunk/Matt's comment above). I know they will be successful, and they deserve all the good things that come their way because they've materially advanced web development over the last several years (even inspiring ZEIT to pivot into Next.js+Vercel).
Jared: I think your beef might actually be with serverless compute and the restrictions that come with it, especially when vendors try to force it down developers' throats as the only way to build apps. The A in JAM can (and often should) be a long running server instead of a thin Lambda shim, but Netlify is a lot less guilty of pushing this narrative compared to their peers.
Love Render and Netlify. I've been meaning to try Render's capabilities for static websites but Netlify has just worked so far that I haven't bothered yet.
Original author here, and I appreciate your perspective! Interesting to know the connection of how one shift in the market helped influence another.
A couple of short thoughts:
> offer everything under one roof
To me this is THE value prop. I don't want to deal with the headache of setting up multiple providers and API services and a pandora's box of integrations just to get a straightforward project up and running. In addition, I ideally want my production software choices to mirror what I can run on my local machine. The fact I can run PostgreSQL/Redis/Ruby/Node/SSGs/whatever here, and then push it all up somewhere and expect that It Just Works is fantastic. Bonus that it's all just accessible FLOSS tooling for the most part.
> I think your beef might actually be with serverless compute and the restrictions that come with it
That is indeed a beef I have…not that there aren't good uses for FaaS architecture, but it's just generally not been anything that solves real problems I have besides simply spinning up a "boring" monolith. Certainly we can't say it's all Netlify's fault this became a big buzzword, but let's be honest: it's been a real slog to claw back recognition and mindshare that server processes are pretty cool actually, and Netlify certainly hasn't helped in this regard. You guys, Fly, Railway, and plenty of other hosting companies out there are innovating in this space, and it's truly great to see.
There's value in that, but I think dealing with two vendors (web servers and database) is not terrible, based on my limited experience so far as a hobbyist developer with Deno Deploy and Neon.
The differences between Deno running locally and Deno Deploy can be a bit annoying, such as not supporting npm's on Deploy yet. I expect that will improve.
My development environment is pretty light: Deno itself and VS Code. So far I haven't needed to set up a database locally, or even install any client-side Postgres tools. (The database driver is an npm library that wraps fetch.)
I used render for a bit and I have to say, basic static site building is more than enough. What you had perfectly met the needs I had for netlify so I got to save a ton.
My biggest issue with render was lack of command line tools that allow you to do things like change env vars during builds. It was the biggest hurdle for me.
I'm rooting for you guys. I see tons of potential.
I, like I assume everyone else who read this article, was interested in Render so I clicked through and started perusing the docs. I don't understand at all how secrets are meant to be managed by secret files when deploying docker containers. The secret sauce (haha) of secret files is that they don't survive the layer they're used in. How is that going to help at runtime? For accessing private repos to compile your go app in a build layer, sure. Hitting the DB or another API with a bearer token though? Seems like a non-starter. The docs even reference this
> Unlike build args, secret mounts aren’t persisted in your built image.
The doc you saw refers only to how secret files are treated at build time.
At runtime, Render mounts your secret file at `/etc/secrets/FILENAME` in your container. Your application can then read it like any other file on the local filesystem.
Of course, you can always store your secrets in Render environment variables and use them via ENV statements at runtime.
147 comments
[ 4.2 ms ] story [ 197 ms ] thread> Things which used to take hours or days to accomplish in standard Rails or Laravel or Django apps—most of this stuff isn’t rocket science, folks—now took weeks or months! Progress!
This article is too much of a narrative to be coherent about issues with Netlify + the Jamstack... and also too verbose of a narrative to be readable. I'd skip it, but maybe you'll find it entertaining.
if netlify is being portrayed as the only platform to deploy a statically generated site from git commit, then i suppose yes, the sane defaults of these frameworks are not the right tool _for you_.
I replaced all this crazy setup with vanilla tools. I moved my webpage (a bunch of html pages and other files) to my VPS. I modified nginx to submit incoming html form submissions to my CGI bash script which then in turn adds them to a sqlite database and emails me.
There is no automatic rebuild. I wrote makefiles to rebuild and publish my pages in a few seconds.
It turns out I didn't need anything else, and above all I didn't need to spend time learning someone else's APIs.
Sure I can agree these tools are worth learning, I'm just pointing out it's not the same thing. Netlify allows you to setup a static website with data collection, e-mail dispatch and whatnot all without code and much faster.
Netlify wants developers to live and breathe microservices that they meter to developers. In order to get the benefits, you have to change DX, which the entire JAMstack community has been doing for a decade or so. The downside is now putting stuff on the web is often needlessly confusing and forces you to be dependent on a middle man.
True, and it's been a rewarding decision ever since. For a corporate or a community Netlify or similar JAMstack content management systems might make sense, but for a indie developer? I don't think so.
https://raw.githubusercontent.com/mehdisadeghi/mehdix.ir/mas...
'Sounds like something out of the pre-Perl era. Not saying you can't get it to work but .... why when there's a ton of micro-frameworks such as Roda (Ruby) and FastAPI (Python) which can handle this in a couple of lines of code?
I've been developing with React for 10ish years now. My most recent startups have been a mixture of React front-ends that call to a variety of backend services. Most recently using Vercel and Next.js to host our frontend codebase.
One of our lead engineers setup an NX monorepo. We deploy an API to AWS and our front-end to vercel. This has honestly added so much unnecessary complexity, I really regret it. Here's the main issue as I see it:
Conflating a fullstack web application, with a decoupled UI and a standalone API.
It's the same old conversation about "microservices" and knowing where to draw the boundaries. In my experience "frontend" and "backend" are not really good boundaries.
Sometimes there needs to be a high degree of coordination between frontend and backend. In this case, they should probably be part of a fullstack deployment like Rails or Django, or my personal favorite: Remix.
Personally, I think all web applications should start out with the assumption they are a monolith. Only after the product is starting to reach maturity, and weaknesses in the monolith are revealed, should a backend api or a decoupled front-end be split off.
Vercel and Netlify (among others) try and avoid the basic necessity of databases and other backend complexities as if a front-end developer can exist in some shining, pretty land free of that yucky backend stuff.
I hope the NodeJS world can turnout something as turnkey and well-supported as Rails, but I haven't really seen it yet.
The choice of stack really just depends on the project, and the skillsets of developers in that community + the available tools in that community.
[1] https://www.reddit.com/r/nextjs/comments/139j19t/shall_we_co...
By 'monolith' are you still talking about a Rails/Django/Remix/(Next.js?) app? (Or ASP.NET for my dotnet homies out there).
I don't understand where the complexity is in your setup that you're unhappy with.
Furthermore, in our case, the front-end and backend are really coupled, so having these as separate systems is just a big headache. All of the web app's views are tied into specific backend functionality, and our API doesn't really stand on it's own without the front-end.
Yes this is poor architecture. I'm just pointing out a case where JAMStack was a mistake. Rails (or similar) would have been a smarter choice.
If you want more coupling, perhaps you could try something like ts-rest to add API types to your frontend. Or if you're feeling more adventurous, GraphQL or tRPC, though I personally prefer to avoid being tied to overly experimental frameworks.
Next.js has saddened me since the move to SSR. I think remix is light-years ahead to be honest.
I will give ts-rest a look-see.
They are creating the disease and selling you the cure. You see less monoliths in the node community because it's the only ecosystem where the attempting to build a monolith takes you off of the happy path. Most tools and frameworks not-so gently nudge you in the SPA + back-end-as-a-service direction and make the simple thing hard.
As i understand you guys, you're talking about the difference between writing an API server vs writing a web app, that delivers the view, instead of an API. What exactly makes one leave the happy path? Using a template language?
All that complexity is not that useful imo.
If you need SSR you probably should pick the right tool for the job (not react) to begin with. If you need a simple static site you don’t need all this cruft either.
Am I wrong? I just don’t see where I’d use these tools and I’ve used them all before to try it out.
Fwiw my startup is keeping it simple with a go backend, sveltekit, and flutter iOS/android.
Now that said, I think a ton more stuff can (and should) use SSG than SSR. This is IMHO the killer feature that Next.js makes easy to do.
tried svelte, vue, I don't feel react is more complex, if at all.
Keeping it simple would just be using Laravel and then Flutter for mobile front ends.
And Go is good for all the other things like real time and as a general language.
all i will say for now is that the Jamstack movement was a champion of simplicity on the web, and I hope that there's an equally powerful voice in the current move towards React Server Components and distributed-system-in-your-frontend trends.
In other news I can still access most of the useful web, Usenet, IRC and mailing list archives going back to the early days of the internet.
Stop using Discord for anything non-frivolous.
Readers, it was so AWESOME to write spaghetti JS in one file. Do a little manual code organization. Name things sensibly. Write comments. Communicate.
Everything we did could be shimmed into a react app fairly quickly, but why? Our goal was to get something out the door that performed an intuitive feature-set and we did it. We didn't have to fiddle with dependencies, or start thinking in 'library mode' when you search NPM for something instead of just coding it yourself. Just make the thing that works. If you suddenly have to scale your team and need to refactor to a common framework in order to support dev onboarding, that is an incredibly fortunate position to be in and a good problem to have.
I had to maintain a 80k line angular.js single file directive in my first company.
Definitely not AWESOME to maintain it though So yeah you are definitely right.
My point, which I'm sure I articulated poorly, was that we found ourselves highly productive by simply using the tools and API provided in the modern browser and a text editor.
Once you have an admin panel and a CMS and a WYSIWYG editor, maybe get yourself a framework you'll start hating in a few years.
wikipedia:
Sovereign is a title that can be applied to the highest leader in various categories. The word is borrowed from Old French souverain, which is ultimately derived from the Latin superānus, meaning 'above'.
The roles of a sovereign vary from monarch, ruler or head of state to head of municipal government or head of a chivalric order. As a result, the word sovereignty has more recently also come to mean independence or autonomy.
but then you have to actually make it a functional part of a business with tests and regulatory compliance and integration with other products and customer requirements, and new developers who didn't build the original demo start working on it, and then you remember why all that complicated and inconvenient tooling exists. just building demos and then abandoning them doesn't pay a whole lot of bills, unfortunately.
[0] https://swarm.workshop.perforce.com/view/guest/perforce_soft...
Haven't used Gatsby but in theory every SSG should produce output that is usable without JS.
It all depends on the components then, which, well, shouldn't use client-side JS for rendering essential HTML if you want to work them without it.
Zola is a static site generator and it’s crazy fast, using one binary only [2], also there’s Blades [3], same concept but supposedly faster, never tried it though.
[1] https://github.com/emilk/egui
[2] https://www.getzola.org
[3] https://getblades.org
>it costs less
That's only true if you have low traffic in which case why not host from a $50/mo (at most) VPC? If a business can pay your salary then surely they can afford an extra $50/mo cloud costs.
>you don't have to manage servers
However now you have to learn to write serverless functions that will execute in an environment fundamentally different from your local machine making it more difficult to develop. So you've reduced time spent in devops and increased time spent in development.
>reduced time spent in devops and increased time spent in development
This may be true if you’re trying to figure out how to do something you already know how to do outside of serverless, but IME many developers benefit from serverless eliminating boilerplate and nudging them away from state where it’s not necessary.
Also regarding cost and devops: I see serverless as an insurance policy against “my startup/product got a once-in-a-lifetime lucky break by going viral while I was asleep” causing you to fall over from a flood of traffic. Not only do you get to skip implementing your own scaling to go from 0-1 but you only pay substantially (vs the regular price diff) extra for it when it happens.
I remember evaluating the JAM stack years ago, and was underwhelmed. Like so many shiny new techs it didn’t really offer any big leaps forwards under the marketing and hype. People who lapped it up should think more critically about why they adopt tech.
What I dislike is the hype, people with sizeable bases acting irresponsibly about new tech. Encouraging early adoption, and spending so much time promoting it, funding conferences, and then after 5 years dumping all of it so you can "learn from your mistakes" to push for some new thing. It feels so dishonest, why would their current choice be any better if they made such reckless decisions not too long ago?
So you're right we really do need to think critically about new tech and give people the means to assess things critically without the hype.
You need to be able to take the good with the bad and analyze everything objectively.
Heroku is dead to me and in the mean time, i'm using SPA to serve my customers really well and fast !
I have no clue what you're talking about.
He also discusses Netlify and Render feature sets. While both services allow to do more than just a stateless JAMStack, they both have too much vendor lock-ins, and offer too little to make people take that functionality seriously. For example, Render supports Docker containers, but they are tied to a single region only. This is probably enough for hobby projects, but it's a show stopper for commercial deployments.
In my opinion, author drank too much Heroku-aid in his conclusions.
The vast, vast majority of commercial deployments are single region, as evidenced by the occasional failure of us-east1.
https://sst.dev
I would actually argue that Jamstack has won to the point of basically just being "Modern Web Development" by now.
In the 7 years since I first presented the term at Smashing Conference in San Francisco, I can't think of a single new successful commercial CMS that hasn't been headless or API first. I can't think of a single new successful commerce platform that's launched in that period, that hasn't been headless or API driven.
On the contrary, big existing players have mostly changed their strategy. Shopify is more and more embracing a decoupled approach of building globally distributed shop UI's with Remix (running either on their own platform or places like Netlify or Cloudflare) pulling in products, pricing and check out flows from their API layer. Most existing CMS companies have started integrating API first approaches into their strategy and in the data space we've seen an explosion of "Database as API" from Neon, to Supabase, to Xata or Converx, etc...
Part of the confusion has always been the conflation of Jamstack with "static" when even my first presentation on Jamstack back in 2016 had a big slide with the word static crossed out to underline that I personally didn't intend to conflate the two. The real game changer for treating the web UI as it's own decoupled application, and the backend as a set of API and services where some are your own running your core business logic, but a lot of them are provided by external providers.
At Netlify we're now focusing less on evangelizing the Jamstack approach of treating the web UI as it's own decoupled, independent layer, running on top of API's rather than stuffed into your backend systems - and more on helping really large companies adopt this at scale for their core web architectures (Composable Architectures). But not because we're any less bullish on the first part, on the contrary - because we don't really have to anymore!
And the article's conclusion that we somehow failed is absurd. Sites and apps on Netlify are visited by more than a billion unique visitors a month, we delivered more than 10 Petabyte of data out of our network in December alone, have onboarded more than 4 million developers to our platform, and continue to prove that we can scale this architecture to some of the largest and most complex companies in the world, running big complex projects with faster time to market, higher productivity and higher conversions and revenue.
[1] https://feedback.render.com/features/p/docs-on-how-renders-l... [2] https://devcenter.heroku.com/articles/scaling#autoscaling [3] https://devcenter.heroku.com/articles/http-routing#request-d...
You also don't address the OP's points where Netlify has suffered the same fate of "enshitification" where features slowly get stripped out and moved into pay to use buckets, likely at the behest of needing to payback 100+ million dollars in VC funding.
We are also building a real, longterm sustainable enterprise business. We're not a non-profit and we're here to create a big lasting company that can keep investing into the future of the web.
Almost every feature you charge for is something you can achieve for free inside of a basic VPS. I understand you have the classic SV "Hotel California" model where you can check in but you can never leave. But frankly this makes the internet worse in every way possible and part of the point of the original article.
I struggle with even Digital Ocean and just want my site to freaking run.
Downvote me all you want, but I'd rather ship features than fuddle with infrastructure.
Digital Ocean in particular has great guides to get you from the starting line to something that in most cases will work okay, but as a long-term solution to “I have an app I want to run on some infrastructure”, I agree that there’s a non-zero cost to managing a server that, like you, I’d much rather not deal with.
Seriously, it is orders of magnitude faster to deploy a static website on Netlify - simply drag and drop a folder from desktop - than it is to spin up just a single VPS on Vultr… and by the time you’ve configured that VPS, I could have done a dozen revisions to the website, and it would still be more difficult to deploy updates to the VPS than to Vultr. Don’t even get me started on the complexity of a global CDN.
Do I wish all of Netlify was free? Sure, yes I do. Does this mean it’s not valuable? Of course not.
The irony of this is that you seem to be saying that (a) Netlify locks the customer in with useless features, and (b) it can be trivially reimplemented in an entirely custom but otherwise “free” VPS.
The real question is, which “free” VPS are you going to use that will serve the same capacity as Netlify’s paid plans? AWS? Do you think you can avoid lock-in using AWS - of all things?!
Also, by your own standards this is a comparison between a paid Netlify account and a free VM. Right?
> Almost every feature you charge for is something you can achieve for free inside of a basic VPS
I have plenty of experience with both Netlify and VMs, and I don't think they are even remotely comparable.
> You can search all of this yourself with all of one google query.
You're the one making the claims - I'm not even sure what I would be searching for since the parameters of a VM are vastly different to those for Netlify. How could I even find TTFB for a free Oracle VM? In fact, my personal experience with Oracle VMs (granted it's from before 2018) is that the jitter would be very high, such that any TTFB would probably be meaningless. And it would depend on the deployment region, too. Not to mention the HTTP server being used.
Words are cheap. Unless you're willing to substantiate your claims with some actual facts, nobody learns anything.
Netlify’s free plan is awesome. You might get more bandwidth with a VPS. But you won’t get a CDN and you won’t get atomic deployments without a bunch of work. You’ll use half your VPS storage on the operating system. You’ll need to keep updating your software and maintaining backups. You’ll spend hours or weeks a year maintaining this thing, versus zero for Netlify.
It’s not just about the cost of bandwidth or storage. You gotta compare like with like.
1. Full server control (install any package) 2. Host any kind of server - Django, Rails, etc. etc. 3. Run database servers: MySQL, PostgreSQL, MongoDB, etc. 4. Background processes (cron or systemd) 5. Run VPNs and proxy servers for personal use at the same time. 6. Host email servers 7. Multi-purpose usage (Use for remote dev environments, cloud storage, AI/ML platforms, etc.)
All. For. *Free*.
Netlify has done nothing but innovate and push the needle forward for front-end devs. I’ll be there until there’s a VERY strong reason not to be.
i'd be curious to know what portion of websites they scan they know this for.
Java/Kotlin/Go/Rust/Ruby/Python/JS/TS are a lot less leaky about what language the server-side is written in. Usually the webserver used advertises itself name and in a server string, but it is considered bad practice and thus often switched off.
Reading "php" extensions in paths is a clear giveaway, so are "htm" extensions for microsoft products. Tools usually guess the language/framework based on some of these giveaways and the better the tools the less this is evident.
I jut checked some web apps I worked on, and only the one I last touched 10+ years ago is detected with buildwith.com; it's a Rails site.
All the Java/Kotlin/Rust/Hasura+Elm apps I worked on since are now shown as "Nginx" (the rev proxy in front of it).
Every programming language has holes, its just that with PHP the attack surface is much larger, so i guess people find more holes, etc..
Are you advocating “security by obscurity”?
Back in the day (!), server software used to honestly respond with things like the software name and exact version number it was running.
Naturally, that meant scanning for vulnerabilities was a lot easier than it needed to be.
There's also the way of most using runtimes/libraries that (constantly) have CVEs in them; and understanding why it is that these languages have CVEs in the first place (see my comment on "eval()").
obscurity is absolutely part of good security practice, as long as it's not all you're relying on.
Information-gathering is a common early step in any attack against a system; knowing the language & libraries involved (especially their versions) allows you to search for any existing CVEs that apply.
> Are you advocating “security by obscurity”?
I don't think OP was implying that security by obscurity alone is sufficient, just that it's unwise to advertise information that's not relevant to end users, that could help would-be attackers.
These things are not so easy, say, with a C++/Rust/Go app. Or even in most JVM configurations. JS has similar issues, that Deno is trying to mitigate to some extend.
How is it vendor lock-in when I can easily move my JS app to Render.com, AWS s3, Cloudflare, etc?
Do they? Or do they just use Wordpress? This is important to differentiate because people's idea of PHP on traditional servers ITT is a far cry from setting up wordpress.
Sure, there are some plugins that you can use to transmute the result builds and there's Edge functions, but nothing is hard to move to another provider.
Unfortunately netlify went from loved to hated overnight.
All jesting aside it’s easily one of the most pleasant developer experiences you can have as a modern web dev in 2023. Everything just works and failures are loud, obvious, and usually dead simple to fix.
Well done, says I.
Our pages rendered in 20ms.
The thing some people don't realise is EEx is compiled to a function call, which means no string interpolation, regex whatever. Getting a bunch of HTML is just a function call.
It worked amazingly fast. Some things were painful, and would have been better served with some progressive enhancement via a dollop of frontend js, but they were rather small exceptions
When I left a few years back they'd undergone some leadership turnover and the new wanted to migrate to some messy jamstack thing. They had millions of SKUs. Last I heard they migration hadn't gone anywhere
But man, I wish it had been. React is nice enough but the idea of not having to redefine my types at several different layers and fight with npm sounds like a dream.
Don't you think there might be just a little bit of hubris creeping in here? JAMSTACK is such a niche/fringe it's not worth talking about. I'm a solo dev and network with many others. I don't think I've ever heard JAMSTACK mentioned let alone adopted. You're living in a self-generated bubble.
I've been in web dev for the past 10 years and none of the companies I've worked at in San Fran use this tech.
I'm familiar with the space: Gatsby, GraphQL, etc. I took a Jamstack course on frontendmasters, but I chose to skip using it for personal projects.
For professional software work, the dominating reason I favor a decoupled architecture is so I can have a frontend team and a backend team. I want the frameworks and existing libraries/processes/tools to lean on, so I can minimize how much engineering time is spent on reinventing wheels.
One dilemma I've faced is when you find yourself in the middle of those two areas and might want to develop an MVP in Jamstack to later add more web-appy features. Jamstack always left me feeling like it was sufficient for my current use case, but with much more complexity I was always one errant feature request away from running into something I couldn't do and having to rewrite everything.
Furthermore, just doing simple things can require significant creativity on how to achieve that. It's fun, because the end result is something that's significantly more performant than anything you could squeeze out of React. I happily use Jamstack for my blog (FCP of 0.8s, Lighthouse score of 100!), but would feel reckless suggesting it for any professional work that I do outside of company blogs or something.
Jamstack is used on less than 10% of websites i would guess.
1. JAMStack is not Netlify.
2. The complexity he's talking about isn't obligatory. No one is forcing you to use any complex architectures, when markdown + a SSG is what you need for your use case. Neither is Netlify, they would support that actually.
3. JAMStack is a very elegant solution for a big chunk of websites, compared to having a dynamic server rendering the webpage again and again for every request.
I host my personal site on ghp. It's a nuxt.js app. I push code up, a Github action sees it, builds it, and deploys to the pages. The end. The build yaml is maybe 30 lines total
The reason I like JAMstack is because: - It is free. - It adds modularity to a static site. - If you want to provide an API service and your website just makes the API data look pretty.
It is free.
Netlify is free to sign up without a credit card. What else would you like me to mention? Everything else costs $5 a month or more. I am cheap. Cloudflare is free, Firebase is free, etc.
Modularity in a static site generator.
You know what is really cool and just works? Good static site generators. But sometimes, I would like to add some technical features to it, for SEO or fun. I would like to add components that focus on server-side computation a bit. However, it is not easy to do when you start with a static site.
So, what I will do is simply write an API and connect it to the site with a simple API call. I can handle all the complicated tasks in the backend and send some data to my website, where it will be displayed in a table.
If you want to provide an API service and have your website display the API data in a visually appealing way, this may not apply to most people. However, in my line of work, I used to focus on building APIs exclusively. People were not interested about the how site looked. They sometimes required authentication, a table, and some visualization and sorting features.
To simplify the process, I would handle most of the tasks on the backend, with the website mainly fetching data from the API. It would consist of templating syntax and occasionally handle state management, as it was not practical to filter the data on the backend.
---
So, that is how I used JAMstack. Can I do better? Eh, not really. I am not a web developer. I build APIs that sometimes need some visual representation. With Netlify Auth, Netlify Function supporting Go, Cloudflare Pages, etc., I don't see myself throwing in the towel on JAMstack, even though I might be missing the entire point here.
Embracing the two-year cycles that web developers have about everything being bad and everything being shit is not for me. And yes, this is a cycle, and this is a fit. You will see after two years, some dude with 120K followers on Twitter will announce "we have re-embraced everything that is wrong with PHP because of 4chan memes, and here is this web5 stack that will fix everything."
In web development, the only people I respect are those who have been using a 5-20 dollar/month VPS for more than a decade. They are not on Twitter, don't check HN except for weekends and they don't even do webstack-evangelism.
However, to this day, Netlify's static site product remains ahead of Render, and we haven't invested as heavily in it as other products in our portfolio. Why? Because static site hosting is now a commoditized market, and we can differentiate ourselves better elsewhere. Netlify sees this too and is changing course accordingly (based on bobfunk/Matt's comment above). I know they will be successful, and they deserve all the good things that come their way because they've materially advanced web development over the last several years (even inspiring ZEIT to pivot into Next.js+Vercel).
Jared: I think your beef might actually be with serverless compute and the restrictions that come with it, especially when vendors try to force it down developers' throats as the only way to build apps. The A in JAM can (and often should) be a long running server instead of a thin Lambda shim, but Netlify is a lot less guilty of pushing this narrative compared to their peers.
A couple of short thoughts:
> offer everything under one roof
To me this is THE value prop. I don't want to deal with the headache of setting up multiple providers and API services and a pandora's box of integrations just to get a straightforward project up and running. In addition, I ideally want my production software choices to mirror what I can run on my local machine. The fact I can run PostgreSQL/Redis/Ruby/Node/SSGs/whatever here, and then push it all up somewhere and expect that It Just Works is fantastic. Bonus that it's all just accessible FLOSS tooling for the most part.
> I think your beef might actually be with serverless compute and the restrictions that come with it
That is indeed a beef I have…not that there aren't good uses for FaaS architecture, but it's just generally not been anything that solves real problems I have besides simply spinning up a "boring" monolith. Certainly we can't say it's all Netlify's fault this became a big buzzword, but let's be honest: it's been a real slog to claw back recognition and mindshare that server processes are pretty cool actually, and Netlify certainly hasn't helped in this regard. You guys, Fly, Railway, and plenty of other hosting companies out there are innovating in this space, and it's truly great to see.
The differences between Deno running locally and Deno Deploy can be a bit annoying, such as not supporting npm's on Deploy yet. I expect that will improve.
My development environment is pretty light: Deno itself and VS Code. So far I haven't needed to set up a database locally, or even install any client-side Postgres tools. (The database driver is an npm library that wraps fetch.)
My biggest issue with render was lack of command line tools that allow you to do things like change env vars during builds. It was the biggest hurdle for me.
I'm rooting for you guys. I see tons of potential.
> Unlike build args, secret mounts aren’t persisted in your built image.
At runtime, Render mounts your secret file at `/etc/secrets/FILENAME` in your container. Your application can then read it like any other file on the local filesystem.
Of course, you can always store your secrets in Render environment variables and use them via ENV statements at runtime.