I usually try to pop into the debugger from within unit or integration tests, but have found this to be very slow and unreliable when doing it over a port. Have you found your experience to be different?What is your setup to debug mocha.js (or another framework) tests in chrome?
Is there a way of doing a long running log of all network, page load speeds, etc. in Chrome and store it in a reasonably efficient format? Like a perfmon/tracer for the browser.
I ask this because I've been trying to track down an issue - probably caused by an ad on a news website - where Chrone pretty much freezes up on all processes. Whilst I can (and have) worked around it by installing uBlock Origin in browsers I'd really like to know what is causing the problem. I can't produce it locally so I'd like to get a log of all things that occur on Chrome over the course of a day.
They mention "Progressive web apps" and link to some info, but I can't figure out what the difference is from a normal webpage. Do they mean "web apps that use some stuff that was recently added to most modern web browsers"?
Generally, a "progressive web app" is something that behaves a bit like a regular native app, when the browser supports it and user allows it. This includes using serviceworkers to cache data for offline (and low bandwidth) use, making a home-screen icon that launches a standalone (from the task switcher perspective) window with no browser frame, and so on.
I'm a fan of the concept, hating apps that could easily have been webpages (public transport apps are often a good example), so it sounds like a good idea to give this a name and promote it. It's too bad that this name sounds like Microsoft came up with it in the early 2000s, but oh well.
It's an awesome idea and one that is actually not too hard to implement, at least partially. Problem is browser support of the APIs, with Safari lagging behind.
Yah, the tricky bit is safari access. I'd love to put a bunch of time into using service workers, push notifications, and so on to make an app-like experience for my users (it's a forum / social network thingy for teachers), but mobile safari really puts a crimp in those plans. Instead I have my own homegrown cache and other hairy tricks that are nonstandard, but work on safari.
It's a laundry list of enhancements that are usually not in any way critical to business and product requirements, and whose absence will likely not be noticed by many users. Great to have and I support the idea 100%, but this stuff is usually the first to get cut when launch is looming, and for good reason.
According to google a progressive web app is a website that progressively becomes an app the more you interact with it.
So I guess at first visit you get things like service workers and notifications. Then after like 5 or so visits you get to install it to the home screen and the address bar optionally gets hidden or played around with or something.
After 5+ years of developing in Chrome Dev tools, I switched to Safari 2 weeks ago (Mac) and couldn't be happier. Chrome has become bloated. Ever notice CPU fans ramping up? Only while Dev Tools is open. Memory hog is an understatement. Furthermore, while Chrome's light, prebundled Flash was an asset 3 years ago it's now a liability: most websites now gracefully fallback to HTML5 video. Safari's upcoming leading edge standard support announcement makes it a candidate for best dev browser. (Hint: try Safari's Responsive Mode)
Page loads feel faster in Chrome for me, but yes, the dev tools are much cleaner. There are at least worth a second look if you can't find the bug in chrome.
I switched to Safari 2 months ago for the same reasons as you did. Definitely feels better speed-wise. Also with iCloud keychain I decreased 1Password usage.
For development though, I still can't get use to Safari's developer tools.
Many news sites insist on Flash still. The shitty thing is that if you use the Developer menu in Safari and change user agent to iPad Safari they often play the video using html5.
It's ironic that scrolling stutters so much on a Google Developers page when using Chrome on Android (51.0.2704.81). Inertial scrolling is broken too.
I rarely have this problem on other sites. It usually only occurs on Javascript heavy sites (disproportionately frequently on Google sites using that Material UI toolkit).
I'm using a Samsung S7, but had this same issue on my Nexus 6.
I'm glad to see Css source diffs in there. My workflow consists of tweaking Css in dev tools and then updating source. I've found that if I map directly so Devtools updates the source file I get lost very quickly.
Incidentally I'd be interested in knowing of better ways of writing / debugging css.
slowly the browser is becoming an JS IDE, and that's nice. Ctrl-Shift-I can become the "READY" prompt of the C64.
The "next thing" is CDT auto-saving your changes to css and js for a website, and optionally re-applying them on future browsing.
Excited to see better support for App Cache and Service Workers. I still have a bad taste in my mouth from trying to integrate them into one of my applications.
Scrolling is broken in Safari on this page. Maybe the page authors should spend less time in the Chrome dev tools and more in the dev tools of other browsers.
I'm glad these folks spend their time on Chrome dev tools rather than catering to the users of inferior browsers who expect people to invest extra energy catering to their preferences.
How can you seriously think that Google developers not supporting other browsers than Chrome is ever a good thing? We are already headed quickly enough towards a Chrome monopoly and Google abusing their dominant position on the internet to make other browsers look bad isn't making that any better.
Whilst the issue may not be the fault of the web designers, there's not really any need to call Safari inferior. It's probably a bug, all browsers have them.
My main issue, FWIW, is not that Apple don't fix bugs - it's the long timeframes they take between releases!
Rarely is any description 'needed', but in this case it is 'helpful'. The parent seems to be unaware that Safari has, over time, become inferior (relative to the other popular browsers) increasing the likelihood that the problem is with safari rather than with the site. Being unaware of the inferiority of safari, he didn't even try another browser. Simply knowing that its a safari bug may not be sufficient to maximize the efficiency of his problem solving strategy in the future, as he may brush this off as anomalous. Knowledge that others have found safari increasingly buggy and inferior makes it more likely the parent may adopt a better strategy, such as 'test with another browser first'
You certainly have made a lot of assumptions about me. I did test in other browsers - Chrome, obviously, and Firefox. But the fact that it works in Chrome and Firefox doesn't excuse the fact that it doesn't work in Safari. I'm a web developer, so it's my job to make things work correctly in all the browsers, Safari included, so from my perspective the creator of the page did a bad job.
Worse, it wasn't something fancy that it's understandable isn't supported in older browsers - it was scrolling, something that literally every web browser ever has been able to do.
Finally, as a web developer and as someone that has used Safari as his primary browser for many years, I rarely have an issue with Safari being "buggy and inferior". You may not get cool new APIs first, but Safari is usually pretty solid and bug-free with the ones it does support.
What, specifically, do you consider inferior about Safari? I'm genuinely curious - I use Chrome, Firefox and Safari regularly and I find Chrome and Safari to be of equal quality. And I notice bugs in Chrome every now and then, but with both browsers I find it pretty rare these days.
Well, as a for-example, safari's support for indexeddb, service workers, push notifications, and just about everything that makes progressive web apps interesting is pretty lacking.
As another for-example, I was able to hard-crash safari on ios by setting some CSS attributes on the scroll track about eight months ago - like literally a web page with css that altered how wide the scroll bar track was could CTD safari on ios.
As another for-example, KeyboardEvent.key isn't supported in safari.
As another for-example, http://caniuse.com/#compare=chrome+51,safari+9.1,ios_saf+9.3 and scroll down. Battery Status API, Fetch API, Proxy Objects, Shared Web Workers, on and on. The "modern" web as a good platform for interesting progressive apps is passing safari, in particular iOS users, by.
One assumes a motivator here is the app store: apple's walled garden approach is fundamentally incompatible with web apps gaining all these APIs, whereas android's (relative) openness means Google is less uptight about people deploying apps without going through the app store approval process.
My view is that Safari is leading in privacy and lags in everything else. Meanwhile Chrome absolutely leads in security while Firefox leads in standard support.
I use Chrome for work and Safari for casual browsing. Safari definitely has better tab management (tab expose). I am also sad that Firefox UI looks stale. Their settings & options window look like it hasn't changed since initial release.
NodeJS and Chromium have complete different debugging API's. It would be cool if they where the same, so you could reuse the debugging tools on both platforms.
> Thanks to the V8, DevTools, and Google Cloud Platform for Node.js teams, you can now use all of DevTools’ powerful debugging features to introspect a Node.js app.
