Live data from Hacker News

The Evolution of Jamstack

smashingmagazine.com

41–49 of 49 posts

Re: The Evolution of Jamstack

#41
post #21

Earlier quoted context omitted.

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. F…

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.

You may be confusing ruby with perl or clojure.

Re: The Evolution of Jamstack

#42

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 ma…

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 secur…

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?

Re: The Evolution of Jamstack

#43

Earlier quoted context omitted.

At the end of your SPA build process, you spin up a dummy HTTP server and run headless chromium on it (e.g. with puppeteer) to render each route and save the output html. Instead of only /dist/index.html, you have /dist/index.html, /dist/about/index.html etc.

Surely you meant this facetiously?

I think not, what he describes is really the way some of these tools work.

Re: The Evolution of Jamstack

#45
> At that point, the idea of fundamentally decoupling the front-end web layer from the back-end business logic layer was only an early trend, and not yet a named architectural approach.

Is this a joke? As far as I can tell Jamstack is just a buzzword for web sites served via CDN that use JavaScript.

Re: The Evolution of Jamstack

#46

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 ma…

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.

Re: The Evolution of Jamstack

#47

Earlier quoted context omitted.

I think not, what he describes is really the way some of these tools work.

Why render headless and repackage the output though?

The main benefit is for SEO tags on each individual route and proper 404 status code

Re: The Evolution of Jamstack

#48

Earlier quoted context omitted.

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 secur…

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?

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!

Re: The Evolution of Jamstack

#49

Earlier quoted context omitted.

Well, funnily enough, I have also found existing site builders to be insufficient in various ways. Firstly, I do not believe that the block-based approach works that well. It sounds great on paper, to be able to drag and drop block-like elements to compose a page, but it falls apart so quickly. You just don't end up with coherent pages, especially once everything starts getting rearranged on mobile. Speaking of mobil…

Sounds like you built something for yourself instead of building something that the market wants. Every non technical person I've spoken with loves Wordpress and Squarespace for good reason.

> Sounds like you built something for yourself

Absolutely! That appears to be how all of my projects start. If I have a need for something, I'll go build it for myself. That way I am ensuring I am using my own product, which I find vital.

> instead of building something that the market wants.

I don't quite have that information yet. So far, reactions seem positive, but the jury is out on whether it'll work. I'm only about a month in, but I felt it's worth giving it a shot and seeing if there are others who want the same features I've built. I am not planning to even show up on Wordpress' or Squarespace's radar. Their user figures are in the millions. If I, by some stroke of luck and opportunity, ended up with a few hundred, maybe a thousand users, I'd consider this thing hugely successful.

> Every non technical person I've spoken with loves Wordpress and Squarespace for good reason.

This is super relevant, could you let me know how many people and what sort of level of technical knowledge? You mention 'for good reason', which would also be most interesting to hear more about. What sort of reasons?

I have found Wordpress and Squarespace to be good products. Squarespace much more so, especially for less-technical people. I find that setting up a Wordpress instance, even in this day and age is an extremely varied experience (from 1-click providers all the way to installing your own SQL DB and whatnot). But I have also found that you run into certain limitations quite quickly. Themes can be oddly restrictive. Changing your mind about something substantial on your site can quickly become an issue. At the same time, my product has other limitations, so it's obviously about what you think you need as a user. I'd wager that if you took someone properly non-technical and set them in front of our CMS vs. the Wordpress site builder (or even a site pre-built in either CMS), ours would be more intuitive to use. But I am still doing that research and while my sample size is growing, I wouldn't with confidence declare my product easier to use.

Edit: I feel documentation is another pretty big area where things quickly get confusing for users of the other providers' systems. I'm really trying to build a kind of documentation that encompasses the whole system and makes it very clear how to use every part of it. With something as complex as Wordpress that's nearly impossible to do, as Wordpress can be as complex as you like it to be. That's obviously one of its strengths: Even a dev can use it and not feel hindered by it. My product, on the flipside, does not cater to devs whatsoever.

Post reply on HN