parris

Hmmm, this is the best justification I've heard to replace cars with bionic ants.

I don't think it's worth reading the JS books in your case actually. I think I was also trying to talk about the different types of tech books I've seen; meanwhile, also talk about the books that directly impacted me. I'd recommend books focused on C# that cause you to really deep dive into the language or ones that flip the language semantics on their head a bit. It's always great to see other paradigms and what you can pull from them.

I'm the author AMA! The reason we built this was that we wanted to produce react/graphql projects quickly. We were tired of endless setup to get all the features we wanted. In addition we wanted an easy way to upgrade the different projects we had, and be able to own the data rather than using a SaaS platform for the data side of things. We use postgraphql so graphql apis are auto generated from knex migrations. We use apollo under the hood and redux as well. Also, we built out some really handy Form helpers and other components. A big goal was to make as many aspects as possible declarative, and to make setup of projects relatively config free (or at least config light).

Oh I should also say, come contribute :)!

Sure! Parts of that are indeed ridiculous.

Although I'm pretty sure the download size from a CDN is far less important from a performance standpoint (within reason). More important things include: - Time to first byte from a slow'ish server (.5s to create the HTML and .5s to deliver). - How many separate requests you are making (somewhat going away with http2)

Can we start ranting about the excessive amounts of tracking pixels everywhere now :)?

Consider that when most people get sites that don't meet their needs their gut reaction is to open 20 tabs and mentally slice data from all over the website. That doesn't seem very progressive either.

Of course/agreed! It took me a while to get there, but basically the conclusion I was trying to make is "it's not the only tool please stop prescribing for every scenario blindly."

This is non-sense. Every few minutes you hear someone complain about the lack of progressive enhancement. The case for progressive enhancement is only valid when you have "content" that is easily parseable by human eyes.

In a world where you have too much data and users want to see slices of data, progressive enhancement fails to deliver a fast, pleasant, engaging user experience. In the case, where you have complex tools that help a user meet some end goal more quickly progressive enhancement falls short of providing the easy to use tools. The only case where this works in any way shape or form is when a site is submittable via simple forms and all data can be retrieved by visiting urls. Any, slightly more complicated use case fails to be delivered at any reasonable pace with any sort of reasonable performance. You know the kind of performance that wouldn't make your server side fall over.

This whole progressive enhancement thing is mired in decade old dogma. While progressive enhancement can work sometimes, it is NOT the only tool. We shouldn't wholesale prescribe solutions without knowing someone's problem.

Whoa that's really cool!

Ha! I might split out the code into its own repo so it can be used as an add-on library for ThreeJS. I think the code here might push it over the 100kb limit. We'd also need to get a license to SDF'ify a default font (possibly Helvetiker). We had to get permission to do it with our font "Benton Sans".

I agree for the most part. For a lot of cases we did use tooltips, overlays, and sidebars. That isn't a cure all though. Without embedding text we couldn't really give enough context to the end user.

AMA: I worked on the frontend for eventbrite's seat designer tool.

Solution 1: Upgrading npm actually does nothing and also complains about a cert error.

Solution 2: is a terrible idea for people who have their own private registries or proxy caches. Also a security issue in general...

This leaves you with needing to upgrade node, which may or may not be possible due to operating system/platform constraints. Luckily we were using this https://launchpad.net/~chris-lea/+archive/node.js/ which makes life on ubuntu ok.

We set up our own proxy cache, at this point im thinking about increasing the cache time to something like 2 weeks.

Gulp seems more like a feature and less like a build system. In fact: http://blog.evanyou.me/2013/12/29/gulp-piping/ and https://github.com/wearefractal/vinyl-fs

Grunt works just fine. Make is probably ok once you learn it. It is a shame that we as a community don't take time to create amazing tutorials for our older tools like we do with our newer ones.

I think the main issue ends up being that github has created a double edged sword in open source dev land. You have people creating projects just so they can earn stars and thus resume fodder. This ends up creating packages with no maintainers and multiple projects that do the same thing. I mean really, how many different string parsing npm libraries do you need?

I feel like getting a job at a larger company as an engineer is easier than getting a job at a startup anyways. Sure when you start your own thing there are no rules, but any startup with a couple senior engineers that have had to train up some employees from scratch know how much work it is. If you are joining a large company then you have a better opportunity to learn from more people. Your support base is larger.

Side note: who can you actually hire within your network if you join/start a startup? I thought I knew people, but every time I've ever asked if anyone wants a referral for (enter reputable startup brand here using awesome tech) I get no responses among my network. Every good engineer I know right now actually has a job that they like.