There is no difference, webdev is someone who solves problems with web tech, mobile dev is someone who does mobile apps, embedded dev works with low level components, etc. It’s all development, and often the two will mix.
For example, I worked at a startup using C for embedded stuff, Go for the server stuff, and web tech for the FE. Rust wasn’t out yet, so C was the best option for interfacing with the board components (in this case a math module for our signal processing), Go was a good mix of performance and ease of training new devs, and a web FE was the lowest barrier to getting our customers using our product (basically a high end IOT device). We built a small native FE for certain simulations, and eventually moved it to a server with a web FE.
At my current role, we build a reporting and simulation app for a niche industry. We do everything from simple forms to 3D rendering to simulations that take hours to complete (most are 15-45min). Our customers use crappy laptops, so doing the processing locally isn’t an option (they probably don’t have enough RAM anyway), so we’re going to need a server. Because of that, we decided to build it as a web app. We still have native components (some simulations use C++, another was Fortran until recently, etc), and they’re maintained by Ph.Ds in our field because the hard part isn’t the coding (our JS specialists could handle that, they’ve built a 3D app in the last few months with complex transformations and calculations due to business login needs), but knowing the math behind it all, hence the researchers.
Not all web apps are overengineered crap because they hired a dev team to build a static site, there are apps like the two I mentioned that do interesting things and happen to use web technologies.
There is no difference, webdev is someone who solves problems with web tech, mobile dev is someone who does mobile apps, embedded dev works with low level components, etc. It’s all development, and often the two will mix.
For example, I worked at a startup using C for embedded stuff, Go for the server stuff, and web tech for the FE. Rust wasn’t out yet, so C was the best option for interfacing with the board components (in this case a math module for our signal processing), Go was a good mix of performance and ease of training new devs, and a web FE was the lowest barrier to getting our customers using our product (basically a high end IOT device). We built a small native FE for certain simulations, and eventually moved it to a server with a web FE.
At my current role, we build a reporting and simulation app for a niche industry. We do everything from simple forms to 3D rendering to simulations that take hours to complete (most are 15-45min). Our customers use crappy laptops, so doing the processing locally isn’t an option (they probably don’t have enough RAM anyway), so we’re going to need a server. Because of that, we decided to build it as a web app. We still have native components (some simulations use C++, another was Fortran until recently, etc), and they’re maintained by Ph.Ds in our field because the hard part isn’t the coding (our JS specialists could handle that, they’ve built a 3D app in the last few months with complex transformations and calculations due to business login needs), but knowing the math behind it all, hence the researchers.
Not all web apps are overengineered crap because they hired a dev team to build a static site, there are apps like the two I mentioned that do interesting things and happen to use web technologies.