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.