I usually tell new hires this often; understand how this company makes money. Is engineering seen as a necessary cost or income multiplier on the balance sheet.
In most companies, it falls in the land of IT, a cost center.
Glad someone is talking about the option other than selling to VCs or ramen diet start ups. The tech community might have collectively forgotten the other option.
Generally Gumroad itself is an amazing idea. It's challenging to push out products, and any platform that helps empower people to just try is a win.
I'm not sure about how the open-source element of this is supposed to work, but if it ends up with more people building things, creating and contributing, while making a dollar, that's a good thing.
Our team also runs into this issue. Dealing in real time means real time changes. Even if we have to wait on an return from the database to the api to the client.
So we simulate the changes as the user makes the action, 'optimistic UI updating' and then wait for confirmation on the server to persist the data. During that waiting period, we tell the user that their changes are being saved, but they are free to do what ever they wish.
It lets the user know things are happening, but might not persist because we are still in the mode of saving, yet allows the user to carry on with their tasks while we deal with the information they send us.
If they close the page, during this time, they are well aware that the changes are happening. The request has been made, it just didn't return yet.
Not being able to import/include library code is bat-shit insane. You can't reliably check the type of things like arrays.
The 'this' value is 'wrong' in callbacks (by wrong, I mean, not what programmers actually need in that instance).
Javascript dates values are 1-based except for months which are zero based - be consistent!
Math.parseInt will produce correct results for 05, 06, 07, wrong results for 08, 09 - don't ASSUME a radix! (unless that radix is base 10).
It goes on regardless in the face of a large number of errors meaning that the location of an error can be much harder to find than is necessary - I believe that fail fast is infinitely superior to 'just muddle through and do something random with that invalid state'
You can't rely on getting decent stack traces out of it on error which makes debugging harder than it should be.
It's easy to accidently add globals.
I'd add lack of types: obviously that's a preference but when 30% of your tests just end up checking what a compiler could have done for you for free, then I say that;s a fault with the language.
That said, I really like array and object literals. It's not all bad. Just... about 86%
For me, coffeescript was the answer to the question "How can I write javascript with python-esque whitespace block formating?" I suspect the author was asking something like "what can replace javascript?"
Coffeescript seems to be more like Perl, where parenthesis are often optional, and meaning is implied by the context a lot of the time.
I like Perl, but I tended to be fairly pedantic with parenthesis and things when writing it. I prefer explicit over implicit. (Though sometimes implicit can save you a ton of time).
Ironically - he doesn't it's kind of the whole flaw in the series.
How is JavaScript a minefield? Well, JavaScript has all sorts of pitfalls lurking for the developer. Each pitfall is like a mine in the minefield, silently waiting for you to accidentally step on it. Just like the minefield, JavaScript’s mines are hidden in plain sight. Entire books have been written about all the mines present in JavaScript. Maybe I’ll get into what some of those are in future blog posts.
So then he goes into why Typescript/Coffeescript/Dart aren't the answer to the "Javascript minefield" though he doesn't actually describe the mine's he's trying to avoid. He's not even bothering to setup a strawman to knock down. Its kind of hard for any tool to solve an undefined problem.
Given that a safe path through the JavaScript minefield isn’t enough, it seems like we need a detailed map of the minefield. Many books and blogs have been written to provide that map. JavaScript: The Definitive Guide by David Flanagan is one of the most detailed of those books. The JavaScript Garden is a good place to start learning about the mines online. [2]
