13 ms·

My journey away from the JAMstack

178 points by brycewray 3y ago

deleted 3y ago
[deleted]
stevebmark 3y ago
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.
- zcmack 3y ago
  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_.
  - stevebmark 3y ago
    I don't think you read the article nor my comment lol
mehdix 3y ago
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.
- hagg3n 3y ago
  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.
  - efields 3y ago
    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.
  - mehdix 3y ago
    > 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.
    - cutler 3y ago
      But bash with CGI? Seriously, when there's Perl, Ruby, Python and PHP to choose from? 'Sounds like a security nightmare too.
      - mehdix 3y ago
        Because I wanted to learn more about CGI. Below is the script, I'd appreciate pointing out any weaknesses in it. https://raw.githubusercontent.com/mehdisadeghi/mehdix.ir/master/src/cgi-bin/submit https://raw.githubusercontent.com/mehdisadeghi/mehdix.ir/mas...
iamcasen 3y ago
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.
- cosmojg 3y ago
  So, would you recommend that newer startups just stick with a good old-fashioned full-stack monolith deployed on any old VPS?
  - iamcasen 3y ago
    Yes absolutely. I've been very impressed that Rails has managed to stay relevant all these years later. 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.
    - kodisha 3y ago
moomoo11 3y ago
Wonder how much of this is driven by the hundreds of millions of dollars of VC money put into stuff like vercel and similar. All that complexity is not that useful imo. If you need SSR you probably should pick the right tool for the job (not react) to begin with. If you need a simple static site you don’t need all this cruft either. Am I wrong? I just don’t see where I’d use these tools and I’ve used them all before to try it out. Fwiw my startup is keeping it simple with a go backend, sveltekit, and flutter iOS/android.
- freedomben 3y ago
  React can be super nice to use for SSR. When the site is small and/or simple (or even medium sized), React is definitely overkill. But if you have a big site (like lots of pages, or complex pages) then the component model that React brings can make it a ton easier. The rule of thumb I use is basically if I'm including/importing more than a few template pages, React can make it a lot more manageable. Now that said, I think a ton more stuff can (and should) use SSG than SSR. This is IMHO the killer feature that Next.js makes easy to do.
  - synergy20 3y ago
    I heard everyone saying 'react is for large complex project', somehow I think react is good for small project too: use a few components and its context api and dom-router to build a small site, the learning curve is actually not much comparing to other frameworks, what am I missing? tried svelte, vue, I don't feel react is more complex, if at all.
    - freedomben 3y ago
      Yeah compared to svelte, vue I think React is the way to go. For me the alternative for a small or medium project is a standard template system like Liquid (Jekyll), ERB (Rails) or EEx (Phoenix).
- gochi 3y ago
  Your startup isn't that different from what you're complaining about when it comes to complexity. You've just replaced next with sveltekit. Keeping it simple would just be using Laravel and then Flutter for mobile front ends.
