ericelliott

Cargo-cult programming is the act of copying something without understanding how it works or even whether or not it's required.

Typically it involves the ritual inclusion of code which does not need to exist because the author is copying something else they saw (or literally copying and pasting from Stack Overflow). The essence of the original article is the systematic _exclusion_ of code which does not need to exist -- that is the opposite of cargo-culting.

All of the guidelines exist for reasons which are well explained in the article. It's basically a guide that teaches you how to avoid cargo-culting.

If you're complaining that the guide encourages functional programming approaches, it's useful to admit that functional programming is an important capability of JavaScript (evidenced by the fact that functional utilities are built-in to the language).

See "Familiarity Bias is Holding You Back: It's Time to Embrace Arrow Functions" https://medium.com/javascript-scene/familiarity-bias-is-hold...

I'm not sure what you're trying to express. The "squiggly brackets" example is not valid JavaScript.

If you need to disambiguate associativity, you need to wrap with parentheses:

    const secret = msg => ( () => msg );

But in this case, it's not required, because the alternative doesn't make sense:

    const secret = (msg => ()) => msg;
                            ^ Unexpected token

See "You Might Not Need TypeScript (or Static Types)" https://medium.com/javascript-scene/you-might-not-need-types...

If you click through the links and actually read the content, I have plenty more to say about TypeScript, and why I consider it optional learning for JS developers.

Yes.

React is mature and robust now, and still growing in popularity like a rocket. It's not going to be gone tomorrow. Angular 2 is just starting to become stable, but it still uses some ideas pioneered in Angular 1 going on 4 years ago.

It also won't be gone tomorrow. Angular is still the dominant framework by a healthy margin. Yeah, there are newcomers like Vue.js, but they're currently about 1/10th as popular as React.

This "over in 5 minutes" meme in the JS discussions isn't exactly telling the whole story.

That's easy with both React and Angular.

Sublime is absent because a lot of previous sublime users are now Atom users, and it is now the more popular editor by a large margin. Those comfortable with Sublime will find Atom very inviting.

The costs discussed are counted in development time, not the monetary value of rockets. That point is clearly evident with a cursory glance at the math. Just look at the numbers. The values all fall on the same curve. The cost increase from design phase to implementation phase is the same relative increase from implementation phase to testing phase, which is the same relative increase from the testing phase to the production phase.

If it were counting the cost of rockets in the production phase, it would clearly jump that value off that cost curve in a dramatic and clearly notable way.

The mathematical evidence of these facts is clearly visible in this chart: https://cdn-images-1.medium.com/max/2000/1*jOS7CZX-gWfOoKGPU...

Which is a reproduction of the graph that appears in the original paper using identical data.

Of course, the data I cited was not the only data available on the economic impact of software quality. There is a whole chapter on the topic of the economic benefits of reducing bugs in the book "The Economics of Software Quality" by Capers Jones, Olivier Bonsignour Addison-Wesley, Jun 3, 2011.

The book is packed with valuable references if you're looking for more data on why it's worthwhile to reduce production bug density using techniques like TDD and code review. I strongly suggest you have a look at it if you have any doubts about the value of reducing production bug density.

While the example is fictional, the numbers used for it come from a meta-study of TDD research, and for the relative cost of fixing a bug in production vs implementation time, "Integrating Software Assurance into the Software Development Life Cycle (SDLC)" from the IBM System Sciences Institute. Original sources and raw data are available if you click through the links.

None of the examples or figures presented rely on the Chrysler C3 project, or anything published by Kent Beck. I'm unsure why you'd mention them except to build a straw man argument. Straw men aside, this is all independent research with lots of 3rd party citations.

Yes, tests do take additional time and do incur maintenance costs as well, and that additional time is accounted for in the numbers presented. TDD still easily wins.

Yes, you can produce successful projects without TDD. You can also run a marathon with only 1 leg -- but maybe it would be easier with 2.

As for questioning my credentials, I don't blame you. It's certainly a lot easier to try to cast doubt on somebody's credentials than it is to come up with a valid argument or think critically about your own beliefs and bias. If you have any sincere doubts, a sampling of projects I've worked on are listed at the bottom of the article.

You sound like you have a lot of free time...

It's true that WebGL lags native capabilities significantly, but that's a good thing in terms of the number of users who will be able to enjoy your app.

For a mobile WebGL-native experience, check out PlayCanvas, which offers a Unity/Unreal Engine style game production environment on the web platform, and targets mobile browsers by default.

