2 ms·
On a related note: I've had to help train a bunch of Java/C++ devs about web dev over the years. I've also talked to a lot of new devs. One thing I noted is tha
by acemarke 4y ago
On a related note: I've had to help train a bunch of Java/C++ devs about web dev over the years. I've also talked to a lot of new devs. One thing I noted is that there wasn't a good resource that tried to explain the key pieces of web dev concepts, terms, and technologies, and how they fit together. So, I ended up writing a "How Web Apps Work" blog series to try to fill that gap:
https://blog.isquaredsoftware.com/series/how-web-apps-work/ https://blog.isquaredsoftware.com/series/how-web-apps-work/
The series provides an overview of HTTP and servers, client dev, browsers / HTML / CSS, JS / DOM, and AJAX.
A number of folks have told me they found the series particularly helpful.
- aastronaut 4y agoI just read through your post on servers[1], as I'm currently in a similar boat (webdev working with C++ devs). I think the biggest hurdle for such developers are things like: - statelessness of the server (REST) - the lifecycle of a single request - the lifecycle of a single (server-)app (microframweworks) OOP devs unfamiliar with server development tend to pollute the app lifecycle with hidden state in some singletons that are swirling around globally. The requirement that servers should be able to parallelize request-processing is mostly an afterthought and hidden app state makes it impossible to parallelize anything. A sequence diagram of a single request would help there a lot IMHO and a short explanation of how to keep the response times short, by doing long-running tasks in the background with message queues. [1]: https://blog.isquaredsoftware.com/2020/11/how-web-apps-work-http-server/ https://blog.isquaredsoftware.com/2020/11/how-web-apps-work-...