swyx 3y ago
as a former advocate for Jamstack (https://www.swyx.io/ideas?filter=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.
andybak 3y ago
Did Netlify shut down the Discord without archiving any content? I wonder how much valuable knowledge gets flushed that way. 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.
efields 3y ago
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.
- gochi 3y ago
  It always feels better to write spaghetti.
  - yboris 3y ago
    There's code on his editor already, mom's spaghetti
- isanjay 3y ago
  Readers, it was so AWESOME to write spaghetti JS in one file 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.
- wintogreen74 3y ago
  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.
  - efields 3y ago
    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.
zitterbewegung 3y ago
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 .
ezekiel68 3y ago
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. [0] https://swarm.workshop.perforce.com/view/guest/perforce_software/jam/src/Jam.html https://swarm.workshop.perforce.com/view/guest/perforce_soft...
tamimio 3y ago
A couple weeks ago I did my portfolio site with React/Gatsby, while its performance was relatively good and better than say a wordpress page, but later I tried Zola and the performance is just much much better, in development or even as a user, plus now it works even with no JavaScript enabled in the browser. So I think react and the likes can be used but only when it’s the only tool that can make it, else, there are plenty of better tools.
- moritzwarhier 3y ago
  React and SSR are not mutually exclusive. I don't know what Zola is though and I like using static no-JS sites :) 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.
  - tamimio 3y ago
    Honestly, frontend development especially with all these crowded frameworks and libraries always confused me so pardon my ignorance, which is why in a project I’m working on right now I’m trying not to use js, instead I’m using egui [1] Zola is a static site generator and it’s crazy fast, using one binary only [2], also there’s Blades [3], same concept but supposedly faster, never tried it though. [1] https://github.com/emilk/egui https://github.com/emilk/egui [2] https://www.getzola.org https://www.getzola.org [3] https://getblades.org https://getblades.org
    - moritzwarhier 3y ago
      All power to you, sounds nice!
nusmella 3y ago
I don't understand the appeal of serverless. >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.
- potta_coffee 3y ago
  I've found some great use cases for serverless. None of those have involved hosting a backend for a website / web application. It's been a useful solution for automating some cloud management tasks though.
- weitendorf 3y ago
  Regarding cost, it can depend a lot on your traffic structure. If traffic is bursty, or substantially different between intraday peaks and troughs, it can be more cost effective. Solving this yourself costs dev time. >reduced time spent in devops and increased time spent in development This may be true if you’re trying to figure out how to do something you already know how to do outside of serverless, but IME many developers benefit from serverless eliminating boilerplate and nudging them away from state where it’s not necessary. Also regarding cost and devops: I see serverless as an insurance policy against “my startup/product got a once-in-a-lifetime lucky break by going viral while I was asleep” causing you to fall over from a flood of traffic. Not only do you get to skip implementing your own scaling to go from 0-1 but you only pay substantially (vs the regular price diff) extra for it when it happens.
davedx 3y ago
People waste so. Much. Time. On shiny tech, often just because it ends up on HN (or Tiktok or Insta). I remember evaluating the JAM stack years ago, and was underwhelmed. Like so many shiny new techs it didn’t really offer any big leaps forwards under the marketing and hype. People who lapped it up should think more critically about why they adopt tech.
- api 3y ago
  It seems like something that was designed to sell more cloud SaaS services: content hosting services, build services, etc. Instead of having one host for your site you now need three.
- gochi 3y ago
  I don't mind the churn, adopting new tech can be its own form of personal enjoyment. What I dislike is the hype, people with sizeable bases acting irresponsibly about new tech. Encouraging early adoption, and spending so much time promoting it, funding conferences, and then after 5 years dumping all of it so you can "learn from your mistakes" to push for some new thing. It feels so dishonest, why would their current choice be any better if they made such reckless decisions not too long ago? So you're right we really do need to think critically about new tech and give people the means to assess things critically without the hype.
- whalesalad 3y ago
  The problem with this attitude is that sometimes shiny new tech is awesome. I remember when nginx was shiny new tech and I had to deploy it into prod (back in 2007-2008) to prove that it was superior to Apache + mod_python. You need to be able to take the good with the bad and analyze everything objectively.
  - davedx 3y ago
    Well yeah that’s what I mean about thinking critically.
- cpursley 3y ago
  How is providing a github url and having your site live and distributed via a global CDN with zero fuss not a leap forward?
revskill 3y ago
What's.... dead ? 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.
nxpnsv 3y ago
But... Netlify is not required to play JAMstack, is it?
- garganzol 3y ago
  It's not required. And it's a big mistake to tie an app to a single vendor.
chmaynard 3y ago
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).
garganzol 3y ago
The author's problem arises from the inability to understand that JAMStack is tailored towards static content / client-side apps. That's it. Postgres, server logic, services etc all represent something else. He also discusses Netlify and Render feature sets. While both services allow to do more than just a stateless JAMStack, they both have too much vendor lock-ins, and offer too little to make people take that functionality seriously. For example, Render supports Docker containers, but they are tied to a single region only. This is probably enough for hobby projects, but it's a show stopper for commercial deployments. In my opinion, author drank too much Heroku-aid in his conclusions.
- politelemon 3y ago
  I'm getting a similar impression. This seems like a classic case of blaming the tools rather than figuring out the right tool to use. I have a suspicion that their journey isn't over.
- anurag 3y ago
  > For example, Render supports Docker containers, but they are tied to a single region only. This is probably enough for hobby projects, but it's a show stopper for commercial deployments. The vast, vast majority of commercial deployments are single region, as evidenced by the occasional failure of us-east1.
