[HN Gopher] My journey away from the JAMstack
___________________________________________________________________
My journey away from the JAMstack
Author : brycewray
Score : 117 points
Date : 2023-07-31 15:55 UTC (7 hours ago)
(HTM) web link (www.spicyweb.dev)
(TXT) w3m dump (www.spicyweb.dev)
| ezekiel68 wrote:
| 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_soft...
| swyx wrote:
| 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.
| zeptonaut22 wrote:
| 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.
| rcarr wrote:
| 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
| iamcasen wrote:
| 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.
| JSavageOne wrote:
| > One of our lead engineers setup an NX monorepo. We deploy an
| API to AWS and our front-end to vercel.
|
| I don't understand where the complexity is in your setup that
| you're unhappy with.
| iamcasen wrote:
| 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.
| redact207 wrote:
| 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.
| zengid wrote:
| >> _Personally, I think all web applications should start out
| with the assumption they are a monolith._
|
| By 'monolith' are you still talking about a
| Rails/Django/Remix/(Next.js?) app? (Or ASP.NET for my dotnet
| homies out there).
| moojd wrote:
| > 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.
| lagrange77 wrote:
| > 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?
| moojd wrote:
| I'm not making a value judgement on rendering strategies,
| spa, etc. I'm arguing that for most js frameworks, building
| a full stack app with your own database, auth, etc without
| third party services is not the happy path. These are table
| stakes in php, ruby, and python. There are exceptions like
| remix. I'm just deriding a general trend.
| cosmojg wrote:
| So, would you recommend that newer startups just stick with a
| good old-fashioned full-stack monolith deployed on any old VPS?
| iamcasen wrote:
| 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 wrote:
| Yo clearly missed all of the Next is now PHP/Rails and
| Next.js as PHP and Rails logo [1] memes :)
|
| [1] https://www.reddit.com/r/nextjs/comments/139j19t/shall_
| we_co...
| nologic01 wrote:
| 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.
| bobfunk wrote:
| 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.
| irrational wrote:
| 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.
| paultopia wrote:
| 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.
| boredumb wrote:
| 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?
| jmuguy wrote:
| 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.
| cpursley wrote:
| Render is (a cheaper) Heroku + Netlify ;)
| giovannibonetti wrote:
| Render seems to have autoscaling with a reasonable round-
| robin load balancer [1], whereas Heroku only has
| autoscaling in (expensive) Private Spaces [2] with a dumb
| load balancer [3].
|
| [1] https://feedback.render.com/features/p/docs-on-how-
| renders-l... [2]
| https://devcenter.heroku.com/articles/scaling#autoscaling
| [3] https://devcenter.heroku.com/articles/http-
| routing#request-d...
| blitz_skull wrote:
| 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.
|
| Well done, says I.
| shiftpgdn wrote:
| 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.
| cpursley wrote:
| > vendor lock-in
|
| How is it vendor lock-in when I can easily move my JS app to
| Render.com, AWS s3, Cloudflare, etc?
| blitz_skull wrote:
| 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.
| shiftpgdn wrote:
| https://w3techs.com/technologies/details/pl-php 77.4% as of
| today.
| notatoad wrote:
| >of all the websites whose server-side programming
| language we know.
|
| i'd be curious to know what portion of websites they scan
| they know this for.
| cies wrote:
| PHP is know for being very leaky about being PHP (and
| since PHP + ecosystem have a bad history of CVEs, being
| leaky about being PHP is not cool).
|
| Java/Kotlin/Go/Rust/Ruby/Python/JS/TS are a lot less
| leaky about what language the server-side is written in.
| Usually the webserver used advertises itself name and in
| a server string, but it is considered bad practice and
| thus often switched off.
|
| Reading "php" extensions in paths is a clear giveaway, so
| are "htm" extensions for microsoft products. Tools
| usually guess the language/framework based on some of
| these giveaways and the better the tools the less this is
| evident.
|
| I jut checked some web apps I worked on, and only the one
| I last touched 10+ years ago is detected with
| buildwith.com; it's a Rails site.
|
| All the Java/Kotlin/Rust/Hasura+Elm apps I worked on
| since are now shown as "Nginx" (the rev proxy in front of
| it).
| tacker2000 wrote:
| How is being "leaky" in any way bad or even good?
|
| Every programming language has holes, its just that with
| PHP the attack surface is much larger, so i guess people
| find more holes, etc..
|
| Are you advocating "security by obscurity"?
| gochi wrote:
| >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.
| bobfunk wrote:
| 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.
| shiftpgdn wrote:
| https://www.netlify.com/pricing/#pricing-table-full-
| feature-...
|
| Almost every feature you charge for is something you can
| achieve for free inside of a basic VPS. I understand you
| have the classic SV "Hotel California" model where you can
| check in but you can never leave. But frankly this makes
| the internet worse in every way possible and part of the
| point of the original article.
| cpursley wrote:
| Setting up a VPS - yeah, sooooo easy.
|
| I struggle with even Digital Ocean and just want my site
| to freaking run.
|
| Downvote me all you want, but I'd rather ship features
| than fuddle with infrastructure.
| klysm wrote:
| Then go ahead and use a VPS...
| shiftpgdn wrote:
| The difference is I'm not out touting using a VPS as "The
| next generation of web development" and having payola
| articles written that if you don't use a VPS then your
| career is going to get left behind.
| te_chris wrote:
| 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.
|
| Our pages rendered in 20ms.
| perelin wrote:
| honest question: sounds like a cool architecture! care to
| give some insights how you achieve this?
| andybak wrote:
| 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.
| [deleted]
| revskill wrote:
| 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.
| wqtz wrote:
| 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.
| nxpnsv wrote:
| But... Netlify is not required to play JAMstack, is it?
| garganzol wrote:
| It's not required. And it's a big mistake to tie an app to a
| single vendor.
| stevebmark wrote:
| 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 wrote:
| 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_.
| tamimio wrote:
| 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 wrote:
| 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 wrote:
| 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
|
| [2] https://www.getzola.org
|
| [3] https://getblades.org
| moritzwarhier wrote:
| All power to you, sounds nice!
| paradox460 wrote:
| 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
| efields wrote:
| 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.
| isanjay wrote:
| 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 wrote:
| 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 wrote:
| 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.
| gochi wrote:
| It always feels better to write spaghetti.
| yboris wrote:
| There's _code_ on his _editor_ already, mom 's spaghetti
| m463 wrote:
| 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
| superanus, 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._
| notatoad wrote:
| yeah, building demos is really fun.
|
| 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.
| efields wrote:
| no sense in building out the functional part of the business
| if the demo proves the business doesn't work.
| nusmella wrote:
| 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 wrote:
| 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.
| moomoo11 wrote:
| 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.
| gochi wrote:
| 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.
| moomoo11 wrote:
| Yeah unfortunately flutter web had some issues at the time.
|
| And Go is good for all the other things like real time and as
| a general language.
| freedomben wrote:
| 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 wrote:
| 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 wrote:
| 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).
| primitivesuave wrote:
| 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.
| zitterbewegung wrote:
| 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
| .
| davedx wrote:
| 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 wrote:
| 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 wrote:
| 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.
| cpursley wrote:
| How is providing a github url and having your site live and
| distributed via a global CDN with zero fuss not a leap forward?
| whalesalad wrote:
| 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 wrote:
| Well yeah that's what I mean about thinking critically.
| anurag wrote:
| (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.
| jaredcwhite wrote:
| 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.
| Justsignedup wrote:
| 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.
| stringtoint wrote:
| 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.
| chmaynard wrote:
| 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 wrote:
| 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 wrote:
| 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.
| mehdix wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| lagrange77 wrote:
| 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.
___________________________________________________________________
(page generated 2023-07-31 23:01 UTC)