We do need to update the landing page, we've gone through many updates over the two years that this site has been out and I think this page doesn't explain what Web Fundamentals site is.
Our goal with this section is to explain the fundamentals of web development from the platform upwards with opinionated best practice guidance.
We are constantly adding new content for new areas of the web (like push notifications) and refactoring guidance as we learn more of how this is used in production (things change, but we base the initial guidance off how we have used it).
In the 'Getting Started' section of a site named 'Web Fundamentals,' you have articles on service workers, promises, async functions, and shadow DOM. They're great introductions to those topics, but those aren't fundamental. They're more like advanced new browser tech that's only been supported for a few years or less. 'Fundamentals' would be things like HTML, CSS, JavaScript, JSON, and HTTP requests.
I think I get what you might mean in that these things are now permanently part of the browser runtime and not just imported libraries, but this site would have driven me crazy when I was first learning the actual fundamentals of web dev.
You've got excellent content on here, so I'd recommend just changing the name to something like 'Advanced Web Features'.
The site is called "web fundamentals" and looks to be educational. Unfortunately, it is severely flawed due to a bias. The site is immediately and inherently skewed towards interaction and programming. This mistake (though incredibly common) is really really bad.
At the core to have the web all you need is two things: an application protocol and a document structure format. The public web standardizes on HTTP and HTML for those two qualities. This site does not address these two most primary qualities explicitly. The implicit assumption is that these qualities are not themselves important and instead necessary trivialities who technical qualities can be indirectly surmised through study of more interesting derivative works. This is a big mistake that makes learning these technologies far hard than it really needs to be. Don't assume the technologies are simple or that people will just get it right, because they won't.
If I were teaching a class on web fundamentals I would start with XML Schema. Don't laugh, I am being serious, just hear me out. Learning XML Schema is important because it forces the student to learn the importance of structure and design in the crafting of human consumable information, which is really what the web is all about. It also teaches the student about node types and node relationships that is directly reflected in the standard DOM methods. Equally important it also teaches the student about application scope.
XML Schema (and thus XML and HTML) features lexical scope for its scope model in exactly the same way that JavaScript does. I cannot express enough just how important this single quality is to understanding JavaScript. For people coming from languages like C#/C++/Java this really seems to be the most challenging experience to wrap their heads around, but it is absolutely essential to understanding that language.
After XML Schema I would teach the DOM. I would teach this even before teaching anything about JavaScript. Understanding the DOM from a high level is a conversation of relationships and abstract modeling more than programming. Many web developers never get this and they forever suck as a result. This subject is so much easier to understand when separated from writing methods in a programming language and then so much easier to apply once the student gets to the programming part.
None of these principle standard technologies are hard to learn. They just need to be taught in the right order and expressed through practice. Security standards are hard, but web standards are easy. Yet, most developers I have ever known always fail on the easy stuff. If you, as a potential educator, aren't taking these technologies seriously then neither will your prospective students.
I would just start with HTML basics so they could build something "cool" right away. Part of a beginner class is getting them interested in the topic and showing them why it is important. Starting with one of the most boring topics is a bad way to do that.
I don't think it is targeted at complete beginners. Most of the topics are quite advanced and require some background knowledge.
On a related note, what do you mean by "lexical scope" in HTML? Unless I'm misunderstanding, I don't really see the parallel with HTML since it doesn't have variables.
I agree about teaching DOM separately from JavaScript. As someone who learned the DOM and JavaScript simultaneously, it took me a good while to learn which parts of JavaScript really were DOM APIs.
When you declare an element (or attribute) in an XML instance that isn't already defined as a body of the primary document or root schema this declared entity is available only to a limited scope. That limited scope is the element of declaration and its descendant nodes. Typically such declarations occur as the result of referencing a foreign artifact against a namespace.
You don't really see this capability in the common forms of HTML, but you can if you run the HTML as an XML serialization (regardless of the HTML doctype in the document). The execution context can be changed in many cases by sending a document with an XML specific media type or in some cases by changing the file extension from .html to .xhtml.
"Fundamentals" does not mean "the newest thing that has come through". It means almost the opposite.
It's your site, but if I meant fundamentals, I would call it fundamentals and start with fundamentals: HTML and CSS. If I meant building on the fundamentals, I would write about the standard uses of JavaScript to bring HTML and CSS to life. If I meant "newest things", I would call it a blog and talk about the newest things: recently implemented and incompletely supported APIs, such as notifications. Some of the newest things are very interesting as what they are: new things.
Maybe I'm missing something, but I don't see any reason to label a site "web fundamentals" and lead with something that has never been fundamental to the Web unless the agenda of "web fundamentals" is something other than teaching web fundamentals.
It's a good point. We chose to aim this at already practicing web developers and show them the best practice. There are already great HTML, CSS and JS resources over on MDN and we had no intention of competing with them.
The home page needs some work, clearly and we can sort that.
"Web push notifications allow users to opt-in to timely updates from sites they love and allow you to effectively re-engage them with customized, relevant content."
Christ, opting into these things has always been a mistake for me.
Anybody has a good reference on this? Including managing teams from different backgrounds and details on documentation and artifacts that support web projects?
So much of this would depend on the budget, and size of the project. What works great for an enterprise site... is total overkill for a small project. Likewise... it's seldom one person, or even one team, that does everything end-to-end... so like... maybe your role is only to get to UAT, and their team will take over for security screening, performance testing, hardening, launch... Do we include what dev, design, devops, marketing, sales, legal teams all care about? I'm sure that's not even a complete list of teams...
At an agency I worked for a few years back we had a sheet called "Getting to Done" -- looked something like this:
I've got a huge file on process, with sample documents... but every time I sit down to put it all together into something that can help new hires I hit a wall around who it needs to be written for. What size of company, what focus of the site, what department of the company, what role on the team...? I think the sample "technical alignment" document we used when taking over a web property was about 15 pages worth of questions... and we still had to verify all that stuff and look at the code and various metrics.
Point being this stuff is all a learning process for everyone... best practices evolve, technology evolves, standards evolve... if you manage web projects it's more about ongoing learning rather than memorization / repetition.
Heh, I actually wanted to include something like this in the original site. The very first version of the site we had a massive IA planning doc and guide, style-guides, mocks, prototypes, user-stories and user-profiles (the type of developers we wanted to write for). I've still got all the information.
I don't think we will end up getting this on to our site right now, but I would love to see it.
I think the title of the article (strike that, I mean the section heading above the title) is a bit misleading because it implies a wider context than was intended.
But in that wider interpretation of the title of course the management is key.
I am wondering though, aren't the most important aspects of managing web projects shared with managing other types of (technology) projects?
In case someone reading this can fix it, there's a typo:
> App install banners make it easy for users to add your app to their home screen with a single click, and is an indication to the user that the app their adding, meets an important quality bar.
"their" should be "they're", and there shouldn't be a comma after "adding", I think.
We are not saying to use Firebase although there is a firebase JS lib. If you use Chrome on Android it connects to FCM (which is backed by firebase product but it's not the same, it was called Google Cloud Messaging), if you Mozilla it connects to their push service. That's the way the spec works, the browser controls what push service you connect to.
You people complaining this isn't about fundamentals have your priorities skewed. The web today is all about selling things and web developers finding their next gig.
Those are the only fundamentals the web cares about today.
We do need to update the landing page, we've gone through many updates over the two years that this site has been out and I think this page doesn't explain what Web Fundamentals site is.
Our goal with this section is to explain the fundamentals of web development from the platform upwards with opinionated best practice guidance.
We are constantly adding new content for new areas of the web (like push notifications) and refactoring guidance as we learn more of how this is used in production (things change, but we base the initial guidance off how we have used it).