4 ms·

Pretty sure you have conflated the abilities of the half dozen frontend frameworks you added (for simplicity) with the the backend you replaced. ".Net" (not act

Pretty sure you have conflated the abilities of the half dozen frontend frameworks you added (for simplicity) with the the backend you replaced. ".Net" (not actually a specific backend) and an rdbms are not in any significant way a friction against a REST api. Mean while the only noticable difference between the sites is the front end.

slathrop 8y ago
My comment above was intended to add some value and perspective on using Hugo in a real world business/industry/paying customer website scenario... something beyond a personal blog. So RE: the main discussion here about Jekyll and Hugo and static site generators (SSGs), I think that if you take a moment to consider the difference between the SSG/JAMstack approach vs. the traditional "build the response on every request" back-end approach (and I'm not picking on .NET and SQL Server there, I've developed many sites using them myself) you'll see that there are some huge differences[1]. I think the most important difference is that with SSGs and JAMstack, your back-end code only runs at build time, on free build server infrastructure. There is no runtime back-end code, and therefore you can operate these JAMstack sites, at scale, at zero or near-zero operating cost. In the case of my customer, I estimate I saved them $100K over the life of this new site. Of course, your use-case must align with this sort of architecture. Not every site can or should be totally re-generated when content is changed. And importantly for my customer, they did not have to sacrifice a nice, user-friendly content-management experience. I happen to be using Netlify CMS, but others like Contentful and Forestry are nice options too[2]. [1] https://youtu.be/uWTMEDEPw8c https://youtu.be/uWTMEDEPw8c [2] https://headlesscms.org/ https://headlesscms.org/
haskellandchill 8y ago
We’ve mostly lost track of our ability to talk about things of technical interest on the front end. It’s common to see framework soup (though OP explained themselves well in their response). I have to put headphones on when junior engineers talk JavaScript tech, it makes me too angry/amused and they probably should be talking about it anyway since it will help their careers if they pick the right ones. Sadly a similar thing has happened to programming languages, we use languages just for their libraries. The language itself must be treated as an empty vessel for the ML/Numeric/Web/Physics whatever it is you need. Or programmers you need to hire. This bothers me but is the purpose of our industry, to minimize construction time through reuse.

slathrop 8y ago

My comment above was intended to add some value and perspective on using Hugo in a real world business/industry/paying customer website scenario... something beyond a personal blog. So RE: the main discussion here about Jekyll and Hugo and static site generators (SSGs), I think that if you take a moment to consider the difference between the SSG/JAMstack approach vs. the traditional "build the response on every request" back-end approach (and I'm not picking on .NET and SQL Server there, I've developed many sites using them myself) you'll see that there are some huge differences[1]. I think the most important difference is that with SSGs and JAMstack, your back-end code only runs at build time, on free build server infrastructure. There is no runtime back-end code, and therefore you can operate these JAMstack sites, at scale, at zero or near-zero operating cost. In the case of my customer, I estimate I saved them $100K over the life of this new site. Of course, your use-case must align with this sort of architecture. Not every site can or should be totally re-generated when content is changed. And importantly for my customer, they did not have to sacrifice a nice, user-friendly content-management experience. I happen to be using Netlify CMS, but others like Contentful and Forestry are nice options too[2]. [1] https://youtu.be/uWTMEDEPw8c https://youtu.be/uWTMEDEPw8c [2] https://headlesscms.org/ https://headlesscms.org/

haskellandchill 8y ago

We’ve mostly lost track of our ability to talk about things of technical interest on the front end. It’s common to see framework soup (though OP explained themselves well in their response). I have to put headphones on when junior engineers talk JavaScript tech, it makes me too angry/amused and they probably should be talking about it anyway since it will help their careers if they pick the right ones. Sadly a similar thing has happened to programming languages, we use languages just for their libraries. The language itself must be treated as an empty vessel for the ML/Numeric/Web/Physics whatever it is you need. Or programmers you need to hire. This bothers me but is the purpose of our industry, to minimize construction time through reuse.