Chris Campanale
Likewise! I thought for sure, based on the title, that I was going to read about the development of entirely client side web applications that use local storage techniques, possibly block chain, and consumption of SaaS services and APIs available over the internet. Instead, it’s just more of the same concepts behind SPAs. Nothing that new IMO.
Furthermore, what is with these “stop doing…” articles. I feel like I read at least one article a day that tells me to “stop doing” something only to read that the real story is how you could do something different or is advertising nsome new framework or runtime without much evidence as to why you should really “stop” in the first place. These articles should be titled “consider the following x next time you y”.
Martin
This article has an underlying tone of that web requests are bad and is an architecture you should avoid. The JAMstack is the one stack to rule them all! This leads to several problems. Sure, your Macbook Pro might be super fast at rendering the thicc layers of JavaScript to get the website up, but what about low-end mobile devices? Instead of Flash and Java Applets one of the biggest issues in both performance and security is all the JavaScript running on the front-end together with its 3rd party dependency mess. While it may sound like a cool idea, each architecture has its limitations. There are way too many people that enforce a certain kind of architecture or technology simply because they think it is cool, not because it’s the right tool for their job. And I think web-developers specifically do this mistake way too often.
Robin S
Well but… this is still server based right?
Furthermore that’s even slower compared to the “older” approach to serve content within one single request.
Doing multiple requests and the requirement to load data after the document is ready makes it even slower and the user has to wait longer until they can see the data they want in that way.
I’m still confused about that title. Could you eventually explain if that was just some kind of click bait or was it really serious, because I still don’t know why it should not be server based anymore. How can you avoid server based logic via form submits and such?
David Neal
Thanks! Yes, I drew the illustrations.
David Neal
During the render process, you can still use your favorite language and templates. The difference is instead of rendering on every request, you render only when the content, navigation, layout, or some other piece of the page changes. The only thing that needs to be managed using JavaScript are any dynamic elements on the page, and that can be done using your favorite front-end framework, such as the SPA you use today.
David Neal
The goal should be to not only minimize the amount of work required to serve a request, but to minimize the amount of work that needs to done on the client, as well. Maximize as much pre-rendered markup/assets as possible and serve them from a dedicated storage service or CDN. I’m not a fan of heavy JavaScript frameworks where the only thing that gets sent down to the client is an empty <div id="“app”"></div>. That’s not good for SEO, discoverability, or usability.
David Neal
To keep the article short, I didn’t go into detail about how different scenarios are supported. You can absolutely create an e-commerce web app and other very dynamic apps with the JAMstack approach. Search for e-commerce and JAMstack and you’ll find several tutorials on how to implement such an application.
B.Max
Fair point. It’s true that you can build such apps using the JAMstack, but is it the best approach? It depends on what the app will be dealing with.
Is it a good idea to use JAMstack for every apps? Probably not.
Is JAMstack an awesome approach when appropriate? Hell fucking Yeah (Gridsome for the win)!
Is it a viable approach in certain scenarios? Nope, but any coder should use the right tool(s) for the right job.
Would JAMstack be fit more use cases / problems if more packages/libraries/3rd-parties supported SSGs like Gridsome, Gatsby and Scully? Yes, unfortunately for some of us, some packages/libraries we need, don’t work (well) in static contexts or play well with SSGs.
B.Max
You’ll need to host the app regardless of it being static (e.g. pre-rendered) or dynamic (server-side rendered).
B.Max
Bringing the pros of static sites to server-side managed codebases and plenty more I’m sure you read when looking up JAMstack or specific Static-Site Generators.
B.Max
Not sure if you realised it or I am reading your comment wrong, but you’re comparing Angular (FRONT-End) to Java (BACK-End) which is like comparing apples and oranges.
Also, anyone can use TypeScript, Flow or any typed/annotated versions of JS which eliminates the problems with dynamic typing that don’t show up in statically typed languages like Java.
Of course you may enjoy Java’s verbosity and style but that’s not the case for everyone especially when they are imo (case-dependent obviously) better options for server stuff.
Gilbert Diaz
You need to write a course on that. https://media0.giphy.com/me…
Matthew E. Keller
Thanks David. Maybe I didn’t read this carefully enough. I’ll take another look.
Matthew E. Keller
They are different ways of producing a web page with dynamic content, so it seems like anyone wanting to write a web application would want to explore the pros and cons of each approach before choosing how to build it. The whole Angular paradigm seems flawed to me from the start because embedding your html in javascript is a layer of abstration that spawns even more abstraction making for an overcomplicated solution. The worst thing about this model is that it makes life really difficult for web designers (layout guys). The best web designers I have worked with are not java or javascript developers. They are wizards at html, css, and photoshop, and “art” oriented. By mixing up javascript and html, and further fragmenting the html through numerious locations the web designer ends up having to work in a way that is very inefficient for them. JSP, ASP, and PHP only require the webdesigner to look around some dynamic tags, which they generally don’t have issues with. Server rendered MVC still has the best separation of concerns and specialities. JSON based web applications using services are the fashion but have lots of drawbacks. They are okay for small web applications, but for very large applications that have a lot of state its better to still have an MVC web server. Of course the webserver can still call services for its data, so you can move the DAO layer and some of the business logic off the webserver regardless. This way you are leveraging services but taking advantages of the control and simplicity that a server side MVC gives you.
B.Max
Firstly, Angular doesn’t do HTML-in-JS, more the opposite. That’s React (and Vue to an extent) which do that.
Secondly, web designers don’t need to learn frameworks and libraries (they could but I have yet to see a single one who has to use them).
Do you genuinely think a design has to use JS? Have you not come across Front-End developers (I’m sure you know that FE Development != Web Design).
I struggle to see why you think having MVC web servers are a good idea when MVC is an architectural pattern for the software (not the server)…
And also, why would web designers deal with Back-End languages like ASP, PHP, … That’s not their job, BE/Fullstack devs are here for that.
peterritchie
There’s something to be said for optimizing to do “one thing” only one time. Effectively this is a level of compartmentalization: something also difficult to get right. I think this is doable and beneficial in isolation. The work to get there from where most people and apps are is probably huge. Well componentized systems that are more run-time composed would make this easier; but that’s something that has also been evangelized without much traction because of the complexity. 
Maybe approach is as less of an all-or-nothing thing and describe it as a principle that can be used in individual and concise scenarios?
Tom
But how do you manage authorization? Before letting the user download the HTML or on the client after the js is loaded?
Patrick
I think the author is just writing about the benefits of a single page application
facumo
Ehem… Ehem… Did you mean, React?
Chris Wood
I laughed my butt off at that 
