My journey away from the JAMstack

Netlify CEO and coiner of terms here :)<p>I would actually argue that Jamstack has won to the point of basically just being &quot;Modern Web Development&quot; by now.<p>In the 7 years since I first presented the term at Smashing Conference in San Francisco, I can&#x27;t think of a single new successful commercial CMS that hasn&#x27;t been headless or API first. I can&#x27;t think of a single new successful commerce platform that&#x27;s launched in that period, that hasn&#x27;t been headless or API driven.<p>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&#x27;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&#x27;ve seen an explosion of &quot;Database as API&quot; from Neon, to Supabase, to Xata or Converx, etc...<p>Part of the confusion has always been the conflation of Jamstack with &quot;static&quot; 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&#x27;t intend to conflate the two. The real game changer for treating the web UI as it&#x27;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.<p>At Netlify we&#x27;re now focusing less on evangelizing the Jamstack approach of treating the web UI as it&#x27;s own decoupled, independent layer, running on top of API&#x27;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&#x27;re any less bullish on the first part, on the contrary - because we don&#x27;t really have to anymore!<p>And the article&#x27;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.

(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&#x27;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.<p>However, to this day, Netlify&#x27;s static site product remains ahead of Render, and we haven&#x27;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&#x2F;Matt&#x27;s comment above). I know they will be successful, and they deserve all the good things that come their way because they&#x27;ve materially advanced web development over the last several years (even inspiring ZEIT to pivot into Next.js+Vercel).<p>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&#x27; 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.

This article isn&#x27;t the best, but I&#x27;m glad it is attempting to foster a conversation about the future of JAMstack.<p>I&#x27;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.<p>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&#x27;s the main issue as I see it:<p>Conflating a fullstack web application, with a decoupled UI and a standalone API.<p>It&#x27;s the same old conversation about &quot;microservices&quot; and knowing where to draw the boundaries. In my experience &quot;frontend&quot; and &quot;backend&quot; are not really good boundaries.<p>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.<p>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.<p>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 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).<p>Readers, it was so AWESOME to write spaghetti JS in one file. Do a little manual code organization. Name things sensibly. Write comments. Communicate.<p>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&#x27;t have to fiddle with dependencies, or start thinking in &#x27;library mode&#x27; 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 <i>think</i> this person is trying to say they moved from Netlify to Render, with some moderately insane, vague anecdotes, like:<p>&gt; 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!<p>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&#x27;d skip it, but maybe you&#x27;ll find it entertaining.

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.<p>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.<p>There is no automatic rebuild. I wrote makefiles to rebuild and publish my pages in a few seconds.<p>It turns out I didn&#x27;t need anything else, and above all I didn&#x27;t need to spend time learning someone else&#x27;s APIs.

The never ending random walk of front end &#x2F; back stack configurations suggests there might be some missing constraint. This allows a whole family of near equivalent approaches (at least superficially) but it fails to select the proverbial &quot;right tool for the job&quot; and let us move on to other challenges.<p>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.<p>But some of it maybe due to some sort of <i>degeneracy</i> (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.<p>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.

as a former advocate for Jamstack (<a href="https:&#x2F;&#x2F;www.swyx.io&#x2F;ideas?filter=jamstack" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.swyx.io&#x2F;ideas?filter=jamstack</a>) this has been on the cards for a while, and I&#x27;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.<p>all i will say for now is that the Jamstack movement was a champion of simplicity on the web, and I hope that there&#x27;s an equally powerful voice in the current move towards React Server Components and distributed-system-in-your-frontend trends.

The author&#x27;s problem arises from the inability to understand that JAMStack is tailored towards static content &#x2F; client-side apps. That&#x27;s it. Postgres, server logic, services etc all represent something else.<p>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&#x27;s a show stopper for commercial deployments.<p>In my opinion, author drank too much Heroku-aid in his conclusions.

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&#x27;ve seen novices deploy real-time apps with authentication, storage, server-side functions, etc.<p>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&#x2F;processes&#x2F;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 &quot;web applications&quot; (owned by React) and content sites (owned by Jamstack).<p>One dilemma I&#x27;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&#x27;t do and having to rewrite everything.<p>Furthermore, just doing simple things can require significant creativity on how to achieve that. It&#x27;s fun, because the end result is something that&#x27;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.

People waste so. Much. Time. On shiny tech, often just because it ends up on HN (or Tiktok or Insta).<p>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.

Did Netlify shut down the Discord without archiving any content? I wonder how much valuable knowledge gets flushed that way.<p>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.<p>Stop using Discord for anything non-frivolous.

Wonder how much of this is driven by the hundreds of millions of dollars of VC money put into stuff like vercel and similar.<p>All that complexity is not that useful imo.<p>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.<p>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.<p>Fwiw my startup is keeping it simple with a go backend, sveltekit, and flutter iOS&#x2F;android.

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).

I&#x27;m not sure what his beef with github pages is either.<p>I host my personal site on ghp. It&#x27;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 next time I try and do a serverless site I&#x27;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&#x27;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.<p><a href="https:&#x2F;&#x2F;sst.dev">https:&#x2F;&#x2F;sst.dev</a>

A couple weeks ago I did my portfolio site with React&#x2F;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.

Didn&#x27;t Fly.io recently nosedive in similar fashion? If so, that just leaves Render.

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 .

I use Netlify since multiple years for static site hosting on their CDN, partly using a headless CMS. It is a blast to use and I could not imagine how it can be any easier. For full-stack applications I would definitely consider Render, as I heard many positive reviews. For me, as a front-end developer, Jamstack and Serverless comes in very handy as I don’t have to spend time learning other programming languages, but Laravel looks very appealing to me, being opinionated and having a rich ecosystem.

I don&#x27;t understand the appeal of serverless.<p>&gt;it costs less<p>That&#x27;s only true if you have low traffic in which case why not host from a $50&#x2F;mo (at most) VPC? If a business can pay your salary then surely they can afford an extra $50&#x2F;mo cloud costs.<p>&gt;you don&#x27;t have to manage servers<p>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&#x27;ve reduced time spent in devops and increased time spent in development.

I don&#x27;t get his problem.<p>1. JAMStack is not Netlify.<p>2. The complexity he&#x27;s talking about isn&#x27;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.<p>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.

But... Netlify is not required to play JAMstack, is it?

Gosh, I was so excited to read something current about my favorite build tool suite [0] after all these years. Alas, it was not to be.<p>[0] <a href="https:&#x2F;&#x2F;swarm.workshop.perforce.com&#x2F;view&#x2F;guest&#x2F;perforce_software&#x2F;jam&#x2F;src&#x2F;Jam.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;swarm.workshop.perforce.com&#x2F;view&#x2F;guest&#x2F;perforce_soft...</a>

What&#x27;s.... dead ?<p>Heroku is dead to me and in the mean time, i&#x27;m using SPA to serve my customers really well and fast !<p>I have no clue what you&#x27;re talking about.

Okay, I probably didn&#x27;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:<p>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.<p>It is free.<p>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.<p>Modularity in a static site generator.<p>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.<p>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.<p>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.<p>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.<p>---<p>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&#x27;t see myself throwing in the towel on JAMstack, even though I might be missing the entire point here.<p>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 &quot;we have re-embraced everything that is wrong with PHP because of 4chan memes, and here is this web5 stack that will fix everything.&quot;<p>In web development, the only people I respect are those who have been using a 5-20 dollar&#x2F;month VPS for more than a decade. They are not on Twitter, don&#x27;t check HN except for weekends and they don&#x27;t even do webstack-evangelism.