My journey away from the JAMstack
spicyweb.dev
spicyweb.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.
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.
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”?
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.
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()").
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.
obscurity is absolutely part of good security practice, as long as it's not all you're relying on.
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.
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*.
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.
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.
Unfortunately netlify went from loved to hated overnight.
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.
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.
Our pages rendered in 20ms.
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.
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.
[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...
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.
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.
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.
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?
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...
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.
By 'monolith' are you still talking about a Rails/Django/Remix/(Next.js?) app? (Or ASP.NET for my dotnet homies out there).
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.
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.
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.
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.
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.
> 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?
Use cases have not changed dramatically in the past decade yet there is constant churn. Some of it may be self-excited and basically just self-reinforcing fads, manias and other such noise which create its their own reality.
But some of it maybe due to some sort of degeneracy (seeking an optimum around a flat region). Maybe people ignore or poorly evaluate an important dimension (e.g complexity, long term mantainance costs etc) that if taken properly into account would reduce the ambiguity.
In any case this never ending debate needs to get a bit deeper to avoid going around in endless circles. It does not reflect well on the ability of the entire community to allocate resources in some thoughtful manner.
Every engineer has had unpleasant experiences with some giant convoluted messes. And there's a strong tendency to blame for that at the feet of the tools/stack/language of those messes, and believe that if we just choose something different, this time it will be clean and perfect.
Of course, some or all of that blame is undeserved. "Giant convoluted mess" is the state toward which every project will tend over time. But that rarely diminishes the totemic belief that new tools will produce different results, so an impetus toward novelty-for-novelty's-sake remains persistent.
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.
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.
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.
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.
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.
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.
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
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.
>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.
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.
[0] https://swarm.workshop.perforce.com/view/guest/perforce_soft...
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.
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.