351–360 of 412 posts
Earlier quoted context omitted.
Presumably this occurs when the site uses a CDN for their js libraries (or even their main js). After a few days you start to spot which domains need to be enabled and which can be safely ignored.
Can you whitelist a CDN but only for a specific site?
One thing to consider is that at larger companies, we already have a difficult enough time testing all of our site with JavaScript enabled. Netflix building a version that works without JavaScript is like asking them to build a second website, especially from a QA perspective. When you look at your users and find that .5% of them are not running JavaScript, how do you justify spending the money for that few of people…
Less javascript would be an improvement for everyone, not just the noscript users.
>Verdict: Cartography catastrophe. As much as I hate JavaScript, Google Maps gets a pass. I'm pretty sure the code behind it is thoroughly tested. We can just suck it up and turn JavaScript on for one of the most useful tools from the internet -- how hard is it to find something that whitelists domains to run JS anyway?
There should be something as a fallback, though, surely? Take out all the functionality, by all means, but at least give me a map image. If you can't even get link-to-zoom working to display different images, just give me a map image based on my IP location; give me anything rather than nothing.
Earlier quoted context omitted.
Google maps is a useful tool. It also had a habit of freezing an older (core2) laptop I was still using completely (with Firefox). Not just the browser, the whole OS. Had to power cycle. From time to time I'd forget and go back to Google maps were the cycle would repeat. Why was I still using a core2? Because it worked fine for almost everything else. Got a better second laptop and no more issues but still... there w…
It's probably WebGL-related. Some Firefox update seems to have fixed it for me recently but for quite a while I could only visit Google Maps in a brand new Firefox instance, because any attempt to use it in a well-aged process would crash firefox and emit graphics errors to dmesg. You may have a poorly-supported WebGL stack.
Now that I've updated to 16.04 firefox runs better than it did but chrome still blows it away.
Earlier quoted context omitted.
the list of sites on https://hnpwa.com/ vs this https://news.ycombinator.com/
Would you prefer that Hacker News reloaded the page every time you voted on a comment?
Earlier quoted context omitted.
We've already learned from our past mistakes changing the prototype of the standard library - the Ruby community learned the same thing with monkey patching their standard lib too. The maintenance overhead far outweighs any immediate benefits.
What maintenance overhead? Current and future costs are reduced by making code simpler and cleaner in the first place by using prototypes efficiently. Also, to be clear, I'm suggesting adding new methods to DOM object prototypes, not changing behavior of existing methods.
Earlier quoted context omitted.
the list of sites on https://hnpwa.com/ vs this https://news.ycombinator.com/
Would you prefer that Hacker News reloaded the page every time you voted on a comment?
One of my clients loads a 4.5 Mb bower.js (including Angular with a lot of components and jQuery), they also include an extra jQuery script, a full jQuery UI and several other scripts on each pageload . Nothing is minimized. The bower file alone has 300k in comments. The CSS file is also nearly 1 Mb. It's just a simple website with some forms. They have 2 developers working on the site, a scrum master, a project mana…
We're starting to get there.
JS Modules gives us static exports/imports, so we can statically analytics the dependency graph and identify functions that aren't used and do tree-shaking to remove them. Rollup and Webpack2 already does this, but there's more to go.
CSS Modules creates a contract between the your CSS and what uses it. As you have to import it, and exports are static, you can understand which style files are imported where. Next step would be to understand which classes are used inside that module and strip those that remain unused. This is theoretically possible (providing you use a more 'statically safe' syntax), but tooling hasn't yet popped up to do this.
One of my clients loads a 4.5 Mb bower.js (including Angular with a lot of components and jQuery), they also include an extra jQuery script, a full jQuery UI and several other scripts on each pageload . Nothing is minimized. The bower file alone has 300k in comments. The CSS file is also nearly 1 Mb. It's just a simple website with some forms. They have 2 developers working on the site, a scrum master, a project mana…
This part is more of a shameless plug, but I believe public/industry/developers should be aware of what tools & techniques academia develops so that the researcher's efforts can be more useful. There are some static analyzers for JavaScript such as JSAI, SAFE, and TAJS (disclaimer: I'm working on a project related to JSAI on the lab which developed it). These static analyzers can discover the dead code if given all the entry points however:
- They don't have facilities to report the dead-code AFAIK (this is a trivial thing to add _in theory_, if there are parts of the program _unvisited_ by any of these, that part of the program is guaranteed to be dead). If somebody wants to add such a facility to any of the tools they are welcome. In case of JSAI, I'm willing to provide them all the information I can.
- They are conservative (e.g. sound) tools and may find too few dead code results.
- They don't play well with `eval` & friends in general although they try their best[0], the web frameworks rely on eval-like highly-dynamic approaches a lot to be generic enough and that hurts precision of such analyses dramatically.
[0]: https://pdfs.semanticscholar.org/8140/feec021818815c55a43b54...
[1]: https://www.cs.purdue.edu/sss/projects/dynjs/eval-TR.pdf
Earlier quoted context omitted.
Not really an answer to your question, but this might be useful: http://youmightnotneedjquery.com
Yeah. Except you need to do Ajax and fetch doesn't cut it. So new lib. And manipulate the dom with something better then the browser API or you loose your mind. So new lib. Then normalize browser events. Oh wait, you can do that manually. But you are writing a new lib. Eventually the code will grow to be the size of jQuery anyway. Only not as well tested, documented and cached.
curious as to why you think this? fetch is pretty convenient to use. We created our own wrappers around it, but that basically just consists of ajax = (url) => fetch(url).then(res => res.json())