Since my recent “addiction” to podcasts, I’ve started listening to the (very recommended) the Software Engineering Daily. For those that can’t listen to the podcasts posted there, I’ll be bringing here some notes for those that I feel especially interesting and more directly related to the topics we like to talk about here.
Starting with Eric Elliott (author of Programming JavaScript Applications: Robust Web Architecture with Node, HTML5, and Modern JS Libraries
Listen to the full podcast and/or read on for my selection of highlights (I bet you’ll find some of them quite controversial 🙂 ) :
If you don't know how to code you'll be illiterate in the future Click To Tweet(I liked this one so much that I even added it to my “software engineering quotes” list, direct instagram link).
Programming is a form of expression Click To Tweet Everything is a lot easier in JavaScript compared to classical OO like C++ or Java because its flexibility (e.g. writing functions) Click To Tweet Universal Programming: Write your application once. Same codebase works both on the server and the client side. Click To Tweet I've ported software from ruby and php to JavaScript and I've seen tremendous performance gains. Click To Tweet Everybody not using universal JavaScript is wasting a lot of time and money Click To Tweet Rails is not intended to be used for distributed architectures (Twitter learnt this the hard way) Click To Tweet There are quite a few frameworks like Rails for JavaScript. E.g. Keystone or meteor Click To Tweet(Keystone looks very interesting indeed. It focuses on database-driven web applications and offers very powerful scaffolding functionalities that helps you to quickly create a default UI immediately after your define your domain model)
JavaScript ecosystem is three times the size of the Rails ecosystem Click To Tweet There are not yet best practices for JavaScript. Everything changes so fast (e.g. React with its one-way data flow) Click To Tweet Check time-travel debugging in redux (enabled by the one-day data flow) Click To Tweet Timeless principle in JavaScript: composition over inheritance Click To Tweet I'm a big proponent of class-free programming. And you can do this on React too Click To Tweet Dev Teams: We don't have front-end or backend developers we have universal engineers. Click To Tweet JSHomes.org: partners with housing & job training programs to provide tech training to those in need Click To Tweet
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
Well, you did say controversial. But no. Just no.
As for “Everything is a lot easier in JavaScript compared to classical OO like C++ or Java”.
So I guess that’s why there’s Typescript/Coffeescript/etc. which add the OO/static typing features missing from the original language? And why they’re being adopted into subsequent versions of the language spec?
The javascript ecosystem is a mess, as Jeff Atwood eloquently illustrates: https://twitter.com/codinghorror/status/619298227611766784
And the whole async/callback thing is just horrible. Joe Armstrong is right: the correct way to handle concurrent activities is to provide good concurrency abstractions in the language and runtime. It’s not to force cooperative multi-tasking on the developer. Building apps is hard enough, let’s not go back to programming like Windows 3. If you don’t want to use a “mainstream” language like java or C# for back end stuff, do yourself a favour and look at Erlang/Elixir/Go. Or – since this is a modelling community – generate your choice of target from a modelling language that provides better abstractions. To paraphrase Jeff Atwood again, Javascript is machine code for the web.
Of course, the momentum is huge, and javascript isn’t going away. And if you’re really into learning and playing with new frameworks, there’s no better place at the moment. OTOH if you’re interested in building applications efficiently, apps that won’t become legacy nightmares in less than 6 months, the javascript world is a frustrating place to be. Don’t make it worse by building your back end on the same shifting sands.
I warned you it will be controversial 🙂
From what I got while listening the podcast, he is not a big fan of OO or static typing in the first place so he probably wasn’t the one asking to add this to JavaScript.
I believe the choice of a programming language depends a lot on your personality. JavaScript gives a lot of flexibility which is exactly what he is looking for. Myself, for instance, I would never use a dynamic typing language just because I’ve tried and it doesn’t work for me.
And to be honest, I’m still so surprised about the huge momentum JavaScript has right now. I would have never predicted that!
I’m a fan of OO, but in JS, composition with prototypes is easier and better than class inheritance.
I’m a fan of static types, but they’re better suited as editor tooling for devs than error catching. Type correctness does not guarantee program correctness. Every language benefits from linting, TDD, code reviews, and CI/CD. By the time you do all that, few type errors make it into production.
That said, a good type system and type annotations have lots of other benefits which are much more exciting. That’s why I founded the rtype project for JavaScript: https://github.com/ericelliott/rtype
Good points all Eric. I still remember reading the Self papers for the first time; it’s profoundly elegant, beautiful even, thanks to the prototype model. So I have a lot of time for that. Much though I still prefer static typing, my “go to” scripting language is Python; for highly concurrent systems I’d choose Erlang every time. Both dynamically typed – though interestingly, both with optional static typing capabilities (e.g. Dialyzer for Erlang). So the static/dynamic typing discussion has strong arguments on both sides.
What’s less defensible IMHO are the other two points: (1) the concurrency model, and (2) the unstable environment. I can’t help but think that Async will be the “GOTO” of concurrent systems. And since the original post, we’ve had the infamous “left-pad” debacle. The geek in me is fascinated by the incredibly rapid evolution in the Javascript world. My Control Systems Engineer side sees a highly unstable, underdamped system. Building an application on top of that is committing to an ongoing, significant maintenance burden – where the underlying software infrastructure will suck up cost even if the application requirements remain stable. To my mind that’s the opposite of what’s desirable. I can build simpler, more performant, more stable apps in Erlang (or even C#/Java) for no extra up front cost. I can’t justify Node on the back end commercially. And I certainly don’t fancy explaining to a customer that their app fell over because someone removed a 20 line package.
Of course it’s just my opinion. Thanks for sharing yours. And good luck with your rtype project.
Amen. Those comments are not controversial, they are just silly.