7 ms·
Maybe the web ecosystem will finally get some sane tooling... or not because those devs will probably be driven to madness.
by voidfunc 3y ago
Maybe the web ecosystem will finally get some sane tooling... or not because those devs will probably be driven to madness.
- illiarian 3y agoFunnily enough, web ecosystem has tooling most languages can't even dream of. - Instant hot reload of application - Inspect app/page structure in runtime - Runtime debugging - Monitor all network requests - Tools to monitor time spent in functions, painting, redrawing... - Runtime changes instantly applied ...
- camdenreslink 3y agoMany languages have all of that tooling and more. For example C# and Java. I think Rust has all of that except the hot reload and runtime changes.
- illiarian 3y ago> Many languages have all of that tooling and more. For example C# and Java. Instant hot reloading? Runtime introspection into apps, and into strucutre of the apps, direct view into what the app sends over the network etc.? Open up development tools in your favorite browser, you'll be surprised :)
- blackoil 3y agoDon't know of current state but Blazor should check most of them.
- illiarian 3y agoBecause Balzor piggy-backs the existing web tools ;)
- kaba0 3y agoWell, java in debug mode can hot swap class methods, for what it worth. But the web is definitely the most used “GUI framework” ever, so there is no competition with that on tooling ground, even if there is nothing inherently that would block it, as a dom inspection is pretty easy to implement - just print out the tree of ui nodes.
- Ygg2 3y agoAt expense of browsers complexity rivaling operating systems. And now there is essentially one browser who can afford such complexity. Until Google discontinues it.
- chrisco255 3y ago> at expense of browsers complexity rivaling operating systems. That's a feature, not a bug, as open source browsers have loosened the importance of the operating system (freed us from the MS monopoly) and enabled an multi trillion dollar web app industry to flourish. If Google ever discontinued Chrome support it would be picked up by the community in a flash. That's the beauty of open source.
- illiarian 3y ago> If Google ever discontinued Chrome support it would be picked up by the community in a flash. Of course it wouldn't. The number of people capable of managing and developing a full-blown browser is minuscule. Even Microsoft gave up and went with Chrome in the end. Case in point: how many people picked up Servo? Hell, even Firefox?
- marcosdumay 3y agoTo be fair, the number would increase a lot if Google stopped making the web hostile for other software.
- bzzzt 3y agoAll that stuff that could be done with a Java (or probably .net or php) server side webapp stack two decades ago...
- chrisco255 3y agoInstant hot reloading without even recompiling/refreshing the page? Sorry, try again. Flame charts in Visual Studio 2003? Sorry, try again.
- worksonmine 3y agoJavascript hot reloading requires a "recompile", you just don't notice it. Import a plain js file without any node tooling and see what you get for free.
- illiarian 3y ago> Import a plain js file without any node tooling and see what you get for free. I get F5 to refresh the page when source code changes. All the other tooling remains the same: https://developer.chrome.com/docs/devtools/ https://developer.chrome.com/docs/devtools/ I mean, Chrome even has an animations debugger
- worksonmine 3y ago> I get F5 to refresh the page when source code changes. Really? That's surprising but so overkill. How does it know what files to poll and which not to, I assume file:// and localhost but more specific? Does it do it for a webpack/vite app which has its own hot reloading setup?
- illiarian 3y agoWhat do you mean? F5 refreshes the browser page. This has been the way to develop pages since the first browsers. And the original question was "Import a plain js file without any node tooling and see what you get for free." You don't get hot reloading but you get all I wrote in my original comment and much more for free.
- LandR 3y agoPretty much any lisp.
- worksonmine 3y agoExcept 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. Don't get me wrong the web pays my bills and I like it but there's no point exaggerating.
- illiarian 3y ago> 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 agoHave 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.
- co_dh 3y agoAny language with repl can have it . Python for example
- Uehreka 3y agoYou make a good point, I’ve been saying for years that hot reload is too fast. Rust compile times really give you time to meditate and reflect.
- rk06 3y agoWhat sane tooling are you talking about? FE projects takes minutes to build while backend projects can take hours.