`
photon
  • 浏览: 70527 次
  • 性别: Icon_minigender_1
  • 来自: 大连
社区版块
存档分类
最新评论

A note on "An Introduction To Full-Stack JavaScript"

阅读更多

Undoubtedly, this is a good article on javascript and related good practice, and it expained a lot of concepts in easy words. But I think some of its parts worth further discussions.

1. Should parallel be an explicit attribute/mechanism when used? Such as when lock mechanism is used in thread-programming.

Alejandro Hernandez provided a piece of snippet as an simple example for parallel.

db.query("SELECT * FROM 'table'", function(resultset){
   drawTable(resultset);
});
doSomeThingElse();

In this snippet, Even though the function db.query blocks, the execution of the code would be able to go on to the next statement outside of db.query. So the doSomeThingElse(); can be executed without any delay. This is what parallel here means. But the snippet here can bring a confusion to programmers.

Block and parallel are two different mechanisms. So when a programmer sees a piece of code like this, he is probably not sure what would happen when it blocks. If he is unfamiliar with the code, nothing could tell him about the handling mechanism on blocking related to this piece of code. He simple doesn't know if the execution would go on or pauses.

Further more, the event-polling mechanism itself could be time-consuming or resource-consuming. So it's something that should be paused or ended under certain conditions. The conditions could be various and quite different in different environment. This might mean, that the event loop mechanism of Javascript need to be extended a lot in real world. In other words, you need your own scheduler. I'm not sure how Javascript could help developers face this challenge.  

It is good that Javascript could provide a light-weighted event loop or scheduler mechanism that's already handy or built-in. But it's better if programmers could use an existed library or write their own library to do the non-blocking jobs for flexibility. And, without underlying interfaces that Javascript could provide, programmers cannot finish this job easily.

2. The title of this article.
If it is called something like "fully-equipped javascript" instead of "Full-Stack JavaScript", it might be better.

 

In the end, put a comment I saw from Christopher Probst:
"Python for instance has very nice async support using gevent (no callback hell - coroutine based) or twisted. And everybody knows that callback based I/O is just horrible. Ever heard of haskell ? Async I/O done right!"
http://chetansurpur.com/blog/2010/10/why-node-js-is-totally-awesome.html

Ever heard of haskell ? Async I/O done right!


Original articles:

English:
An Introduction To Full-Stack JavaScript:
http://coding.smashingmagazine.com/2013/11/21/introduction-to-full-stack-javascript/

Chinese:
全栈式 JavaScript 介绍:
http://segmentfault.com/a/1190000000355221

 

related:

Part 1: Understanding event loops and writing great code for Node.js:
http://developer.yahoo.com/blogs/ydn/part-1-understanding-event-loops-writing-great-code-11401.html

A Curious Course on Coroutines and Concurrency
http://www.dabeaz.com/coroutines/

Coroutines via Enhanced Generators:
http://www.python.org/dev/peps/pep-0342/

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics