drderidder

Well said! Dynamic memory allocation is a really big performance hit, and in a lot of cases you can pre-allocate data structures on the stack for serious speed improvements. Avoiding DMA was one of the secrets for writing blazing fast real time systems stuff when I was in telecom. I don't think those benefits have gone away.

The article is somewhat misleading. Keeping up with software evolution is something large North American companies struggle with as well, and while Japanese companies may be slower to adopt some software trends that are commonplace here, Japan lags in very few areas technologically - and leads in a lot of others. Every time I visit I'm blown away by the innovative application of technology. There are electronically controlled traffic lights aplenty in Japan, ubiquitous high speed internet, and all the accoutrements of modern electronic communication in greater abundance and density than most of North America. The "human powered traffic lights" the writer alludes to are just safety officers who assist traffic and pedestrians at some crossings where construction is underway, usually in addition to to the usual traffic signals; an example of the emphasis on service and attention to detail sorely lacking on this side of the pond. If faxes are still in use it's a result of the fact that practically everybody had one in their house long before most North Americans had ever used one. Having been so widely adopted, it's not too surprising that their use has continued for longer. I think the author went a bit hyperbolic in an effort to make a headline out of something which is actually not that big of a deal, although there are likely just as many if not more opportunities for software modernization in Japan as there are elsewhere.

Hmm, that the acquisition would mean anything for node directly seems off. At least, the blog post seemed to indicate that this wasn't meant to be about IBM buying influence. I wasn't a customer and not particularly keen on the enterprise focus of strongloop but I thought you had a really good thing going with loopback. Not sure what to think of it now... I was in a startup that got acquired by a huge multinational and it was shocking how quickly we went from nimble to gridlock.

Well, that's true, the masters didn't forget about Bach even though the public mostly ignored it. Thankfully Mozart, Beethoven and Mendelssohn helped to keep an appreciation of Bach's work alive.

Bach, my all time favourite. An absolute genius; his work was almost forgotten, thank goodness it was rediscovered and preserved. Excellent performance of Prelude and Fugue in C Minor; two pieces I played back in the day for RCM Grade exams.

What frightens me is that we don't seem to have come far enough as a society since those times. Benjamin Barber and Noam Chomsky have done a pretty good job of exposing current-day American exceptionalism. This article points out that the attitudes which made such atrocities possible still exists today. Chomsky's essay "We Own the World"[1] is another good read - it's uncharacteristically short and accessible. Alas, "a prophet is without honour in his home town".

1. http://www.chomsky.info/articles/20080101.htm

I feel like the techniques React uses to deal with state and performance are likely to be addressed in a simpler way by solutions that work better with the existing stack. I'm not an Ember user but I like the way they've approached this, without re-inventing the DOM wheel.

All the core team really lacks now is the node.js label. Joyent's trademark seems weak, since the term was in prior use for commercial purposes well before they came along. A trademark challenge might be one possibility. On the other hand, name changes in other open source projects have worked out just fine.

I think it shows how important it is to maintain a healthy work-life balance. Hopefully he'll find a way to combine his technical aptitude with his new lifestyle in a symbiotic way.

I recently read this, worked through the examples, and was pleasantly surprised at the depth and quality. Subsequently we recommended it to our 800+ member meetup group as the top learning resource for new JS programmers. The content is enlightening and enjoyable and could be just the thing for reaching a breakthrough in understanding about functional programming.

What is a kicksled??? I want one already!

[update] wow...found one, the kickspark! Awesome. http://www.goslide.ca/en/shop/kickspark.php

I just skated 13K on the canal in Ottawa - it's a blast. This year the ice is good but it varies, some years you get only a couple weeks of decent skating. For reliable self-propelled commuting in winter you're probably better off looking to bike paths and cross-country ski routes - there's no shortage of snow!

Basically anyone who has a business model related to the node.js ecosystem would benefit by not having development under the control of a single corporate entity. Isaac was in a tough place back then. I think spinning off NPM was a good move for him and it's great to see him on board with the community fork.

PS. A number of people were against it at first, including Nodejitsu guys and Michael Rodgers. I wrote that either a foundation or a community fork were inevitable. Eventually people realized it, and it turned out to be a community fork. If a meaningful foundation were to happen at this point it would have to be built around io.js in my opinion.

About a year ago I posted "node.js needs a new home" on the mailing list. It started a minor s### storm and a couple of local IBM guys went down to talk to Joyent, which eventually led to the whole advisory board / foundation initiative. Mostly it was all back-room discussions between companies taking place in private from the wider community. They're great people, but that isn't really what I had in mind.

