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).
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.
I am not saying there is no need for more complex web sites. Personally I just think it is sad that in 2015 there are lots of sites that won't load anything at all if you disable JS or have a bad connection.
With a 50k connection at home I simply can't accept waiting 3+ seconds until your site loaded its 500kb of JS and 4 different web fonts to finally show something.
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 :)?
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.
Progressive enhancement does make sense in some cases, such as using a feature that not all browsers support yet but that the site can function without.
And progressive enhancement makes perfect sense for things like CSS; if your site content makes no sense with CSS turned off, it probably makes no sense with a screen reader. So, for instance, remember to put content in a sensible order in the HTML rather than arbitrarily rearranging it with CSS.
However, I no longer think progressive enhancement makes sense for things like JavaScript, as long as you use features just about every browser supports. Otherwise, you'd have to effectively write your site twice: once with JavaScript, and again as entirely forms/links and server-generated content.
The critical reason why I no longer think this makes sense: because it's completely sensible to follow an API-first approach to site design, where the first thing you write is an API usable both by third parties and by your own first-party site. Then you can write your site on top of your own API. I don't think we need to target human-readable first; on the contrary, I think we get a better, more extensible, more programmable, more open web if we build APIs first and foremost.
Now, all that said, there are other ways this article is completely right about not breaking the web. In particular, having an app is no excuse not to have a website, or one not usable on mobile. And if you're going to display a "you might want the app" banner, have a "go away and stop asking me" that does not break navigation to the specific page the user was trying to visit in the first place.
Progressive enhancement for JavaScript is not only a accessibility and usability issue, it has become a security issue. Tor enabled JavaScript by default, because the web would break without JavaScript support, and that hampered adoption rates of Tor.
We already had a programmable web. If anything we are moving away from machine-readable code.
If progressive enhancement does not fit your development style, and takes too much time to build, well... fine. I see this not as a fault of progressive enhancement, but in your approach. To me it is akin to saying that writing unit tests takes you too much time, and hence, testing makes no sense.
I don't actually think an entirely client-side-rendered application makes sense; on the contrary, I do think it makes sense to do most HTML generation on the server, and where appropriate, hand out snippets via the API, rather than handing out JSON or similar and making JavaScript produce HTML. But that's different than rendering entire HTML pages entirely on the server. And for primarily dynamic content, I see nothing wrong (for many sites, at least) with assembling server-provided HTML snippets from JavaScript into a server-provided HTML base page, without any fallback to an entirely server-provided page.
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 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.
The "first load" problem is a recent addition to the canon of reasons why progressive enhancement is a solid approach. I think that trashes your argument that this is "decade old dogma".
And to further counter your point, the notion that "decade old dogma" is "bad" is refuted by success of POSIX/UNIX. And wheels. Some "old" ideas are still state of the art.
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.
Why are the FEES we pay for tickets so inflated? Is there actually justified reasons as to why it takes so much to have this process happen (that isn't made visible) or is it pure profits for the man up top?
Full Disclosure: I'm an engineer at Eventbrite. But commenting independently. My views and opinions do not reflect Eventbrite's official position(s), and "oh god please don't come after me with pitchforks".
I think they're totally reasonable. I'm not going to get into specifics that would expose our finances, but I'll say that we have a lot of people behind the scenes taking care of building and maintaining the product on both the organizer and attendee facing side. On top of that we have some excellent customer service people who take care of hiccups and guide users in their time(s) of need. All those fantastic people need to be cared for (ie. paid).
If you're asking about the general perception of ticketing, I'll refer you to an article in the LA Weekly. http://bit.ly/1kAT1K0 (tldr; There are existing patterns in particular industries to deflate the perceived ticket prices, only to inflate them at checkout.)
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.
