Generation JavaScript
manuel.bernhardt.io
manuel.bernhardt.io
It's true that our community could use a renewed focus around best practices, and it's true that the stack itself is way more complicated than it needs to be. In that sense, I don't disagree with the point of this article at all, but it's important to remember that when things grow organically they will tend to get messy, and the alternative (somehow structured growth, governing bodies, etc) is far worse.
I fail to see the "many excellent options". Awful ones are, on the other hand, abundant.
And even those that are decent have the other issues the article mentions: they are short-lived, with developers soon moving to the next shiny thing etc.
I've been loosely following a lot of projects for several years now... it's hard to even keep a broad awareness at this point. That doesn't even count the platform/systems tooling that I'd honestly rather not think about...
Chef, Puppet, now Ansible... Hadoop, MongoDB, RethinkDB, Cassandra, ElasticSearch, Redis, Couch, etc... Hapi, Express, Koa ... NGINX, HTTP2/SPDY, Varnish, etc... Cloud-VMs, Azure, Amazon, Rackspace, Joyent, Linode, Digital Ocean... OpenStack, Varnish, Docker ...
It goes on, and on... there's too much to keep up with awareness of... let alone what needs to be dug into at this point. It's honestly a bit overwhelming. I just want to get back to whelmed...
I'd really like to be doing more time coding, which right now, I'm spending more time on platform stuff... evaluating packages in npm/github isn't so bad.. much more than that, it gets interesting.
Javascript is definitely in danger. I feel like its just hurtling down a trajectory of becoming the assembly of the web. The library churn is not helping.
IMHO that's the best possible thing which could happen to it. JavaScript is a hideous, ugly, horrible, broken language. But so is machine code, and it doesn't matter because I can write in real languages and let a Sufficiently Intelligent Compiler™ figure out how to encode my program. If I could write in a real language and have it compiled to JavaScript, I'd be a lot happier about writing browser-based apps.
(I'm still not happy about every single web page demanding executable code in order to, e.g., display a blog entry, but that's a different issue)
I think a good attempt at providing a "3000 ft survey of the JS landscape" is http://alpha.ideavis.co/529cc5f
I'd love to see an automated tool that could aggregate stats from a range of JavaScript repositories (e.g. GitHub, NPM, Bower) into something like Dustin's graphic.
Some of you may be old enough to remember the days when managers attempted to measure our output with KLOC/day metrics. That goes back at least to the early 90's and maybe the late 80's. I believe the reasons for this are more fundamental than these articles hint at.
The problem arises, imo, when you have management in a position of relying totally on people whose work they don't understand at all. They are educated to manage risk, and yet they are paying us large amounts of money to essentially function as a black box, out of which comes something that works and makes them heroes, or doesn't and loses them their jobs, and they have few ways of measuring which way the battle is going.
The response is to try to manage ever more closely, treating the process as one of production: X number of people sitting at their computers working hard will produce Y amount of software. Those are the kinds of processes they are trained to deal with in the management schools. They aren't trained to manage inherently risky processes of creation, rather than production. The word "craftsmanship" as used in the linked article is exactly right, but "craftsmen" don't fit into the modern world of value production and they never have.
I think it's important to note that big reformations, like Agile replacing Waterfall, are reactionary; by necessity they tend to be overly so; to promote change they demonize the old way. Unfortunately there's usually a core of good ideas that get thrown out as well.
I don't think the Waterfall methodology works for most products, but it made up-front planning and careful consideration part of the design process that's missing in a lot of projects today. I think a balanced approach is needed; just enough up front planning to provide a strong, clear vision to the team, consideration for the tools and processes that will be used to get there, and someone with the vision and technical knowledge to lead it. These are some of the points I like to hammer out before launching into a project:
* Design - what is the product supposed to look like?
* Testability - how do you intend to test your code?
* Documentation - how will the code, product be documented?
* Tooling - what's your preferred dev tool chain?
* Code architecture - What's your design philosophy?
* Prototyping - straight to product or prototype first?
* Delegation - how to structure for future delegation?
* Security - how to audit the security of your app?
1. http://ventrellathing.wordpress.com/2013/06/18/the-case-for-slow-programming/
2. http://www.datamation.com/career/article.php/3757311/The-Myth-of-the-Interchangeable-Programmer-Can146t-We-Just-Offshore-Him.htm
3. http://pragdave.me/blog/2014/03/04/time-to-kill-agile/I'm curious about the details. How, exactly, do you hammer those points out? One big meeting? Multiple meetings? A week or so "workshop"? How detailed are the answers to, eg. the Design, Documentation, and Architecture questions? Wireframes? Mock-ups? Architecture diagrams? Who do you invite to the planning session(s)? Do you re-evaluate things periodically using the same points? Do you run major new features through the same process, or just slot them into ongoing iterative development?
I'd be very interested in any elaboration you're willing to go into.
* Design - what is the product supposed to look like?
* Testability - how do you intend to test your code?
* Documentation - how will the code, product be documented?
* Tooling - what's your preferred dev tool chain?
* Code architecture - What's your design philosophy?
* Prototyping - straight to product or prototype first?
* Delegation - how to structure for future delegation?
* Security - how to audit the security of your app?
Opposed to using a JVM language, where everything is statically compiled into a single container, including another library (or upversioning one) will impact compilation times and oftentimes trigger a complete re-build, often taking minutes before you can see the output of your code.
Minutes versus seconds when dealing with code correctness really helps, and is what is needed most when trying to 'hack it together'.
† Note: This is the same with test suites: karma tests are often instantaneous and spock/junit tests sometimes take 30-40 seconds before they start to run, depending on environment.
While that may be true, typical JavaScript projects require a compilation step. Plain JavaScript is starting to get somewhat rare, and projects typically use a compile-to-js language like CoffeeScript or TypeScript, or perhaps ES6-to-ES5 compile step. And then you need to minify that code since it's not recommended to run a non-minified "debug" version during development. And if you're project is any complex you're probably also compiling a single .css file perhaps from .less, compiling .html from .jade and packaging it all up in a different public folder.
The point is that typical non-trivial web applications need a build step.
Customers, paying customers, are accepting Javascript apps. Java was never good enough for that to happen except internal to large organizations where aesthetics and user experience didn't matter.
There may be a zillion crappy, similar overlapping Javascript libraries - and to my background it seems like a massive waste of time - but the fact remains that people, everyday people like my mom, sister, uncle and aunt are all spending real money for services accessed through Javascript. It is good enough.
Should I tell them: "You know that website you like so much, e.g. reddit- it would be so much better if it was a native app on your PC written in C++, so, like, don't use it. Demand and wait for someone to re-write it in a proper language with libraries that have a proper pedigree. Then you can run it on a 300 MHz computer instead of 3 GHz."
That'll never work! The javascript/PHP/whatever else stack that implements reddit is absolutely adequate for them to browse cat pictures and interact with their magic tricks communities.
Now, diehards like me cringe because of the waste of CPU, but guess what - CPU power is no longer a scarcity. There are only philosophical and environmental reasons to wring our arms about using less CPU power. And possibly these concerns are non-sensical. Are we wasting the world's resources making fast CPUs so people can use inefficient sw libraries? Who knows. But either way, the point remains:
Javascript's customers and users, and the services they demand and pay real money for all support Javascript and nothing other than a fanatic religion will convince them to change their ways.
It makes me mental, but I've even been learning Javascript over the last few years. It's about the same speed (and variable scope) as the BASIC I used on the Apple 2 in 1984, but so what, I'm paying the rent with it.
But development is not a democracy, and the fact that n thousand projects use a certain stack doesn't mean the stack is fit for purpose.
Take the security horror that is Wordpress. It's popular because it's easy to use, but from a professional point of view it's an infosec plague and server killer.
The quibbles about js have nothing to do with its popularity. They're more about the overall lack of professionalism in software development.
The underlying issue is scope. We don't have a cathedral, or a bazaar. What we have is exactly one (1) planetary network, made of a loose affiliation of barely cooperating nodes and applications.
The original Internet infrastructure worked because the RFC process meant that the core features were designed and refined by peers. Hobby coding in the bazaar removes all elements of peer review.
But the alternative isn't a UNIX-style cathedral, it's a revised set of standards leading - eventually, I guess - to a planet-scale operating system and shared library framework that takes away all the cruft by making it unnecessary.
None of the current stacks are the right way to make that happen.
So the issue isn't js - it's more that web stacks have become de facto operating systems for industrial computing projects without any of the rigour, peer review, or oversight of a well-designed industrial gold standard OS.
And it seems that no one - or at least no one that Tim O'Reilly's authors talk to - is even thinking about how to create an OS of that quality.
You don't have to be Michael Schumacher to become responsible of an F1 team. But you have to understand basic staff and hire proficient personnel to do the rest.
And even the largest selling point of the entire stack - develop once, run everywhere - is far less true then many like to admit. In the past a substantial part of development time has been spent on getting the thing to run consistently across browsers but I fear we are far from the end of the road. Now we have more or less consistent behavior across browser for all the basic things but you still regularly run into unusable web application because you happen to have an unexpected screen aspect ratio, an unsupported video codec or missing WebGL support.
Unfortunately I have no good suggestion how to escape from that situation (quickly) but it seems pretty obvious to me that we have a lot of problems to solve.
Luddite: one who protests against modern labor-saving technology.
> largest selling point of the entire stack - develop once, run everywhere
Rather than being the largest selling point, this is talked about by virtually nobody who actually works with Node.
Easy handling of concurrent I/O is the largest selling point.
See http://nodejs.org/ : "Node.js® is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices."
> JavaScript is an awful language
This is a bare assertion. The same thing can be (has been) said about every programming language, ever.
> the entire stack is more less broken.
This is another bare assertion.
> HTML and CSS got repurposed from document markup languages to GUI markup languages.
This is a red herring. There is nothing intrinsically wrong with the evolution of markup to encompass more layout capabilities.
> We allowed this awful language to escape the browser and infiltrate our servers in form of Node.js.
Another red herring. Node.js exists. Nobody is forcing you to use it. It's being used successfully by quite a few folks. Furthermore, it was Netscape (the originators of the language) who originally introduced server-side JavaScript. SSJS has been around in various forms almost ever since there was JS.
> Microsoft also came up with the clever idea to develop desktop applications and apps with JavaScript, HTML and CSS.
They were certainly not the first. The trend started, I believe, with Mozilla's XUL architecture, evolved through things like Lazslo, and is steadily moving towards web components. This trend has been going on for a decade; even in enterprise Java land things like Struts and JSF got on the application markup bandwagon. Quite simply, markup has proven to be a good way to lay out interfaces.
> develop once, run everywhere - is far less true then many like to admit.
There are inconsistencies, true, but there is really no other stack that has achieved as much cross compatibility as the web stack.
> In the past a substantial part of development time has been spent on getting the thing to run consistently across browsers but I fear we are far from the end of the road.
This is somewhat of a "slippery slope" fallacy: 'There were problems in the past, so I fear there will be problems in the future, therefore we shouldn't solve the problems and the whole thing is crap...'. It doesn't hold together.
> Now we have more or less consistent behavior across browser for all the basic things
Which is incredibly powerful and frankly unprecedented.
> but you still regularly run into unusable web application because you happen to have an unexpected screen aspect ratio, an unsupported video codec or missing WebGL support.
Very rarely. For experimental new apps yes. But when you look at what projects like Clara.io have accomplished, they have blown away the preconceptions that the web is not suitable for things like high-end 3D graphics development.
> Unfortunately I have no good suggestion how to escape from that situation (quickly) but it seems pretty obvious to me that we have a lot of problems to solve.
Let me make a suggestion then. Contribute to solving the remaining problems instead of berating the technology, or if you manage to find a better alternative, write about that instead.
This is a bare assertion. The same thing can be (has been) said about every programming language, ever.
This is just not true. You can always find someone not liking a language but if you asked people that have used many different languages they can of course rank them from worst to best. And although I am not ad hoc aware of any study demonstrating this I also never met any developer seriously suggesting that JavaScript would rank on top of that list.
> the entire stack is more less broken.
This is another bare assertion.
This is obviously my opinion and I assume everybody is able to mentally add IMO somewhere.
> HTML and CSS got repurposed from document markup languages to GUI markup languages.
This is a red herring. There is nothing intrinsically wrong with the evolution of markup to encompass more layout capabilities.
If table based layouts or hundreds of wrapper DIVs are not a sign that the underlying technology is not suitable for the task then I don't know what is.
> We allowed this awful language to escape the browser and infiltrate our servers in form of Node.js.
Another red herring. Node.js exists. Nobody is forcing you to use it. It's being used successfully by quite a few folks.
That somebody uses it successfully does not make it a wise decision to use one of the worser languages in a place where you are - unlike in a browsers - not forced to do it. And don't get me wrong, everybody is free to use whatever they like, I just want to point out that there are better options. You can use a screwdriver to drive a nail into a board, I won't stop you, I just want to suggest to at least consider getting a hammer.
> Microsoft also came up with the clever idea to develop desktop applications and apps with JavaScript, HTML and CSS.
The were certainly not the first. The trend started, I believe, with Mozilla's XUL architecture, evolved through things like Lazslo, and is steadily moving towards web components. This trend has been going on for a decade; even in enterprise Java land things like Struts and JSF got on the application markup bandwagon. Quite simply, markup has proven to be a good way to lay out interfaces.
I completely agree that using a markup language is a good way to build GUIs, the bad idea is using HTML and CSS for that because they were not intended for this and are not really up to the task.
> develop once, run everywhere - is far less true then many like to admit.
There are inconsistencies, true, but there is really no other stack that has achieved as much cross compatibility as the web stack.
I completely agree with that, but this should really not imply we should stick with JavaScript, HTML and CSS. We can do way better and we should do so.
> In the past a substantial part of development time has been spent on getting the thing to run consistently across browsers but I fear we are far from the end of the road.
This is somewhat of a "slipper slope" fallacy. There were problems in the past, so I fear there will be problems in the future, therefore we shouldn't solve the problems and the whole thing is crap.
No, we should of course fix the problems, but I believe we should at least think about fixing them at the fundamental level instead of keeping patching the holes. The obvious problem is of course the adoption of a better replacement and that is why I am not sure if and how this could happen.
> Now we have more or less consistent behavior across browser for all the basic things
Which is incredibly powerful and frankly unprecedented.
> but you still regularly run into unusable web application because you happen to have an unexpected screen aspect ratio, an unsupported video codec or missing WebGL support.
Very rarely. For experimental new apps yes. But when you look at what projects like Clara.io have accomplished, they have blown away the preconceptions that the web is not suitable for things like high-end 3D graphics development.
My point here is that people quite often try to suggest that portability is kind of a unique feature and essentially for free with the web stack which is not true. A simple program is really easy to write in a cross-platform manner in most languages. Then there is a range of applications where the web stack is exceptionally good for building cross-platform applications with very little overhead. At the upper end it again becomes hard and costs effort to get it working across platforms.
> Unfortunately I have no good suggestion how to escape from that situation (quickly) but it seems pretty obvious to me that we have a lot of problems to solve.
Let me make a suggestion then. Contribute to solving the remaining problems instead of berating the technology, or if you manage to find a better alternative, write about that instead.
As another commenter pointed out, we know how to build better solutions. What we don't really know is how to get adoption for it.
So because it's not number one it's an "awful language"? That doesn't make any sense and I know plenty of people who enjoy working with javascript. In fact the few people I do know who hate JS are people who haven't done more than copy/paste code from stackoverflow.
https://github.com/jashkenas/coffeescript/wiki/list-of-langu...
Also, compare this to the number of people who are just using JS normally worldwide, then we'll have perspective of just how many more people are just fine with JS Vs the people who feel the need to make these.
My guess would be that the number of people who like JS and use just normal JS in their projects is far far greater in number than the people who use compile-to-js solutions. So in comparision to the former, the latter group could be called as 'few'.
Time is the true currency of this universe, so we optimize for efficiency as best as we can without knowing the future.
The problem being discussed here is more along the line of building the Golden Gate with wood and plaster.
Coffeescript in particular makes me feel like Javascript has a Bizarro-world cousin of Ruby hiding under all the C-style syntax.
JS and Ruby are similar in a way, the syntax is not all too strange to me so it's easy to run any JS code in my mind, on the fly.
That said I find JS extremely cumbersome compared to Ruby... But if I could easily add JS functionality to my Sinatra/Rails it would be great! :-)
Everyone knows what the solution is; a sandboxable arch-independent batteries-included bytecode format for the web. The solution is obvious, the problem is in organising the detailed work necessary for such a format to emerge.
Assuming this work was completed, widespread adoption is mostly a matter of browser support and time. I suspect the Chrome team would be open to implementing it after it's been designed (there are parallels with the Native Client work), and other browser teams would be unlikely to resist if there are clear performance and workflow benefits (which there undoubtedly would be). Basically it's a "if you build it, they will come" situation.
To understand the scale of the task, consider the 'batteries-included' aspect. The core libraries for the bytecode format should be standardised (i.e. core library API set in stone for each major version of the bytecode). That's a huge amount of work. Then you'd also have the security testing needed (to ensure the bytecode was securely sandboxed). You'd also need to work on ensuring the bytecode was efficiently implemented for all processor architectures. I don't know about you, but I certainly don't feel qualified to do that.
I wonder if rust or c might run in a vm, I guess yes. C compilers can be very small too.
1 URL = 1 resource
Right now, in every web browser that exists, there is still a so-called "address bar" into which you can type exactly 1 address. And yet, for a system that uses WebSockets, what would make more sense is a field into which you can type or paste a vector of URLs, since the page will end up binding to potentially many URLs. This is a fundamental change, that takes us to a new system which has not been thought through with nearly the soundness of the original HTTP.
Even worse is the extent to which the whole online industry is still relying on HTML/XML, which are fundamentally about documents. Just to give one example of how awful this is, as soon as you use HTML or XML, you end up with a hierarchical DOM. This makes sense for documents, but not for software. With software you often want either no DOM at all, or you want multiple DOMs. The old model was:
1 URL = 1 resource = 1 DOM
Much of the current madness with Javascript is that developers want to get away from HTTP and HTML and XML and DOMs and the url=page binding, but the stack fights against them every step of the way.
Perhaps the most extreme example of the brokenness are all the many JSON APIs that now exist. If you do an API call against many of these APIs, you get back multiple JSON documents, and yet, if you look at the HTTP headers, the HTTP protocol is under the misguided impression that it just sent you 1 document. At a minimum, it would be useful to have a protocol that was at least aware of how many documents it was sending to you, and had first-class support for counting and sorting and sending and re-sending each of the documents that you are suppose to receive. A protocol designed for software would at least offer as much first-class support for multiple documents as TCP allows for multiple packets. And even that would only be a small step down the road that we need to go.
A new stack, designed for software instead of documents, is needed.
Java apps! ducks But seriously folks, I'm curious what went wrong there. The JVM these days is very fast, runs everywhere and comes installed by default on most operating systems. I was still a student during the java hayday, but the only downsides I vaguely recall were poor UI, poor security and poor speed. The last two have been fixed and the first one seems very fixable. Furthermore, you don't have to write apps in java anymore. It just seems like there's a lot of untapped potential there these days.
Inheriting the DOM, especially its graphical elements was a boon to JS apps.
Technically Java can/could do all the same stuff, but in the DOM, input, output, graphics and text all flow together. They're too rigidly separated in Java layouts.
While I'm at it, upgrading the Java runtime was always an annoying process, taking time, confusing my sister, etc.
But it's more true than any platform in the history of mankind.
I've noticed a resounding chorus of seasoned developers railing against the web as application platform for over a decade now. But their complaints are always comparing an open standards based platform against some proprietary platform or GUI toolkit. Of course Microsoft or Apple are going to put together a more cohesive app SDK than the W3C. But neither of those behemoths has ever approached the ubiquity of the web, not by a long shot, because every single platform they target has to be developed by them. The web is available everywhere, and if a new corporate behemoth builds the next great platform, they must include web support because that is now considered baseline functionality. I'm surprised more old-school developers don't recognize what an amazing accomplishment this is.
So yeah, JavaScript is terrible, but it's standing on the most ubiquitous platform ever created. And you can't build that platform by thinking to yourself, "what would the ultimate cross-platform application platform look like?" It doesn't work that way. The web won because of it's braindead simplicity, that was the thin edge of the wedge. You see being document-based as a weakness, but that's its strength, because documents have a higher utility-to-complexity ratio than apps. Even today when all us software elites are thinking about javascript-based apps, the web is still dominated by a massive substrate of documents, and many apps exist only to manipulate documents, so being document-based and allowing anyone to edit documents was the killer feature of the web. How many network application protocols/platforms/toolkits have been invented since the birth of the internet? Certainly a lot more than anyone will ever be aware of because they didn't have the means to gain traction.
Systems on the scale of the web don't—can't—happen by design. Instead of complaining how terrible it is we need to look at what incremental improvements are possible. Over time this leads to real evolution, and yeah it's slower than we'd like, but there's no other way forward without chucking out all the users with the bathwater and becoming irrelevant.
No longer are you dealing with a scarcity situation, where the bookstore was your filter, but an overload situation where you could access everything as easily as a click. Amazon dealt with this by allowing for ratings (one to five stars), reviews and ratings of reviews. It also tracked what books people bought in the end. I think this can be applied to NPM and other non-JavaScript package managers.
We have much the data in Github and NPM to do this, with the exception of proper ratings (stars are not that informative, as they are only positive) and proper written reviews.
I'll be honest, there is a real space to move in this direction towards collaborative filtering of packages based on both implicit and explicit signals.
"Imagine you are a newcomer to Javascript development these days. Which librairies should you pick to get started?"
Who cares. What's stopping anyone from just writing a JS file and adding a script tag to their html, that's how most of us learned it.
"There is, however, a price to pay to the approach of coding through instant gratification."
No there's not. It just depends on what type of coder you are. I like to think a problem through BEFORE coding and then hack, when I come to another problem I pause, think, solve the problem, (all away from the computer) then want to code super fast again. Anything that makes the "turn my idea/algorithm" into running code faster is good, when writing C/C++ anyone will tell you they hate compiling, why? because its slows down the "idea-to-code" part. To the authors credit he seems to prefer this approach as well, it just doesn't follow that you have to hack super fast all the time and never think just because you don't have to wait for code to compile.
"The hardest thing in Javascript development today is maybe less the development itself than knowing which libraries to pick."
That's a problem? Seriously, I think many languages would love to be able to "complain" about this.
"It is Torvald’s “Release early and often” without the community smashing the ego of anyone publishing sub-par code."
Here's the way I think about it. If you can't find what you want, build it yourself, maintain it, and use it. Everyone does this in any other language and it works fine, its also working for JS too. see here: https://github.com/sorrycc/awesome-javascript
The only thing I would agree with is that yes, it is ridiculously easy to publish something to npm so there is a lot of garbage. The days of submitting your email patch are winding to a close and I for one am happy about it.
But think about it from a different perspective. Let's imagine you are hired by a company to come in and build a large, web-based, responsive, buzzword, buzzword application for them. It's big enough that it is going to take months to develop and require numerous developers. The strategy of "just writing a JS file and adding a script tag to their html, that's how most of us learned it." is not gonna fly. And if you are spending your time doing "If you can't find what you want, build it yourself, maintain it, and use it" then how are you getting your actual application done? You don't want your devs spending a month of time to build (and then support) some templating library or some such when your real task is to write some kind of CRM application. So how do you go about picking technologies, training teams, building upon existing libraries, etc. in order to build your actual product?
In a parallel universe, the Ruby people did it the same, but the other way around, started with hacking stuff together with as much automagic stuff as possible, and now they're writing blog posts about Dependency Injection.
Admittedly, it's not a perfect sine, but give it another year or 3 and the JavaScript people will have settled on one of the four package managers, and the most-used frameworks will be well-maintained and strike a healthy balance between hackiness and enterpriseyness. Sure, any popular language will have incompetent people and they won't suddenly delete their GitHub accounts, but in my opinion, we're not that far away from there. Modern JavaScript tools like React or Webpack really have that craftsmanship you write about. In a way, you could argue that Angular v1 had too much of it.
It appears to me that this cycle happens in each language ecosystem, but with a different phase and starting in a different direction. I tend to prefer programming languages that used to be quite hacky and just started to discover that, well, yeah, oh, there's something good to say about all that architecture stuff those old people kept rambling about. IMO, JavaScript is there right now and moving in the right direction. Elixir is taking off in the same direction (fueled by hundreds of disgruntled ex-Rubyists), Java is currently descending back towards more hackiness (fueled by gazillions of Android programmers who fead a tutorial).
I'm still not sure where to put the PHP guys here but hey, at least they have a working package manager these days (and not four).
It's not very clean; it's not very efficient; you're dealing with weird nonsensical issues all the time; there's a good chance you will cut off your fingers or mash your knuckles.
But... it's incredibly common, there are a ton of writeups on whatever you're trying to do, and the barrier to entry for getting something done is so damn low that for better or worse, it's not going anywhere soon.
The only thing that's going to rescue us from JavaScript is when every browser ships with a common language-agnostic runtime (a la CLR, JVM). The JavaScript-as-a-Transpiler-Target movement has the right idea and a little bit of momentum, but I think the potential obsolescence, the hassle involved in setup and debugging, and the perceived inefficiency scare most developers away.
Imagine if you could code your web app in whatever language you wanted because they all compiled down to the same VM bytecode...
Sure, it makes using other languages possible, but typically that'll just be seen as weird.
Hmm, I don't see why there should be any hassle in setup an debugging. You need tooling to do that automatically, and the tooling is almost there (although it still requires a bit of manual wiring, but it's only a question of time). Browsers already compile this .js code to run at near native speeds, and modern browsers support debugging compiled code reasonably well. There are still significant areas to improve, of course.
In fact, you can treat "compile-to-JavaScript" as a form of VM "scriptcode".
> It is Torvald’s “Release early and often” without the community smashing the ego of anyone publishing sub-par code.
The relative lack of Torvalds-esque public shaming is exactly what I love about the Javascript community. There is an acknowledgment that we can all do things our own way, and that it's OK. We don't need a dictator shouting down people "doing it wrong".
Of course, you can do insane things in JS, but that's part of the fun. Even at its worst, it'll crash a program or browser tab that can just be reloaded. Annoying and inconvenient, but the computer's still chugging and no harm's done.
That's not a free-pass negation of my point that crashing a browser tab is substantially less severe than a kernel panic, and thus likewise greater engineering due diligence is needed for its code. There's nothing magical about it.
JavaScript has turned out to be one of the most versatile programming environments for this "evolution" to happen. Yes there's a thousand ways of doing things, and maybe only 10 of them are good, and maybe those are difficult to find. But the solution isn't to shut down the shit so that there are only 10 things created instead of 1000. That's just stunting growth, and instead of 10 great things you might just end up with 1 because there was no creative competition (or at least inspiration) in the environment.
So to hell with this thinking, you can't expect to be able to control and lock down a vibrant creative environment and expect the same amount of golden nuggets to come out of it.
I've been writing JavaScript code for 15 years now and the things people are making with it are greater than ever, and many of those things have been reborn out of great ideas implemented poorly. With some kind of "craftmanship" standard, those poor implementations would never have come to exist, and there would be less great ideas in the world.
For the sake of being a bit more constructive in my own rant, I think our efforts should be put into guiding people and helping them find the golden nuggets. And this is happening. There's a lot of tutorials out there. Granted, even the tutorials suffer from the same shit:golden ratio, but finding the golden nuggets is what communities are for.
And yet older generations of programming seem to have managed it.
>Craftmanship or quality is not a binary state, it evolves organically
I don't thing code grows into craftmanship, much less organically -- either you have craftmanship as an attitude from the beginning of writing something or not.
Code itself doesn't grow into craftmanship, because craftmanship is what a person does. A person gets better with experience (both from doing and from observing) and inspiration. Greater visibility and sharing of code means better experience (through observation) and better inspiration (from people sharing their great ideas).
If you think I'm wrong, the alternative solution isn't difficult: you can avoid shared code repositories altogether and instead write more code from scratch. If you still want code sharing, you can start your own online repository where only thoroughly vetted code is allowed in. The important value to me is that people are not encouraged to censor themselves, but that we push ourselves harder to increase quality, by sharing both our knowledge and our work even more. If navigation is an issue, we need to build better tools.
Multiple choices, competition, and organic growth is healthy for the system – enforcing artificial limits believing it'll increase quality is not.
>The sad truth is that something essential gets lost in all of this everyone-can-do-it-yay-lets-all-code euphory. I’m not exactly sure how to call it, so I’m going to pick something that is close enough to describe what I mean. I’m talking about craftsmanship.
Just because many newer developer's code is public on GitHub, it doesn't necessarily mean code quality is going down. Back five years ago, when many developer's code was stored on their machine, there was no way of knowing if their code was any good.
Now, developers are encouraged to show off what they have, because Git shows how you've progressed as a developer. It also allows for developers to help each other and make each other's code better. I know collaborating on GitHub has helped my code quality go up.
It's like music lessons - very beneficial in all kinds of tangential ways although very few students will become concert pianists.
A proliferation of projects is an indication of an exciting and experimental community. If you run off half-cocked and take on an unproven and unmaintained library and build an application on sand then the fault lies with you, not the ecosystem.
The entire contention is that it's difficult to tell which ones are going to become unmaintained because of the amount of churn.
I am a back end developer who has been venturing to the front end world. Having to change frameworks all the time means never getting to know any in depth. Whereas on the back end I can stick with a solid framework - Django, and the stuff I learned 3 and a half years ago is still relevant. And the SQL I learned ten years ago is also relevant. And I can do a lot more complex querying now than I did ten years ago, when I struggled to learn LEFT JOIN syntax. I don't see any of my JavaScript experience being as long term.
(Actually the NoSQL movement is causing similar issues in the back end, with so many devs insisting on using the latest new key-value store when a relational database would be the most suitable tool, and the time spent performance tuning rather than learning a new query language).
Do something about what?
Lots of discarded projects on Github? Too many people working with Javascript? Fast iteration? Lowering barriers to entry?
Those all sound like good (or at least neutral) things to me. I've clearly missed the point of this post.
Note that the author comes from Java. Developpers coming from dynamic languages will be much less annoyed by JavaScript vibrant ecosystem.
As a plant engineer, you're going to have to part out and understand a system in its entirety at some point. And you'll be rating bolts and nuts and greases and such to meet the specification you need. There are a lot of bolts to choose from. It's the same for chips or components when designing a circuit: there are lots of transistors to choose from. For many tasks, many will effectively be interchangable. Sometimes you'll need to be careful, and other times you'll be working on a system where you'll need to research the manufacturer to make sure they're likely to be still in business in ten years.
But you'd never reasonably complain about the choice. Nor about all the regular folk just building a porch out of some wood and screws from Home Depot. You wouldn't complain about a kid learning circuitry by plopping some random components from Radio Shack into a breadboard (which they'll never move to a proper PCB). And I don't see why you'd complain about millions of people interacting with software the same way. Learning to deal with the glut is as simple as going to a curated aggregator (Home Depot/Radio Shack) or becoming an engineer.
I've seen the sort of stuff non-programmers inflict on systems. I'm not even talking about JS on the web, but like simple relay-equivalent ladder logic on heavy machinery. It's just as bad there. But. Work needs to get done, production needs to move forward, and craftsmanship is expensive and time consuming. There's a place for the cowboy programmer, just as there is for the craftsman.
So it seems a bit silly to complain about the situation. To me, it just means software is becoming an industry just like any other.
If you're building an application that will take a non-trivial amount of time to build and will have a lifetime of years, what technologies would you pick? How do you train your team members? What is your strategy for maintaining it into the future?
If someone built a webapp 10 years ago, it would be php, rails, asp.net, java, etc. And you can find someone who would (possibly reluctantly) get in there and do something with it. But what about the app built using 20 npm libs. What do they do in 10 years?
Read the code, just like they'd read the PHP/Ruby/whatever? Not sure I understand what problem you're suggesting.
Where is this mystical app that gets sudden developer attention after 10 years of maintenance-free use? I've never come across a 10 year old application that hasn't been actively maintained that didn't need at least parts rewritten.
Although it's not a great language by design, I think there's a reason why it has reached wide adoption. And don't tell me it's because there are no alternatives.
Those are some of the alternatives - at the end of the day most people seem to prefer going back to straight HTML/CSS/JS to build things. They're not perfect but they're pretty easy to learn, they separate the concerns of content, presentation and logic, and they work everywhere (sometimes with a little help from jquery or modernizr).
Transpilers are reasonably popular, but they're band-aids over the real issues, and are susceptible to inherit the problems that the shaky foundation lies out, and the mechanisms for library interoperability are not always stable. These problems also persist in the ever evolving landscape of JS frameworks, which are symptoms of the limitations of JS.
The other side of it is about what works in the commercial landscape. Building around an uncommon tech stack is a risk when it comes to hiring. The widespread nature of JS is part of what keeps it popular, but that's not necessarily based on merit.
I'm pretty sure that this is exactly the reason: JavaScript is found in every browser, and only JavaScript is found in any (modern) browser. That's the only reason it's widely-adopted.
> The sad truth is that something essential gets lost in all of this everyone-can-do-it-yay-lets-all-code euphory.
This attitude has been wearing on me as well. Although we shouldn't self-aggrandize, it's hard to do this work well, and so many don't do it well. And I realize that yay-everyone-can-do-it is a correction to the insularity and shitty forms of exclusivity that developed in some areas of software development, but it's sadly not the whole truth.
And you can't really say this without being a "hater" and so forth, especially in the Javascript community. They're very self-congratulatory about their community's ethic of acceptance, which is of course a wonderful thing. But there is no space to offer a viewpoint counter to this or to say "yeah but...". I suppose this will change in time.
This x 100000
This is why I hate package managers in a nutshell. The reason is that it reduces the friction for developers of packages to issue updates to a critical level where they turn round and blame package consumers for not using the latest versions while the consumers spend their lives battling with the ever changing bugs and APIs of the packages.
This isn't just an open source problem, as I first ran into it in a company that made many of the mistakes a decade ago that the open source community is just making today. Lots of really nice sounding ideas that increase the productivity of a few individuals working on inner level packages at the expense of the whole organisation.
I think it's similar to writing an essay in some ways. Some people sit down and think for a while, then write the essay in one sitting. They then make some minor grammar corrections and otherwise polish the essay before submitting it. Others (like me), sit down and write whatever comes to mind. Then they rewrite everything, and then they rewrite everything again, etc. Finally they have an essay that they are happy with, make some small polishing changes and submit it.
In the end, both approaches work fine for writing an essay, just like both approaches work fine for writing code. The key, when talking about speed and iterative development, is that the code isn't finished when you have something that appears to work. You have to go back through and rewrite things, refactor, add additional tests and clean the code up.
- I can see the number of downloads on the npm website and so on.
- I can see the issues and pull requests on github
- I can do a git clone + npm test to see if the tests still run or even better see the travis batch that is in the readme.
I prefer a vibrant community and lots of libraries over a slow and "solid" library development community.
In the end - I need to write code any way to fix any of the libraries issues... With lots of libraries, at least I have the chance that somebody already forked the library and fixed my problem.
Otherwise, I ll fork the lib - fix the issue and use the fork myself and send a pull request to the original lib. Once the pull request is accepted - i can just point my dependencies again at the original lib.
Perfect isn't it ? I fix the problem for myself and the community gets a fix back to the original lib almost for free.
So yes, there is garbage out there, but I feel I have a lot of tools to "smell" it and stay away of these before investing too much time.
Both languages aren't sexy at all.
But JS is more versatile. Runtimes are available (and preinstalled) on many servers AND clients. And it's OO and FP seems to be more flexible to me. I get a more smalltalk-feeling from using JS than I got from PHP back in the days.
I have seen a few project that were completely build on its own, without dependencies on external libraries. Not only that those projects turn out to be even less modular (because it's not enforced by a package manager / module system), but the chances that code gets unmaintained are also rather high, since developer time is often rare.
An interesting point is releasing the software. No problem with putting it on GitHub, but if projects are commited to official registries like NPM or Bower, the author should really put some commitment into it. Currently it gets ever more complicated to find good quality libraries, becoming a needle in haystack problem. So a "release ethic" wouldn't be too bad.
We are a small shop. Two people and hope to grow. We publish a web database. Our market is academics, libraries, and scholars. Our Data must be kept in XML. It just makes the most senese.
But we are spread over a half dozen different languages. Halfway proficient at all of them, but as we move around to a new project and set one language aside to pick up the other we regress. What we had known must be relearned, the way we were thinking must be retrained.
If we created our web services, our internal API's, our production system all largely in the same language we should, I think, we come more proficient and quicker in this language. At the end of the day we need a well functioning, modern web application. So I have no alternative but to be very current in javascript it feels.
Might as well set aside our old Java 5 app. Might as well not create a new python project as fun as it is for me when I am the only one that can understand the python. Might as well stop pouring all my efforts into a silo. Why note double down on javascript.
A key source of inspiration for this line of thinking is from a conference presentation I saw given from some at O'riely. They were experimenting with their upstream source of their products being HTML5. The HTMLBook[1] project seems to logical enough. Their output is almost exclusively HTML. Be it on the web, the ereader (epub/mobi) or with the PDF. They were using Attenahouse to convert HTML to PDF using CSS.
Why mess around with several different languages. Keep it simple, and produces nice things quickly. If they aren't as nice as you hope refactor. With not having to retrain parts of your brain for javascript as you were working on a Python project exclusively for the last month and a half we should be that much quicker.
Companies need to team up to put resources behind projects they like and organize their efforts in a sustainable way. One effort that's proven effective has been Apache: http://www.apache.org/foundation/how-it-works.html
Their foundation ensures projects have a good mix of contributors and aren't driven by the whim of a sole corporation or a few hobbyists who would never be replaced when they leave a project.
Said any group that has implemented certifications to make entry into their discipline more difficult to newcomers. "Craftsmanship certification" is something I wouldn't be shocked to see becoming a business in the next 10 years.
There's a worst case of no-one noticing, which will hopefully be a great relief for the anxiety (and yet you can say you published your code), and a next worst case that it's never used and is simply inspiration for a better library! Of course best case is people use your code, modify, expand, and build upon it. You'll be credited in their libraries as part of their inspiration, and the state of the art moves forward.
There are many that want deeper curation on quality; it's hard to deal with all the noise out there. But it's critical to remember that we can always layer curation on top of the bazaar at no additional cost. As the scene settles into its grooves, the better curators will stand out.
Haters gonna hate!