4 ms·

> Except for the hot reloading (which you mention twice btw) the tooling for the popular languages has everything in the list, and most can be achieved with GDB

> Except for the hot reloading (which you mention twice btw) the tooling for the popular languages has everything in the list, and most can be achieved with GDB and Wireshark alone, in any language that GDB supports. "Can be achieved" with some additional tools. I doubt you can easily expect the structure of the app, how it repaints, see all the relevant network requests, and also introspect and query the running app, emulate various hardware, inspect and debug animations etc. in most languages. Yes, there are collections of tools that may give you all that in aggregate, but frankly, it's not close to an "out-of-the-box" experience. > there's no point exaggerating. It's not really exaggeration.

worksonmine 3y ago
Have you used GDB? And network requests is what Wireshark was created for. Browser developer tools don't "emulate hardware" they change the viewport and throttle network, there's a huge difference. It seems you don't have much experience in the tools you're comparing against. In GDB you would connect to a running application on actual hardware or in a VM, if that's what you're testing. Screen sizes and network can be done locally. As far as all-in-one solutions go that's a new goal post, your first comment mentioned "tooling", and hot reloading is not a part of the browser so it's still an "aggregate" as you like to call it. For me it's the unixy way of doing things and just the way I like it. Do one thing and do it well.
- illiarian 3y ago
  > Have you used GDB? I've used debuggers in general (IDEA, Resharper, Visual Studio), and even dabbled with disassemblers like IDA in my youth. > Browser developer tools don't "emulate hardware" they change the viewport and throttle network, there's a huge difference. So, out-of-thebox int their primary tool frontend developers get: viewport simulation, cpu throttling, network throttling, sensor simulation (geolocation and orientation). And can emulate performance with different number of processor cores. Not bad https://developer.chrome.com/docs/devtools/performance/reference/#hardware-concurrency https://developer.chrome.com/docs/devtools/performance/refer... > As far as all-in-one solutions go that's a new goal post, your first comment mentioned "tooling", and hot reloading is not a part of the browser Wat. The original comment claimed this: "Maybe the web ecosystem will finally get some sane tooling". So yes, hot loading is a part of tooling. I've yet to see anything outside the web manage hot reloading with any degree of confidence and speed. You don't like the hot loading, and let's focus on non-moved non-goal non-posts. I hope you noticed the ellipsis at the end of my list? What's that immediately available tool for GDB and Wireshark whatever that: - can let me examine and change the UI of the app on the fly? Including handful tools like layout overlays, layers etc. - examine and debug animations? - analyze paint/re-paint performance? - view and debug delayed background actions? - record and replay user flows? ... ^ Note the ellipsis again. The build tools for Web are undoubtedly atrocious. However, there are very few, if any, tools that come even close to the versatility and ease of use of the tools that exist for the web ecosystem.
  - worksonmine 3y ago
    > So, out-of-thebox int their primary tool frontend developers get: viewport simulation, cpu throttling, network throttling, sensor simulation (geolocation and orientation). The linux kernel has KVM, doesn't get more out of the box than that. Do what you want with it. Emulate ARM? Sure why not. > The original comment claimed this: "Maybe the web ecosystem will finally get some sane tooling". Not my comment, I'm addressing your claim of "tooling most languages can't even dream of". The ellipsis doesn't really matter I'm not here to guess what you're meaning. - can let me examine and change the UI of the app on the fly? Including handful tools like layout overlays, layers etc. Most debuggers including GDB can print and set state. > - examine and debug animations? > - analyze paint/re-paint performance? I don't do GUI development but you'll have to use a tool specific to the environment you're working with (just like how the DOM is a specific environment). What tool do you use to debug webview? Not your main browser. Systems development is the same. > - view and debug delayed background actions? You can get the time spent on anything down to individual assembly instructions if you wish. > - record and replay user flows? rr (which is GDB compliant hence integrates well with termdebug in vim). I don't disagree that there are many tools for web dev. But they're not always better or easier to use. The built-in nodejs debugger is shit compared to GDB for example. My point is that everything you can do in browsers that aren't browser specific exists for other languages as well. Many times very specialized with better features that the devtools version. Again, I love web development, but I also live in the terminal and love those tools even more. I wish they existed for the web.

