One critique would be to use node-fetch, instead of request.
There was a site (weatherpixie.com) that I used to really like... there was a pixel art character (several to choose from) that would wear different clothes or have an umbrella based on the weather, with a few different backgrounds and a cat that may or may not be there ("because cats are like that"). It was embeddable, and awesome. There was an HDD crash around 2010 iirc, and the site never really returned. Not sure if the artwork was lost too, as I keep thinking it would be nice to "rebuild it". Maybe around a cloud platform with a little redundancy in place.
In the end, people will gather around in the box tooling, until something better enough to break out comes along. In this case, Jest includes assertions, and the testing syntax isn't completely alien... it also offers integration of babel easily, and istanbul in the box. Yeah, it's more configuration, but that isn't always a bad thing.
It's pretty cyclical... as things approach a good point of equilibrium. As long as choice remains, and it's easy enough to change many things later... I've seen things change out several times the past few years. And some of the composite tooling seems to be using other tools under the covers, or you can use those alone.
Well, I'm not sure how much better it's gotten, I've frankly switched to Jest mostly... but nyc + istanbul + babel + mocha + chai (not to mention eslint and prettier), it begins to get unweildy... While I prefer chai for assertions, I like jest. Though I tend to favor babel-plugin-rewire + sinon for mocking most things, Jest has been pretty nice... for what I've used it to compare, I went from nearly a minute to under 12 seconds on the one project I converted.
Of course your code structure, and what it's doing will obviously vary.
Node.js was a pretty uphill battle for several years in some organizations. My first corp deployment of node was literally because I was playing with it, and researching a few things, and was able to get an API written and deployed for something in a couple of hours, when another dev quoted a week for a .Net project. LOL... A mongodb a synchronization project, and an API node project all written/deployed in under a day, and ran on a "backup" server used for job processes, reverse proxied from the main server (Application Request Routing, ARR under IIS).
I spent the next couple years about half node, half C#... and the past couple years mostly node. I actually prefer it for most things. But it's not like it was an easy sell early on at all for me.
Interesting take on component styling, though I expected "CSS in JS" aka "JSS" as the subject. I've been pretty happy with JSS, which supports things like nested media query targets, etc, which I'm not sure the styled components supports.
Because the text accompanying the video didn't seem to have the relevant links, I'm including them below.
[1] https://github.com/styled-components/styled-components
[2] https://github.com/romellogood/awesome-styled-components
I think the only real gotcha that catches me frequently is "className"... The rest, not so much. Also starting to like JSS as well. It's just such a natural fit, even if it feels much more verbose.
JSX does feel much more like HTML + JS to me than any templating library ever has. From handlebars/mustache to angular, to vue, to whatever else. JSX is a realization I'd been hoping for since first working with E4X (which never gained adoption outside moz), it was just a nice way to work with things, and imho JSX is better still.
Disagree with Angular as "Better fit for enterprise-grade applications than React" ... If you want typescript, you can use it with React. As for anything else, Angular gets in your way far more often than it helps with its' prescriptive patterns.
Even when using gulp, browserify, webpack, etc, I still recommend that people setup their actual task list in package.json so it's more consistently discoverable.
I think it might have been better to specify npm tasks in package.json, then have the pom.xml reference `npm run build` etc, instead of gulp directly. This could emphasize the separation of the node/js world to the app and beyond this, it would allow the client portion of the project to work as so many other projects do in the client-side space today.
Shouts to @nodeaz and the #gulpjs guys.
One critique would be to use node-fetch, instead of request. There was a site (weatherpixie.com) that I used to really like... there was a pixel art character (several to choose from) that would wear different clothes or have an umbrella based on the weather, with a few different backgrounds and a cat that may or may not be there ("because cats are like that"). It was embeddable, and awesome. There was an HDD crash around 2010 iirc, and the site never really returned. Not sure if the artwork was lost too, as I keep thinking it would be nice to "rebuild it". Maybe around a cloud platform with a little redundancy in place.