Wow, didn't even know about the Fetch API. XMLHTTPRequest, the API that changed software forever by igniting a wave of more powerful browser applications, is finally going to be replaced. Funny that the last 20 years of the web were all built on this ridiculous API that Microsoft came up with to try and make Outlook work in a browser. Good riddance, but you will be missed. Not that any of us has used that disgusting API directly in the last 10 years.
We used to do that stuff using frames back in the day. You’d have a hidden frame, change its url and look at what that dom contains. At scale, too. I was amazed at all the hoo-haa around that “new” xmlhttp API
We did the same thing, and to dynamically pull in content into the parent context, we created our own script block tag.
<div type="javascript">...</div> so that we could extract the JS and eval it in the parent context. The clunky thing was that you had to hand escape reserved html characters (&, <, etc) in your JS code. So many bugs...
Wow, then I think that I jumped directly to that hoo-haa since I didn't even consider the technique you are describing, I wasn't expecting today learning something from dynamic HTML past of the web. Thanks!
I still use on axios over fetch. Mainly because fetch doesn't have abort function. axios implements cancelable promise proposal that didn't go though TC39
Tho it has been a while since I checked TC39 status on fetch
Shout out to Philippe Rivière for the awesome work on d3-geo-polygon[1] (mentioned in the release notes), which enables tons of new map projections like these[2].
Philippe, if you're reading this, thank you. I'm really excited about d3-geo-polygon and I know a lot of others in the community are too.
Unusual map projections like these are often curiosities, but the can also be useful for certain topics, like mapping migrations[1][2][3] or showing airline routes[4][5].
Additionally, this project is a generalization of a feature that already existed in D3 (clipping spherical polygons to map boundaries -- previously you could only do this if the boundary in question was the antimeridian or a small circle centered at the origin). That generalization will make it easier to use some more common map projections that were already supported in d3-geo-projection[5] like as Goode's interrupted homolosine and Mollweide projections. These are useful projections for showing things like population density[6] where you care about preventing distortion in the landmasses but don't care about the oceans. While these projections were possible before, they required the use of SVG clip-paths and other tricks to prevent drawing outside the map bounds. In theory they could now be simplified using the polygon clipping implemented in d3-geo-polygon.
The sad state of affairs is that while D3 is brilliant in terms of API design, it is fairly low level, so few people use it directly. I've been using tools based on D3.js (like C3, NVD3) and it's been a joy.
However, last time I checked (~mid 2017), most of these hadn't migrated to D3 v4, so I'm not sure how fast v5 adoption will be. Maybe some will skip v4 altogether and go directly to v5?
At this point, I'm not sure which wrapper to use, because I don't want to get stuck with v3.
I needed a custom stacked timeline for the work system.
I was planning to do something horrible and then remembered d3 from a post years ago, day of futzing around with examples and it does it cleanly in less than 300 lines of code.
I'm looking to get my team into using D3 more as we begin to do more graphing and data visualization. Do any of you have recommendations on tutorials, classes and other learning aids?
That seems like a small update compared to v4. Wouldn't it be better to brand it as a minor version and provide backwards compatibility with deprecation warning where Promises were added?
Regularly occurring major versions, with only a small amount of changes, has actually kind of become seen as best practice in the JavaScript community. React, Node, Angular and a ton of other popular tools now release a major version update every year or 6 months. The reasoning is that by taking small, backward-incompatible steps, then developers are more likely to make the effort to install the latest update.
To understand the problems the community is trying to avoid, one only needs to go back to 2015-2016, when Angular 2 was released. At the time, AngularJS (aka Angular 1) was extremely hot; it had in record time become THE framework for any front-end developer to learn, and it looked set to dominate the landscape for years. And then, Angular 2 came out and it had a TON of changes. The learning curve of some elements of Angular 2 was very high for the average developer (TypeScript, reactive programming). And worst of all, the "migration path" from AngularJS to Angular 2 essentially amounted to a rewrite of your front-end application. Most never bothered updating their app, and most devs moved away from Angular, especially when React was released. All of that AngularJS experience that we accumulated became "outdated" in the span of about a year.
Sorry, but this is a rewriting of history and the present facts, and I can't let it go unchallenged.
React was first released in 2013, whereas Angular (2) was first released in 2016. React was already a very popular and rapidly growing framework by that point, so the idea that people adopted it simply because of Angular 2 is clearly false.
And while the migration process from Angular 1 to 2 was painful, it's simply untrue to say that nobody bothered, or that every AngularJS developer moved away. If you look at a source like https://hotframeworks.com/, which sources framework popularity data from GitHub and Stack Overflow, you can see that Angular has achieved a significant amount of adoption, and there are plenty of examples of people migrating successfully from 1 to 2+.
If following semver style: Major updates include backwards incompatible changes. Minor updates include new functionality but no backwards incompatible changes. Patch updates include no new functionality.
There are backwards incompatible changes, so it has to be a major bump.
Semver is awesome. If the owner adheres to it, then it can be a very strong signal to the downstream users about whether they should be able to [probably] upgrade seamlessly vs possibly having to do some major rework. Also, if you see an adherent of semver bumping the major number all the time, you can choose whether you want to sign up for the churn on subsequent releases or not. Semver seems to encourage backwards compatibility. Not force, but encourage. There's a reason Microsoft and Intel worship backwards compatibility. Your downstream users love backwards compatibility.
Its funny, when I landed my first job as a software developer, in a statistical startup, I learned about promises using d3.queue[1]. This was before javascript had native promises, and around the javascript community was settling on A+ promises. But d3 was how I learned to write asynchronous code without relying solely on callbacks.
Likewise, but in jQuery, which in one version introduced a feature where you could add listeners to an ajax request and it'd get called after the response returned - I was like what? how? whoa!?
https://github.com/d3/d3-queue has 1360 stars and gets 50% as many daily downloads as d3 itself, so I wouldn't be too sure that nobody out there is using d3's async facilities.
Readit News
It's been great to rely on a standard function, than any of the libraries to make http requests.
Tho it has been a while since I checked TC39 status on fetch
Well, duh. It was a lower level API, offering more control.
Fetch isn't much better. Half-arsed at best, and also needs a higher level wrapper to achieve the same terseness as popular AJAX utility libs.
Really?
It's not not terse.Philippe, if you're reading this, thank you. I'm really excited about d3-geo-polygon and I know a lot of others in the community are too.
[1]: https://github.com/d3/d3-geo-polygon
[2]: https://beta.observablehq.com/@fil/polyhedral-projections-wi...
[1]: https://commons.wikimedia.org/wiki/File:Map-of-human-migrati...
[2]: https://nordpil.com/static/images/redknot_migration.png
[3]: http://ngm.nationalgeographic.com/ngm/0603/feature2/map.html
[4]: https://imgur.com/5TFPcDa
[5]: https://imgur.com/6X91323
Additionally, this project is a generalization of a feature that already existed in D3 (clipping spherical polygons to map boundaries -- previously you could only do this if the boundary in question was the antimeridian or a small circle centered at the origin). That generalization will make it easier to use some more common map projections that were already supported in d3-geo-projection[5] like as Goode's interrupted homolosine and Mollweide projections. These are useful projections for showing things like population density[6] where you care about preventing distortion in the landmasses but don't care about the oceans. While these projections were possible before, they required the use of SVG clip-paths and other tricks to prevent drawing outside the map bounds. In theory they could now be simplified using the polygon clipping implemented in d3-geo-polygon.
[5]: https://github.com/d3/d3-geo-projection
[6]: http://www.jakelow.com/essays/mapping-the-world-population
However, last time I checked (~mid 2017), most of these hadn't migrated to D3 v4, so I'm not sure how fast v5 adoption will be. Maybe some will skip v4 altogether and go directly to v5?
At this point, I'm not sure which wrapper to use, because I don't want to get stuck with v3.
https://naver.github.io/billboard.js/
https://vega.github.io/vega/
https://vega.github.io/vega-lite/
I loved using D3 directly and found it amazing.
I was planning to do something horrible and then remembered d3 from a post years ago, day of futzing around with examples and it does it cleanly in less than 300 lines of code.
Genuinely impressive API as well.
[1] https://github.com/d3/d3-selection/blob/master/README.md#cre...
Thinking that promises are callbacks because .then() takes a function suggests misunderstanding.
To understand the problems the community is trying to avoid, one only needs to go back to 2015-2016, when Angular 2 was released. At the time, AngularJS (aka Angular 1) was extremely hot; it had in record time become THE framework for any front-end developer to learn, and it looked set to dominate the landscape for years. And then, Angular 2 came out and it had a TON of changes. The learning curve of some elements of Angular 2 was very high for the average developer (TypeScript, reactive programming). And worst of all, the "migration path" from AngularJS to Angular 2 essentially amounted to a rewrite of your front-end application. Most never bothered updating their app, and most devs moved away from Angular, especially when React was released. All of that AngularJS experience that we accumulated became "outdated" in the span of about a year.
React was first released in 2013, whereas Angular (2) was first released in 2016. React was already a very popular and rapidly growing framework by that point, so the idea that people adopted it simply because of Angular 2 is clearly false.
And while the migration process from Angular 1 to 2 was painful, it's simply untrue to say that nobody bothered, or that every AngularJS developer moved away. If you look at a source like https://hotframeworks.com/, which sources framework popularity data from GitHub and Stack Overflow, you can see that Angular has achieved a significant amount of adoption, and there are plenty of examples of people migrating successfully from 1 to 2+.
There are backwards incompatible changes, so it has to be a major bump.
Thank the lord!
[1]: https://github.com/d3/d3-queue