worksonmine 3y ago

Have you used GDB? And network requests is what Wireshark was created for. Browser developer tools don't "emulate hardware" they change the viewport and throttle network, there's a huge difference. It seems you don't have much experience in the tools you're comparing against. In GDB you would connect to a running application on actual hardware or in a VM, if that's what you're testing. Screen sizes and network can be done locally. As far as all-in-one solutions go that's a new goal post, your first comment mentioned "tooling", and hot reloading is not a part of the browser so it's still an "aggregate" as you like to call it. For me it's the unixy way of doing things and just the way I like it. Do one thing and do it well.

illiarian 3y ago
> Have you used GDB? I've used debuggers in general (IDEA, Resharper, Visual Studio), and even dabbled with disassemblers like IDA in my youth. > Browser developer tools don't "emulate hardware" they change the viewport and throttle network, there's a huge difference. So, out-of-thebox int their primary tool frontend developers get: viewport simulation, cpu throttling, network throttling, sensor simulation (geolocation and orientation). And can emulate performance with different number of processor cores. Not bad https://developer.chrome.com/docs/devtools/performance/reference/#hardware-concurrency https://developer.chrome.com/docs/devtools/performance/refer... > As far as all-in-one solutions go that's a new goal post, your first comment mentioned "tooling", and hot reloading is not a part of the browser Wat. The original comment claimed this: "Maybe the web ecosystem will finally get some sane tooling". So yes, hot loading is a part of tooling. I've yet to see anything outside the web manage hot reloading with any degree of confidence and speed. You don't like the hot loading, and let's focus on non-moved non-goal non-posts. I hope you noticed the ellipsis at the end of my list? What's that immediately available tool for GDB and Wireshark whatever that: - can let me examine and change the UI of the app on the fly? Including handful tools like layout overlays, layers etc. - examine and debug animations? - analyze paint/re-paint performance? - view and debug delayed background actions? - record and replay user flows? ... ^ Note the ellipsis again. The build tools for Web are undoubtedly atrocious. However, there are very few, if any, tools that come even close to the versatility and ease of use of the tools that exist for the web ecosystem.
- worksonmine 3y ago
  > So, out-of-thebox int their primary tool frontend developers get: viewport simulation, cpu throttling, network throttling, sensor simulation (geolocation and orientation). The linux kernel has KVM, doesn't get more out of the box than that. Do what you want with it. Emulate ARM? Sure why not. > The original comment claimed this: "Maybe the web ecosystem will finally get some sane tooling". Not my comment, I'm addressing your claim of "tooling most languages can't even dream of". The ellipsis doesn't really matter I'm not here to guess what you're meaning. - can let me examine and change the UI of the app on the fly? Including handful tools like layout overlays, layers etc. Most debuggers including GDB can print and set state. > - examine and debug animations? > - analyze paint/re-paint performance? I don't do GUI development but you'll have to use a tool specific to the environment you're working with (just like how the DOM is a specific environment). What tool do you use to debug webview? Not your main browser. Systems development is the same. > - view and debug delayed background actions? You can get the time spent on anything down to individual assembly instructions if you wish. > - record and replay user flows? rr (which is GDB compliant hence integrates well with termdebug in vim). I don't disagree that there are many tools for web dev. But they're not always better or easier to use. The built-in nodejs debugger is shit compared to GDB for example. My point is that everything you can do in browsers that aren't browser specific exists for other languages as well. Many times very specialized with better features that the devtools version. Again, I love web development, but I also live in the terminal and love those tools even more. I wish they existed for the web.