IBM's cloud offering runs on the PowerPC architecture, and older versions of V8 won't run on it, so they can't offer Node hosting. They ported a private build of Node to run on PowerPC using a new version of V8, but Joyent has so far refused to upgrade V8 despite having a pull request with all the work done. It looks a lot like Joyent has been dragging their heels on V8 updates just to fend off an IBM cloud service for node.

The first five words of the announcement are: "Joyent, IBM, Microsoft, PayPal, Fidelity". That says a lot right there. StrongLoop, NPM and a bunch of others are excluded, the whole thing seems to have been baked up in private by people who aren't core contributors, and then sprung on the community like it's some great thing.

Maybe it's a step in the right direction, but as it stands I'd expect this foundation to be about as useful as another hole in the head. I've seen enough corporate bad behaviour from some of them to not care about their special little club right now, and I don't think it will win too many people over.

[Update: Fedor posted about it here https://medium.com/@iojs/io-js-and-a-node-js-foundation-4e14... ]

I got a copy of Paul-Henning Kamp's critique "HTTP/2.0 - The IETF is Phoning It In" off the ACM website before the link went dead. Here's a bit of what he said about it:

"Some will expect a major update to the world’s most popular protocol to be a technical masterpiece and textbook example for future students of protocol design. Some will expect that a protocol designed during the Snowden revelations will improve their privacy. Others will more cynically suspect the opposite. There may be a general assumption of "faster." Many will probably also assume it is "greener." And some of us are jaded enough to see the "2.0" and mutter "Uh-oh, Second Systems Syndrome."

The cheat sheet answers are: no, no, probably not, maybe, no and yes.

If that sounds underwhelming, it’s because it is.

HTTP/2.0 is not a technical masterpiece. It has layering violations, inconsistencies, needless complexity, bad compromises, misses a lot of ripe opportunities, etc. I would flunk students in my (hypothetical) protocol design class if they submitted it. HTTP/2.0 also does not improve your privacy. Wrapping HTTP/2.0 in SSL/TLS may or may not improve your privacy, as would wrapping HTTP/1.1 or any other protocol in SSL/TLS. But HTTP/2.0 itself does nothing to improve your privacy. This is almost triply ironic, because the major drags on HTTP are the cookies, which are such a major privacy problem, that the EU has legislated a notice requirement for them. HTTP/2.0 could have done away with cookies, replacing them instead with a client controlled session identifier. That would put users squarely in charge of when they want to be tracked and when they don't want to—a major improvement in privacy. It would also save bandwidth and packets. But the proposed protocol does not do this.

[He goes on to tear a strip off the IETF and the politics behind HTTP/2.0 ...]

Why is this better than tshark?

Angular emanated some 'project smells' that have kept me at arms length. The size of the codebase was very large compared to alternatives. Lots of add-on solutions for various problems (ng-this, ng-that) kept cropping up. Articles explaining how to do X or Y in Angular indicated things were probably not as simple as they ought to be. And, it was mainly driven by Google as opposed to a small core team of diverse individuals. The tools that have turned out to be the best in my experience have often had one visionary lead developer, a BDFL-type champion. I expect Angular to appeal more to enterprises, while the early adopters and lean startups shift towards small libraries and microframeworks. I think web components will become more and more important, and that we'll begin to see more libraries to assist specifically with data persistence and synchronization between the client and server.

Node got forked because it got corped. When a corporation sinks their hooks into an active open source project, it's only a matter of time. Mysql, Maria, Hudson, Jenkins... same story. io.js is the way forward, and congrats to the core team.

I don't like the manager / developer separation. I've had better results using lightweight strategies to let projects be more or less self-managing. Basically just creating a shared vision, giving responsibilities to people, letting them set their own goals, and then publishing to the group how those goals are progressing on a weekly basis. It doesn't take much time and people usually appreciate the communication.

Sure. First off, I should say that as the lead developer I took ownership of these decisions. Design by committee is certain death. I didn't ask for permission; I sought input from various stakeholders (often one-on-one) and made it clear that while the final implementation might differ from their suggested approach, I would be proposing solutions that took everyone's basic concerns into consideration. After gathering feedback, it would be several weeks before a new iteration was put forward for review. Stakeholders could use and interact with it. More feedback would be solicited and then the next iteration would begin, again taking the feedback into consideration but not making any promises. I had managers who were furious with me for not kowtowing to their demands, but I'd produced a very successful prototype (featured at Blackhat 2013 and Mobile World Congress) and they grudgingly had to admit that the results were better than anything the previous design-by-committee approach had produced.

  * Design - what is the product supposed to look like?

Good design is not part of the DNA of large enterprises. This makes it low hanging fruit for upstart competitors to come in and impress clients with the usability of their "slick" design. Because purchasing decisions are increasingly being influenced by the people who will actually use the product, this gives them a tremendous competitive advantage. In large software teams, its typical to begin design with the data model, and progress through successive layers of code until the data finally goes splat on the users screen in a great meaningless pile. Smaller companies, especially ones with a legacy in web application design, have figured out the value of designing the User Experience first, and then developing the lower layers. This is not without tradeoffs; a new use case that you never envisioned can force changes to the data model that break compatibility. I found that working from both ends of the stack (prototyping the UX while simultaneously considering the data model and future use cases) was beneficial. Anyway, it's amazing how much software actually gets built without anyone even thinking about what it should actually look like to the end user, until the very end. When managers come from the era of punch cards and PDP-11, well, this is just how it is. You have to fight that mentality by pointing out the contracts they lost because the product looks like crap.

  * Testability - how do you intend to test your code?

It amazes me in this day and age that there are still product managers who believe automated testing is a waste of time. I set out a goal of having 100% test coverage, which I maintained for quite a while. Gradually the test coverage declined as new use cases needed to be supported. It simply wasn't possible to cover off every error case or alternative configuration of the product, but I still keep coverage between 80 - 90%, with most of the uncovered code being error handling corner cases that are not supposed to happen in production, or code that exists purely for running in a non-production environment. Incidentally I use Mocha and jscoverage for this, but there are lots of options. The important thing is to choose one. Tests are triggered from npm, which is in turn triggered from make, which is in turn triggered from Jenkins every time code is submitted to our repository.

  * Documentation - how will the code, product be documented?

Initially I set out with a goal of having the project be "self documenting". I settled on having an API that roughly follows HATEOAS principles - the idea being that given the root URL, a user could easily discover and navigate their way through the rest of the API with a web browser. I then used tools like RESTClient and POSTman along with Selenium IDE to automate some REST API developer tests. The output of these could be cut and pasted into an OpenOffice document that I submit to our code repo along with a PDF version. This isn't as fully automated as I would like, but I've got an excellent Install Guide, Developers Guide and User's Guide that can be easily updated and are readily available. They were created early in the project, in tandem with development. Tasks were not considered complete until the documentation had also been updated. QA helped ensure this.

  * Tooling - what's your preferred dev tool chain?

This is purely a personal preference, but I use Sublime for most of my JS related development. Outside of that, I'm a dedicated vim user. I dislike big IDE's because I feel people and projects become dependent on them and they foster unnecessary bloat and complexity because they don't require a developer to hold the whole design in their head. An ongoing problem is poor quality code getting into the repo and not being flagged until a bug surfaces or a build fails. I wanted to move that feedback much further forward in the development process and make it immediate, to catch problems before they ever got submitted. For that, I wrote a sublime plugin for jslint (Sublime-JSLint) with a lint-on-save capability. Any time a developer saves a file, they get immediate feedback on whether it passes the linter. This gets repeated on the build server, and lint warnings will literally break the build. As a result, all of our JS code is very consistent.

  * Code architecture - What's your design philosophy?

In addition to web-first, mobile-first, and API-first approaches, you might have strong ideas about MVC architecture, REST API best practices, abstraction oriented architecture, OO, Functional programming, etc. Being trained first as an artist, my preferences are pragmatic. I want strategies that will get me from concept to product as quickly and easily as possible. I've found an API-first approach with an abstraction-oriented architecture to work well. I began blogging about REST API best practices as a way to gather information on the topic. I also wrote a couple of pretty bad "REST" APIs before I started getting better at it. Now there are frameworks like Sails and LoopBack that will guide your API design.

  * Prototyping - straight to product or prototype first?

I do believe in prototyping first, but you should be willing to view the prototype as throw-away work. Prototypes are often thrown together quickly and incur tons of "technical debt" almost intentionally. Trying to productize a prototype can be more difficult that simply starting from scratch. A lot of times managers will wonder what the hell is taking so long... they saw a working prototype and they've already got customers lined up to take it, so where's the product? They don't realize the prototype is all smoke and mirrors running off a flat file and your personal Google API key. You may need to explain that the prototype is not suitable for productization, and why. On the other hand, if you do want to go from prototype into production, you need to be careful when you build the prototype not to incur the technical debt of a quick-n-dirty mockup, and figure out the path for getting from prototype to production. Things like replacing the data access layer with something that talks to a real database, and having a proper configuration file, etc.

  * Delegation - how to structure for future delegation?

API first design is helpful because it provides a sort of contract by which various components can interconnect. Although I initially wrote the API, server, mobile app, and web interface to the product, the API allows any of the client applications to be forked off into a standalone project. Eventually we did this with the mobile app. This is where the documentation started to prove its worth. The point is to think about how the project and the team is likely to grow, and which parts could be handed off to another team, and how to define clear boundaries with a clean interface between them.

  * Security - how to audit the security of your app?

It's often just assumed that applications will be secure, and then of course they aren't. Session hijacking, SQL injection and cross-site scripting vulnerabilities have been present in most of the web-based user interfaces of projects I've reviewed. Enterprise sw developers tend to be unaware of what these attack vectors are and how they work. There's no substitute for being knowledgeable about web security but there are tools like Nessus and Skipfish and various penetration testing tools that can help. I guarantee they will turn up security issues you never knew existed. If you can automate the process, great. If not, making a security audit part of your QA process is important.

adj. of, related to, or characteristic of a Luddite.

Luddite: one who protests against modern labor-saving technology.

There were a few alternatives on the client side. Not many, but they do exist: Java was supposed to be the alternative for building web based applications, but Applets didn't gain wide adoption. Flash did better but eventually became unnecessary as the web stack itself got good enough to build things like Google Docs, Processing.JS and such. Then there are the "transpilers" like GWT and the various *script dialects that compile to HTML/JS/CSS. On the server side there are tons of alternatives, of course. Even things like Virtx.io that has bindings to a number of languages including JS.

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).

