932 karma · joined August 27, 2018
So, no, Markdown is not holding me back. It is perfectly capable of what the author claims it isn't.
[0]: https://daringfireball.net/projects/markdown/syntax#html
1. The various clients and servers implemented different subsets of the functionality, which deteriorated UX.
2. Service providers have an incentive to lock you in and the average user doesn't mind. So no one pushed for it.
Or do you mean something else altogether by 'CSS attributes'?
[0]: `https://docs.astro.build/en/guides/routing/#static-ssg-mode
What makes it so great is not that it serves a particular niche (like "content-driven websites") but that it provides a developer experience that makes it incredibly easy to scale from a static website to something very complex and interaction-heavy without compromising UX.
Using a framework has upsides over writing static pages manually. Most notably, you can decompose your website into reusable components which makes your implementation more DRY. Also, you can fluently upgrade to a very interaction-heavy website without ever changing tech or architecture. But that's just what I value. I whole-heartedly recommend trying it out.
They suggest a platform where "you upload any docker-compose.yml". Consequently, this makes SSO, updates, etc. the user's responsibility.
The word 'object' has different meanings. One includes arrays and the other does not. They prefer the latter. You prefer the former. I don't think this has much to do with 'facts' and 'opinions', but rather with the practicality of choosing a certain way to speak.
I’d liken it to the word 'sorting'. JavaScript libraries sort in a certain way that is simple to implement. However, this is so different from what we typically mean by 'sorting' that people came up with natural sorting algorithms. Are these people treating facts like opinions on how to sort? I’d rather say, they acknowledge the relevance of a certain way to speak.
Components (be it Astro, Svelte, React, etc.) have a lovely API for sharing code across web pages. I used Hugo before and hit the limits of shortcodes pretty quickly. I can't comment on Jekyll though.
Furthermore, if the need for some dynamically rendered pages or client-side interactivity comes up, it is very easy to integrate this later on. I can build static, server-rendered and client-rendered pages (and everything in between) with the same set of tools, which means less mental load when I develop.
https://www.aqua-calc.com/ – Convert volume to weight and vice versa for many ingredients.
https://liveuamap.com/ – See the current frontlines of the war in Ukraine/Russia.
The main thing that struck me as odd was the distinction between "Simple Static Site" and "Dynamic Web App". If I choose the latter, I am recommended stacks with backends and databases.
However, static sites can have tons of app-like interactivity. And web apps don't necessarily need a backend and a database. It seems to me that if someone knows what you are getting at here, they are probably already capable of evaluating tech stacks without your help.
If you want to separate people who need a backend from people who don't, maybe better questions to ask are "Do you need users to have an account?", "Do you need users to share data with you or each other?", or something along these lines.
Enter the address into your browser. The page exists. It seems to be Lockheed Martin's official page for the jet. Your teachers surely won't blame you for using information from that page, even if you've gotten the link from Wikipedia.
It is very likely the policy is meant to prevent lazy students from copying text from Wikipedia, not from using the sources mentioned there.