rcarr 3y ago
The next time I try and do a serverless site I'm going to use SST. The last time I tried making one, I got all the way to the end of the project using Pulumi only to realise that I couldn't do any tests of the severless functions locally which would have made things an absolute nightmare. I think the only way you can do this is using AWS SDK or SST. Something to be aware of for anyone wanting to go down this route. https://sst.dev https://sst.dev
bobfunk 3y ago
Netlify CEO and coiner of terms here :) 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.
- jmuguy 3y ago
  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.
primitivesuave 3y ago
I used to teach computer science to kids, and I had middle school kids setting up their own website with GitHub pages and buying their first personal domain. Firebase is also pretty amateur-friendly (although certainly more bloated than its early days) and I've seen novices deploy real-time apps with authentication, storage, server-side functions, etc. For professional software work, the dominating reason I favor a decoupled architecture is so I can have a frontend team and a backend team. I want the frameworks and existing libraries/processes/tools to lean on, so I can minimize how much engineering time is spent on reinventing wheels.
zeptonaut22 3y ago
In my experience, the web has bifurcated between "web applications" (owned by React) and content sites (owned by Jamstack). One dilemma I've faced is when you find yourself in the middle of those two areas and might want to develop an MVP in Jamstack to later add more web-appy features. Jamstack always left me feeling like it was sufficient for my current use case, but with much more complexity I was always one errant feature request away from running into something I couldn't do and having to rewrite everything. Furthermore, just doing simple things can require significant creativity on how to achieve that. It's fun, because the end result is something that's significantly more performant than anything you could squeeze out of React. I happily use Jamstack for my blog (FCP of 0.8s, Lighthouse score of 100!), but would feel reckless suggesting it for any professional work that I do outside of company blogs or something.
- tacker2000 3y ago
  How did you come up with this hypothesi? Jamstack is used on less than 10% of websites i would guess.