I'm thinking of things like TodoMVC. There's an abandoned list on nodejs.org that categorizes many of the earliest npm modules. A lot of those modules have matured and are still in use. MicroJS.com is another one I'd probably reference. Curation is a problem in most languages, especially popular ones. Java definitely has the same problem, and anyone wanting to develop native cross-platform apps is faced with similar bewildering choices.

Okay.

> 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.

Wow, I have rarely encountered a more ludditic comment on HN. The number of bare assertions alone is bemusing.

Yeah. There's a great recent post by Jeffrey Ventrella on "Slow Programming"[1] highlighting the problem that comes from the "fallacy that all engineers are fungible"[2] and throwing a bunch of programmers immediately into an iterative development cycle without proper up-front planning.

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?

These points often seem to get left as an afterthought, but these broad strokes have worked pretty well for me and still allow for iterative development and functional refinement.

  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/

Aw, come on, you really should. You know what happens when you publish something to npm? Approximately nothing. Your module gets in there with a bazillion others. Maybe someone will use it. Maybe not. Man if you could see the lame-ass library I first published to NPM you would laugh. The only way you get better is by putting yourself out there and just keep doing it.

Exactly. Is there value in learning to code? Of course. Does learning to code mean you will be able to write quality software? Unfortunately no. Especially if you learned to code in a sort of crash course on web application development. To be honest I've forgotten 90% of what I learned in engineering school, but I feel the triple-variable calculus, statistics, circuit design and assembly language driver hacking somehow prepared me for solving rather tough and unfamiliar problems in the real world.

It's like music lessons - very beneficial in all kinds of tangential ways although very few students will become concert pianists.

What is happening with the web stack now is a sort of renaissance with an unprecedented pace of activity. It's easy to feel overwhelmed, which is why I started a local meetup group that has now grown to 800+ members, all wondering the same thing: where do we start and what is worth investing our time in? Through conversations and presentations we learn what has worked well for others. Gradually, I expect the "storm, norm, perform" cycle to work its way out in the JavaScript community as consensus starts to build around which tools and frameworks are best. That is already happening to some extent. I don't think bemoaning the state of rapid innovation in the web stack is terribly useful; rather we need experienced developers (unbiased ones, preferably) to curate their collection of JS tools and resources and publish it for the benefit of others. One of the talks I've been wanting to give for a while is simply a "3000 ft survey of the JS landscape" or similar - mapping out the territory in terms of client-side MVC, server side JS, build tools, static code analyzers and tracers, libraries, etc. (If anybody knows of existing efforts to curate such a list, I'd love to know about them)...

Kudos to Etsy for doing this. I think there's great value in learning basic programming skills even if not everyone has the inclination to become a software designer. Kind of like how taking music lessons has all kinds of tangential value even if the student doesn't turn out to be another Van Cliburn.