Check out Swooop on PlayCanvas for example: https://playcanv.as/p/JtL2iqIH/

Can you do more with native? No question. Will you reach the same number of potential users? Certainly not.

Will your users appreciate the native difference? Maybe.

This is accounted for in the original article.

I didn't say dead, I said doomed. Meaning the demise is in the future, not the present.

This is not true. See Service Worker and the older application cache fallback.

That's an absolutely absurd notion. Ads usually direct users to a URL, and every app I've ever been a part of got almost all of its converting download traffic from the website, not from an app store search.

Unless you decide not to build a web app at all (and miss out on your single best source of traffic to the app, and the lowest-friction way for users to try the app before downloading), it's not a bias, it's a fact. Opting into native means opting into more work, or opting out of supporting other platforms.

See this comment: https://news.ycombinator.com/item?id=12943936

You can with Cordova. I've worked on several hybrid apps in recent years that took advantage of native features through a thin native wrapper.

But there are a lot of apps that don't need those features at all, and those apps are a great fit for PWAs.

They don't complain. They just don't ever install or use the app. The average user installs less than 3 new apps per month. https://www.tune.com/blog/no-the-average-american-does-not-d...

App install friction is much higher than website visit friction, and with PWA's, coming back is enough to prompt the user to install the app to their home screen with a single click.

Learning something new is not the big obstacle. The big obstacle is investment vs return on investment. If you have to write the same app 3 times, that is a significantly larger investment, and potentially much smaller return if what you end up with turns away most of your users.

Each click in the install process reduces the number of successful installs by 20%. So, start with 1,000 interested users. If the user has to click six times to install the app, you end up with only only 262 installs. And then you have to activate them to keep them using the app. Data shows you'll lose an average of 80% of your users after install if you fail to activate. That means you end up with 52 out of 1,000 potential users.

VS PWA. Once click means you start out with 800 instead of 252, so then you just need to activate them, which gives you 160 activated users.

3x the users for 1/3rd the investment. I don't know about you, but these are pretty compelling numbers for me.

This is the correct solution to this problem in web apps.

I admit, I don't do a lot of native mobile development, but of course I have participated in the production of many mobile apps, mostly servicing middle and back-end tiers using JavaScript and Node (because I specialize in JavaScript). For instance, I wrote a bunch of the code the powers mobile notifications for mobile apps connected to the Adobe Creative Cloud.

One of the biggest problems I saw with maintaining separate apps was that we struggled to keep feature parity across the products, and that would frustrate our users when they switched back and forth between the web app and the mobile apps. Features they depended on in the web app didn't exist in the native app or vice verse.

Yet another compelling reason to choose the universal web platform technology.

If everybody likes you, you're not being honest enough.

I'm all for better solutions for functional components. I hope we go down that road instead of locking in the decision to rely on `class` with things like class decorators and so on.

Several React libraries are already doing that. In spite of all our warnings, people are trying to extend classes for React views, and use `class` in the rest of their code, as well, moving it into the state layer, and modeling their business domains with them instead of using pure functions and Redux.

`class` affords `extends` like balls afford throwing and chairs afford sitting. When you ignore the power of suggestion that comes with the tool affordances, you point users in the direction of trouble.

Sadly, scaling developer education is a lot harder than it seems from inside our ivory towers, surrounded by smart colleagues well-versed in programming wisdom and design patterns.

Classes don't do anything about the dynamic nature of JavaScript. They spit out basically the same constructor that everybody was using for pseudo-classes in ES5. You can still do crazy things like manipulate the prototype outside the class, tack extra stuff onto instances after they've been instantiated and so on...

In other words, classes in JavaScript are a poor substitute for static types, and should not be used that way. That's why a lot of React people are using flow, and a lot of Angular people are using TypeScript.

Yep. I agree with those observations. Static types can be very handy to reduce developer cognitive load. Automated refactoring tools are also pretty nice. All I'm saying is they're no substitute for a test suite. As a software quality guarantee, they don't even come close.

Fixed.

Much credit is due to Elm and Figwheel, which both served as inspiration for the JavaScript time travel debuggers such as Cerebral and Redux.

IMO, the main benefit of Closure Compiler are the type checking errors. However, it's a pretty heavy handed solution for that compared to existing tools like JSDoc + TernJS, or DefinitelyTyped TS annotations.

It relies heavily on JSDoc, and I believe JSDoc has had its time, and is on its way out (being replaced by tools like Flow, TypeScript, rtype/rfx).