lagrange77 3y ago
I don't get his problem. 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.
paradox460 3y ago
I'm not sure what his beef with github pages is either. I host my personal site on ghp. It's a nuxt.js app. I push code up, a Github action sees it, builds it, and deploys to the pages. The end. The build yaml is maybe 30 lines total
wqtz 3y ago
Okay, I probably didn't understand JAMstack, even though I say to folks that I use JAMstack. I am not a professional web developer, but this is the reason why I thought I was using JAMstack: The reason I like JAMstack is because: - It is free. - It adds modularity to a static site. - If you want to provide an API service and your website just makes the API data look pretty. It is free. Netlify is free to sign up without a credit card. What else would you like me to mention? Everything else costs $5 a month or more. I am cheap. Cloudflare is free, Firebase is free, etc. Modularity in a static site generator. You know what is really cool and just works? Good static site generators. But sometimes, I would like to add some technical features to it, for SEO or fun. I would like to add components that focus on server-side computation a bit. However, it is not easy to do when you start with a static site. So, what I will do is simply write an API and connect it to the site with a simple API call. I can handle all the complicated tasks in the backend and send some data to my website, where it will be displayed in a table. If you want to provide an API service and have your website display the API data in a visually appealing way, this may not apply to most people. However, in my line of work, I used to focus on building APIs exclusively. People were not interested about the how site looked. They sometimes required authentication, a table, and some visualization and sorting features. To simplify the process, I would handle most of the tasks on the backend, with the website mainly fetching data from the API. It would consist of templating syntax and occasionally handle state management, as it was not practical to filter the data on the backend. --- So, that is how I used JAMstack. Can I do better? Eh, not really. I am not a web developer. I build APIs that sometimes need some visual representation. With Netlify Auth, Netlify Function supporting Go, Cloudflare Pages, etc., I don't see myself throwing in the towel on JAMstack, even though I might be missing the entire point here. Embracing the two-year cycles that web developers have about everything being bad and everything being shit is not for me. And yes, this is a cycle, and this is a fit. You will see after two years, some dude with 120K followers on Twitter will announce "we have re-embraced everything that is wrong with PHP because of 4chan memes, and here is this web5 stack that will fix everything." In web development, the only people I respect are those who have been using a 5-20 dollar/month VPS for more than a decade. They are not on Twitter, don't check HN except for weekends and they don't even do webstack-evangelism.
anurag 3y ago
(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.
- stringtoint 3y ago
  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.
- jaredcwhite 3y ago
  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.
nologic01 3y ago
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.
- tacker2000 3y ago
  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.
- elishah 3y ago
  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.
cutler 3y ago
Didn't Fly.io recently nosedive in similar fashion? If so, that just leaves Render.
tsp 3y ago
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.

178 points by brycewray 3y ago

deleted 3y ago

[deleted]

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.

zcmack 3y ago
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_.
- stevebmark 3y ago
  I don't think you read the article nor my comment lol

mehdix 3y ago

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.

hagg3n 3y ago
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.
- efields 3y ago
  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.
- mehdix 3y ago
  > 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.
  - cutler 3y ago
    But bash with CGI? Seriously, when there's Perl, Ruby, Python and PHP to choose from? 'Sounds like a security nightmare too.
    - mehdix 3y ago
      Because I wanted to learn more about CGI. Below is the script, I'd appreciate pointing out any weaknesses in it. https://raw.githubusercontent.com/mehdisadeghi/mehdix.ir/master/src/cgi-bin/submit https://raw.githubusercontent.com/mehdisadeghi/mehdix.ir/mas...

iamcasen 3y ago

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.

cosmojg 3y ago
So, would you recommend that newer startups just stick with a good old-fashioned full-stack monolith deployed on any old VPS?
- iamcasen 3y ago
  Yes absolutely. I've been very impressed that Rails has managed to stay relevant all these years later. 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.
  - kodisha 3y ago

moomoo11 3y ago

Wonder how much of this is driven by the hundreds of millions of dollars of VC money put into stuff like vercel and similar. All that complexity is not that useful imo. If you need SSR you probably should pick the right tool for the job (not react) to begin with. If you need a simple static site you don’t need all this cruft either. Am I wrong? I just don’t see where I’d use these tools and I’ve used them all before to try it out. Fwiw my startup is keeping it simple with a go backend, sveltekit, and flutter iOS/android.

freedomben 3y ago
React can be super nice to use for SSR. When the site is small and/or simple (or even medium sized), React is definitely overkill. But if you have a big site (like lots of pages, or complex pages) then the component model that React brings can make it a ton easier. The rule of thumb I use is basically if I'm including/importing more than a few template pages, React can make it a lot more manageable. Now that said, I think a ton more stuff can (and should) use SSG than SSR. This is IMHO the killer feature that Next.js makes easy to do.
- synergy20 3y ago
  I heard everyone saying 'react is for large complex project', somehow I think react is good for small project too: use a few components and its context api and dom-router to build a small site, the learning curve is actually not much comparing to other frameworks, what am I missing? tried svelte, vue, I don't feel react is more complex, if at all.
  - freedomben 3y ago
    Yeah compared to svelte, vue I think React is the way to go. For me the alternative for a small or medium project is a standard template system like Liquid (Jekyll), ERB (Rails) or EEx (Phoenix).
gochi 3y ago
Your startup isn't that different from what you're complaining about when it comes to complexity. You've just replaced next with sveltekit. Keeping it simple would just be using Laravel and then Flutter for mobile front ends.

swyx 3y ago

as a former advocate for Jamstack (https://www.swyx.io/ideas?filter=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.

andybak 3y ago

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

efields 3y ago

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.

gochi 3y ago
It always feels better to write spaghetti.
- yboris 3y ago
  There's code on his editor already, mom's spaghetti
isanjay 3y ago
Readers, it was so AWESOME to write spaghetti JS in one file 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.
wintogreen74 3y ago
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.
- efields 3y ago
  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.

zitterbewegung 3y ago

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 .

ezekiel68 3y ago

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. [0] https://swarm.workshop.perforce.com/view/guest/perforce_software/jam/src/Jam.html https://swarm.workshop.perforce.com/view/guest/perforce_soft...

tamimio 3y ago

A couple weeks ago I did my portfolio site with React/Gatsby, while its performance was relatively good and better than say a wordpress page, but later I tried Zola and the performance is just much much better, in development or even as a user, plus now it works even with no JavaScript enabled in the browser. So I think react and the likes can be used but only when it’s the only tool that can make it, else, there are plenty of better tools.

moritzwarhier 3y ago
React and SSR are not mutually exclusive. I don't know what Zola is though and I like using static no-JS sites :) 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.
- tamimio 3y ago
  Honestly, frontend development especially with all these crowded frameworks and libraries always confused me so pardon my ignorance, which is why in a project I’m working on right now I’m trying not to use js, instead I’m using egui [1] Zola is a static site generator and it’s crazy fast, using one binary only [2], also there’s Blades [3], same concept but supposedly faster, never tried it though. [1] https://github.com/emilk/egui https://github.com/emilk/egui [2] https://www.getzola.org https://www.getzola.org [3] https://getblades.org https://getblades.org
  - moritzwarhier 3y ago
    All power to you, sounds nice!

nusmella 3y ago

I don't understand the appeal of serverless. >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.

potta_coffee 3y ago
I've found some great use cases for serverless. None of those have involved hosting a backend for a website / web application. It's been a useful solution for automating some cloud management tasks though.
weitendorf 3y ago
Regarding cost, it can depend a lot on your traffic structure. If traffic is bursty, or substantially different between intraday peaks and troughs, it can be more cost effective. Solving this yourself costs dev time. >reduced time spent in devops and increased time spent in development This may be true if you’re trying to figure out how to do something you already know how to do outside of serverless, but IME many developers benefit from serverless eliminating boilerplate and nudging them away from state where it’s not necessary. Also regarding cost and devops: I see serverless as an insurance policy against “my startup/product got a once-in-a-lifetime lucky break by going viral while I was asleep” causing you to fall over from a flood of traffic. Not only do you get to skip implementing your own scaling to go from 0-1 but you only pay substantially (vs the regular price diff) extra for it when it happens.

davedx 3y ago

People waste so. Much. Time. On shiny tech, often just because it ends up on HN (or Tiktok or Insta). I remember evaluating the JAM stack years ago, and was underwhelmed. Like so many shiny new techs it didn’t really offer any big leaps forwards under the marketing and hype. People who lapped it up should think more critically about why they adopt tech.

api 3y ago
It seems like something that was designed to sell more cloud SaaS services: content hosting services, build services, etc. Instead of having one host for your site you now need three.
gochi 3y ago
I don't mind the churn, adopting new tech can be its own form of personal enjoyment. What I dislike is the hype, people with sizeable bases acting irresponsibly about new tech. Encouraging early adoption, and spending so much time promoting it, funding conferences, and then after 5 years dumping all of it so you can "learn from your mistakes" to push for some new thing. It feels so dishonest, why would their current choice be any better if they made such reckless decisions not too long ago? So you're right we really do need to think critically about new tech and give people the means to assess things critically without the hype.
whalesalad 3y ago
The problem with this attitude is that sometimes shiny new tech is awesome. I remember when nginx was shiny new tech and I had to deploy it into prod (back in 2007-2008) to prove that it was superior to Apache + mod_python. You need to be able to take the good with the bad and analyze everything objectively.
- davedx 3y ago
  Well yeah that’s what I mean about thinking critically.
cpursley 3y ago
How is providing a github url and having your site live and distributed via a global CDN with zero fuss not a leap forward?

revskill 3y ago

What's.... dead ? 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.

nxpnsv 3y ago

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

garganzol 3y ago
It's not required. And it's a big mistake to tie an app to a single vendor.

chmaynard 3y ago

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

garganzol 3y ago

The author's problem arises from the inability to understand that JAMStack is tailored towards static content / client-side apps. That's it. Postgres, server logic, services etc all represent something else. He also discusses Netlify and Render feature sets. While both services allow to do more than just a stateless JAMStack, they both have too much vendor lock-ins, and offer too little to make people take that functionality seriously. For example, Render supports Docker containers, but they are tied to a single region only. This is probably enough for hobby projects, but it's a show stopper for commercial deployments. In my opinion, author drank too much Heroku-aid in his conclusions.

politelemon 3y ago
I'm getting a similar impression. This seems like a classic case of blaming the tools rather than figuring out the right tool to use. I have a suspicion that their journey isn't over.
anurag 3y ago
> For example, Render supports Docker containers, but they are tied to a single region only. This is probably enough for hobby projects, but it's a show stopper for commercial deployments. The vast, vast majority of commercial deployments are single region, as evidenced by the occasional failure of us-east1.

rcarr 3y ago

The next time I try and do a serverless site I'm going to use SST. The last time I tried making one, I got all the way to the end of the project using Pulumi only to realise that I couldn't do any tests of the severless functions locally which would have made things an absolute nightmare. I think the only way you can do this is using AWS SDK or SST. Something to be aware of for anyone wanting to go down this route. https://sst.dev https://sst.dev

bobfunk 3y ago

Netlify CEO and coiner of terms here :) 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.

jmuguy 3y ago
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.

primitivesuave 3y ago

I used to teach computer science to kids, and I had middle school kids setting up their own website with GitHub pages and buying their first personal domain. Firebase is also pretty amateur-friendly (although certainly more bloated than its early days) and I've seen novices deploy real-time apps with authentication, storage, server-side functions, etc. For professional software work, the dominating reason I favor a decoupled architecture is so I can have a frontend team and a backend team. I want the frameworks and existing libraries/processes/tools to lean on, so I can minimize how much engineering time is spent on reinventing wheels.

zeptonaut22 3y ago

In my experience, the web has bifurcated between "web applications" (owned by React) and content sites (owned by Jamstack). One dilemma I've faced is when you find yourself in the middle of those two areas and might want to develop an MVP in Jamstack to later add more web-appy features. Jamstack always left me feeling like it was sufficient for my current use case, but with much more complexity I was always one errant feature request away from running into something I couldn't do and having to rewrite everything. Furthermore, just doing simple things can require significant creativity on how to achieve that. It's fun, because the end result is something that's significantly more performant than anything you could squeeze out of React. I happily use Jamstack for my blog (FCP of 0.8s, Lighthouse score of 100!), but would feel reckless suggesting it for any professional work that I do outside of company blogs or something.

tacker2000 3y ago
How did you come up with this hypothesi? Jamstack is used on less than 10% of websites i would guess.

lagrange77 3y ago

I don't get his problem. 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.

paradox460 3y ago

I'm not sure what his beef with github pages is either. I host my personal site on ghp. It's a nuxt.js app. I push code up, a Github action sees it, builds it, and deploys to the pages. The end. The build yaml is maybe 30 lines total

wqtz 3y ago

Okay, I probably didn't understand JAMstack, even though I say to folks that I use JAMstack. I am not a professional web developer, but this is the reason why I thought I was using JAMstack: The reason I like JAMstack is because: - It is free. - It adds modularity to a static site. - If you want to provide an API service and your website just makes the API data look pretty. It is free. Netlify is free to sign up without a credit card. What else would you like me to mention? Everything else costs $5 a month or more. I am cheap. Cloudflare is free, Firebase is free, etc. Modularity in a static site generator. You know what is really cool and just works? Good static site generators. But sometimes, I would like to add some technical features to it, for SEO or fun. I would like to add components that focus on server-side computation a bit. However, it is not easy to do when you start with a static site. So, what I will do is simply write an API and connect it to the site with a simple API call. I can handle all the complicated tasks in the backend and send some data to my website, where it will be displayed in a table. If you want to provide an API service and have your website display the API data in a visually appealing way, this may not apply to most people. However, in my line of work, I used to focus on building APIs exclusively. People were not interested about the how site looked. They sometimes required authentication, a table, and some visualization and sorting features. To simplify the process, I would handle most of the tasks on the backend, with the website mainly fetching data from the API. It would consist of templating syntax and occasionally handle state management, as it was not practical to filter the data on the backend. --- So, that is how I used JAMstack. Can I do better? Eh, not really. I am not a web developer. I build APIs that sometimes need some visual representation. With Netlify Auth, Netlify Function supporting Go, Cloudflare Pages, etc., I don't see myself throwing in the towel on JAMstack, even though I might be missing the entire point here. Embracing the two-year cycles that web developers have about everything being bad and everything being shit is not for me. And yes, this is a cycle, and this is a fit. You will see after two years, some dude with 120K followers on Twitter will announce "we have re-embraced everything that is wrong with PHP because of 4chan memes, and here is this web5 stack that will fix everything." In web development, the only people I respect are those who have been using a 5-20 dollar/month VPS for more than a decade. They are not on Twitter, don't check HN except for weekends and they don't even do webstack-evangelism.

anurag 3y ago

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

stringtoint 3y ago
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.
jaredcwhite 3y ago
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.

nologic01 3y ago

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.

tacker2000 3y ago
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.
elishah 3y ago
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.

cutler 3y ago

Didn't Fly.io recently nosedive in similar fashion? If so, that just leaves Render.

tsp 3y ago

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.