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.
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.
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.
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.
>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.
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.
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.
> 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'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.
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
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.
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?
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.
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.
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 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?
(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.
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.
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.
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.
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.
> 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?
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.
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.
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…
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.
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.
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.
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.
> 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.
The never ending random walk of front end / 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 "right tool for the job" and let us move on to other challenges.
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.
I think an important driver in this is a persistent desire for (and faith in) novelty.
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.
To be honest there is never going to be an optimal solution here, because every 2nd engineer is gonna want to reinvent the wheel and do it their way, and then sell their “way” since they invested so much time into it.
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.
Readit News
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.
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.
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.
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.
Deleted Comment
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.
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.
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.
'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.