Closed janat08 closed 4 years ago
Acronyms can be confusing, especially this one and there are still a lot of misunderstandings, than even sites like https://jamstack.wtf/ don't seem to clear up.
Anyway what's your point? Eleventy can build static sites, can fetch data from external APIs, and be gracefully deployed on CDNs, that's what JAMstack is all about: delivering faster websites — not necessarily building SPAs.
In JAMstack, J stands for JavScript (not javascript as you write it).
An Eleventy static site is built with Node.js packages and you can use JavaScript for frontmatter, global data files, templates, etc. It's JavaScript everywhere!
Isn't it enough?
I think your take on JAMStack might be a little too narrow. Eleventy is JAMStack tooling - but focused on a different use case to SPA's.
You're right it's probably not the best tooling for a SPA but it's not claiming to be:
Eleventy is not a JavaScript framework—that means zero boilerplate client-side JavaScript.
If you're looking for a SPA framework out the box, I would say Eleventy is not the right choice.
I guess tools like Gatsby or Gridsome that generate React or Vue Apps by default are responsible for the confusion, but JAMstack was never about shipping JS Apps by default, a static HTML website served over a CDN is 100% JAMstack.
According to JAMstack.com, what they meant by javascript is: Any dynamic programming during the request/response cycle is handled by JavaScript, running entirely on the client. This could be any frontend framework, library, or even vanilla JavaScript.
Im not sure what the first sentence is suppose to convey, but they clearly expect you to have javascript on client.
I suppose its common to market static site generators as if what they're is synonymous to JAM even if there's literally none of JAM in them.
they clearly expect you to have javascript on client.
It's is an example, but it means that if you want dynamic stuff, you can do it like this, instead of relying on a backend as in LAMP stack.
I mean, JavaScript on the client is brittle. Why would I want to use it if the main purpose of my website is content, not interaction (like in games or apps)?
I can write my SSG in JavaScript, fetch API endpoints with JavaScript (e.g. OpenWeatherMap, Twitter, GitHub) and render Markdown with JavaScript.
Sounds pretty JAM~y to me :-)
Plus, Chris Coyier listed the spectrum of JAMstack a while ago. If you take a look at his other note on this, you'll notice, that you can use other featues as well. Say FaaS. Disqus Comments. Netlify Forms.
To me, it is about to shift the effort as much to the server as possible. I don't see, why I would force my visitor's browser to do the same stupid stuff (rendering the very same HTML) over and over again. Instead, pre-render it (with the option to put it on a CDN and thus closer to them). For example, check out what Addy Osmani recently shared on Concatenate Conf - why are you eager on slow loading content?
I suppose its common to market static site generators as if what they're is synonymous to JAM even if there's literally none of JAM in them.
Eleventy is built in Node, so there's your JavaScript (you could also load React or Vue or what-have-you into it, if you really really want) Eleventy has the capability to fetch from APIs so there's your APIs Eleventy has support for eleven different template languages, so there's your markup.
If you're looking to Eleventy as a JAMstack tool and it's not meeting your needs, I'd be interested to know what gaps exist. Perhaps it's outside of the scope of Eleventy's value proposition. Or maybe there's something in the docs/examples that you may find useful.
From what I understand about how server rendered apps work, what you insist is JAM is in fact not much different to php server rendering it's static pages and caching them.
@janat08 I think you misunderstand.... the key difference is pre-rendering vs server-side or client-side rendering
Eleventy templates are pre-rendering at build time; not server-side rendered on request or rendered in SPA-like fashion by the client
further reading: https://www.toptal.com/front-end/client-side-vs-server-side-pre-rendering
I believe in backend apps it's not unheard of to cache results of render, but I'm basically picking on you out of many such frameworks, caveat emptor.
PS I mispoke in previous post in referring to static pages as being cached and not dynamic ones.
Howdy y’all—this issue is invalid and inaccurate and I don’t think we need to debate it 😅 Gonna lock this one for now—thanks!
Describe the bug JAM stands for javascript and etc. You basically have no hydration to use SPA. I doubt that they meant something like jquery when they put J in JAM.