[0xb0565e487]

I've been working for a company that heavily caters toward the "JAMStack ecosystem" for a while now.

From my point of view, the "JAMStack" is nothing more than a piece of jargon used to aggregate various "good" ways of building and deploying web applications to trick non-technical business people or entry-level developers into using their services.

There's an absurd amount of money and effort currently being spent marketing this term.

Whatever it is, it's ephemeral, and I recommend anyone to avoid spending time on this unless they want to fall into another marketing funnel.

[game_the0ry]

I tend to agree. Rise of JAMStack as a concept is likely backed by companies like Netlify, Vercel, Auth0, Twilio, Firebase, and very other API-as-a-service company.

Though I think its part natural evolution of how web apps are built - it makes sense that common web apps functionality (like auth, database, email, etc) would be commoditized as services. I don't see that as a bad thing, especially since there is a lot of open source software (RoR, Django) that commoditizes and standardizes those aspects anyway.

JAMStack also has the side benefit of encouraging developers to focus on the business value of the software they are building, rather than the underlying plumbing.

[PinkPigeon]

It's sort of funny to see how this has suddenly become such a big term. I started out building a CMS that deploys static sites. I did that because I didn't want to deal with DBs / Wordpress, etc. I just wanted to quickly throw static pages onto a CDN and not worry about hosting. Netlify and the likes enabled this and I thought it was rather fantastic. So easy to deploy, very little performance worries, no DB to secure etc. etc. Then the JAMStack term started showing up (pushed by Netlify initially, I believe?). And you're right, just like 'serverless' (which is a ridiculous misnomer), I think this is just the kind of thing that's needed to get non-technical people on board with a better way of doing things.

At the same time, I think there's true advantages to this approach, so long as you do things right and don't fall into the traps of paying through the nose for things that should be cheap. cough Netlify form handling.

The challenge for Netlify (and my own business as well) is finding a way to capitalise on static sites, so often they will decide on some arbitrary metric and restrict that.

So, while I think the term jamstack may go away, I feel the idea behind static sites probably won't. To be able to make a whole shop, including financial transactions, without a DB in sight is quite appealing imo.

Just don't get suckered into the walled gardens / closed ecosystems out there.

[felipeccastro]

I get how static sites are useful for readonly content, but what do you mean by "financial transactions without a DB in sight"? Even in jamstack you still have an API backed by a DB, no?

[PinkPigeon]

Ah, you are right, my wording was imprecise.

If using something like snipcart, you can then have a whole shop without you yourself having to maintain or admin a DB, it's all managed by a third party. They do, however, still maintain a DB themselves.

For my product I am planning to create a Stripe-based shop-module, which would allow anyone to create a shop using their own Stripe credentials. This would require some API calls coordinated by our own server and therefore some DB entries, at which point the sites cannot be considered pure readonly from our side.

All of this reminds me of the horrible misnomer 'serverless'...it's servers everywhere. And even the whole 'without DB' moniker doesn't hold up if things get a bit more involved. Maybe ultimately it's worth calling it the "let's try to keep sites as static and readonly as possible"-stack ;)

Thanks for the observation!

[benjaminjosephw]

This is also true for basically all "cloud" services. There's no real innovation, just a return to mainframes and timesharing with a massive amount of marketing momentum to convince everyone that this is a step forwards. But hey, we all drank the Kool-Aid.

[jeffreyrogers]

Maybe there's no technological innovation, but they do make things a lot easier. I set up my own email server once (for sending mail from a webapp) and after doing that once I'm happy to use mailgun from now on (it is non trivial to configure a mail server to deliver mail to all major email providers without getting flagged as spam).

Sometimes avoiding the cloud services is the right decision, and I think many architectures are overly complicated based on current and prospective performance requirements (cargo cult infrastructure/architecture), but used properly they save many thousands of hours of engineering time.

[pudmaidai]

Yeah, ok, maybe you’re glossing over the immense difference that there is between what could be done on a mainframe vs what a Lambda allows, including all complementary services like per-second billing and granular permissions and logging. Now tell me that this is just the same thing as “mainframes” from the 80s.

[midrus]

After so much time wasted with all of this, SPAs, microservices, microfraneworks, etc, I've ended up pretty burned out of the amount of work it takes, and the incredible number of corner cases I've found. From development environment issues to how to have a staging or testing environment to how to do authentication. Do many things you get for free with more traditional approaches.

Last year we started at work a project with plain old Rails. This year we started using stimulus and turbo. You cannot believe how much our lives have improved. Things are so easy and feel so solid. Everything has documentation, things don't change every other day. Patterns are clear, libraries well tested, we focus 99.9% on actual business problems.

Two members of the team left because they wanted to react node monorepos all the things. It's. South they left, but overall we are so much happier and more productive now, even with two members less (team of 6).

I really wish the pendulum swings back, as they say, and we stop this madness. At least for the 95% use cases that don't need to be an SPA with a Go backend for google scale.

[yannoninator]

Hmm, so basically you're saying it's a scam right?

[asien]

I wouldn’t call it a « scam » technically.

But remember GWT ? I work in one Europe largest bank , the majority of internal apps are written in GWT.

In the 2010 era this trend was at its peak.[0]

Some members of the teams decided that they should « invest » in GWT because this would be the future.

Here we are 10 years laters , GWT is a deprecated legacy framework and developers have been burned out by this strategy.

For Jamstack the same will happen , the hype is reaching its peak and is going to come down as developers and businesses realize it doesn’t actually solve anything from their actual problems.

But in the process, people who are selling « Jamstack » books probably made a fortune. Same thing for GWT...

[reitoei]

You're talking about *Jamstack* like it's some kind of proprietary framework or platform.

It's a methodology for building websites in a particular way using an enormously diverse set of tools and platforms. Comparing it to GWT is not correct.

[pudmaidai]

What’s your point? Technologies come and go. People built Ruby apps that did their job and now good luck finding maintainers for them. It’s just how our market works. We’re lucky if our stack lasts 10 years.

[sethherr]

Ruby is still alive and well! It’s still focused on functionality over flash, and it’s not hard to find developers for it.

[quesera]

I agree with your larger point, but FWIW your example does not match my experience.

I've never had any special difficulties hiring Ruby/Rails devs. Quality is high, availability is reasonable (hiring is always something of a struggle!). My first Rails hire was in 2003 (rails-0.8, IIRC) and my most recent was about 6 months ago.

That's 17 years, and counting.

OTOH, I've never had a good time hiring people to maintain EOLed apps. Ruby or otherwise. "Sustaining Engineering" is a (misnamed) trade that isn't as broadly attractive as new development.

[Scarbutt]

You may be confusing ruby with perl or clojure.