71–80 of 124 posts
Earlier quoted context omitted.
if(x) throw x
The reason this doesn't work in the same way is because it requires you to know where the error occurs. You tend to operate on a data structure and know that at some point x becomes y. By placing a watch on x you find out where that point is. Editing the code does not get you this (bar modern proxies in js).
Earlier quoted context omitted.
Clearly the guy didn't have to pull out a working PoC in one week with a forced uppon JS framework that just changed its public API and not its doc and that need magic lines just for webpack to not crash. Or that has to pull data from a manually written csv our client uploads at 3 pm on their managed ftp and an untested REST api designed last month by a one man start up, using a legacy client lib that only god and a…
This says much more about the work environment front-end developers are subjected to than anything else.
Or contribute to a mess of an open source project that your microservice happen to depend on.
Or debug your student exercice that found yet a brand new way to crash that you never heard of.
Or find what are the side effects of your 3am emergency fix during the last red teaming.
Programming is a vast land.
Brian W. Kernighan and Rob Pike wrote that stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Kernighan once wrote that the most effective debugging tool is still careful thought, coupled with judiciously placed print statements.
A lot of programming these days involves sending and interrogating complex data via awkward and ill-documented APIs and no amount of abstract a-priori thought or judicious print statements (and good luck printing anything with complex structure with C or Go) is gonna come anywhere close to being able to do an API call, drop into the debugger to see what's going wrong, pretty print deeply nested data sanely and effortlessly and fix up some code or value in the debugger and press on.
Earlier quoted context omitted.
if(x) throw x
The reason this doesn't work in the same way is because it requires you to know where the error occurs. You tend to operate on a data structure and know that at some point x becomes y. By placing a watch on x you find out where that point is. Editing the code does not get you this (bar modern proxies in js).
Brian W. Kernighan and Rob Pike wrote that stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Kernighan once wrote that the most effective debugging tool is still careful thought, coupled with judiciously placed print statements.
I actually really like to debug Ember.js code. Because of the source map, I always see my code as I wrote it and I know when I'm in the framework's code. Clean, well written and modern framework, like Ember.js, which supports the developer and help to implement features much faster are great choice and you won't have those problems what were mentioned in the article. Use great tool not the hyped one... https://emberj…
I mean, I sort of get the intercooler.js dude (if anything, I kind of came around to his perspective and am now all in on Phoenix' LiveView), and I can see how people would be all into Go and whatnot, but Ember is one of those things that I just don't understand anyone being evangelical about..
It's not the debugger that is broken, it's the entire JS ecosystem. It's such a terrible language we spent the last 2 decades fixing its warts, adding one layer on top of the other. And now you have es7 + typescript + jsx + some magic introspection + code splitting + weird non standard imports, all that turned into regular JS and source maps, in a complex concurrent and async env that deals with graphics AND the netw…
It's not the debugger that is broken, it's the entire JS ecosystem. It's such a terrible language we spent the last 2 decades fixing its warts, adding one layer on top of the other. And now you have es7 + typescript + jsx + some magic introspection + code splitting + weird non standard imports, all that turned into regular JS and source maps, in a complex concurrent and async env that deals with graphics AND the netw…
Meanwhile vanilla JS is a pleasure to work with. Sure, you can't make a monkey write good JavaScript but you cant do that in any other language either.
I wish I could remove JS from the browsers and watch all the fanboys trying to pretend they still like it now that it doesn't have an accidental monopoly on the most popular platform in the world.
It's not the debugger that is broken, it's the entire JS ecosystem. It's such a terrible language we spent the last 2 decades fixing its warts, adding one layer on top of the other. And now you have es7 + typescript + jsx + some magic introspection + code splitting + weird non standard imports, all that turned into regular JS and source maps, in a complex concurrent and async env that deals with graphics AND the netw…
You can do great things without all that tooling if you're able to only target modern browsers (>90% of the market):
- https://www.npmjs.com/package/htm#example
- https://www.npmjs.com/package/preactz#example-app-with-unpkg