октомври 20, 2011
октомври 14, 2011
What Is Wrong About 17259 Lines Of Code, Q&A
Web Reflection: What Is Wrong About 17259 Lines Of Code
I can answer and it is pretty simple and they have answered already by the way, you seem to just failed to read it: They have the resource and the will. Which means they can put 30 or 100 developers into something for months and even years and pay them to do something that might fail epically and still they would not mind! While the smaller companies and single developers cannot invest months into something that might fail or just be useless.
On the 'why' - it is just an experiment. The high expectations are to be the browsers that 'runs it native' and maybe they believe it will give chrome and chromeos some better user acceptance. Or maybe they really believe it is a step forward.
Anyway, just let them be. AFAIK very little number of companies are using the other attempts: GWT, Closure library, Go and so on. If we leave it alone it might become just one more project of them.
I can answer and it is pretty simple and they have answered already by the way, you seem to just failed to read it: They have the resource and the will. Which means they can put 30 or 100 developers into something for months and even years and pay them to do something that might fail epically and still they would not mind! While the smaller companies and single developers cannot invest months into something that might fail or just be useless.
On the 'why' - it is just an experiment. The high expectations are to be the browsers that 'runs it native' and maybe they believe it will give chrome and chromeos some better user acceptance. Or maybe they really believe it is a step forward.
Anyway, just let them be. AFAIK very little number of companies are using the other attempts: GWT, Closure library, Go and so on. If we leave it alone it might become just one more project of them.
октомври 09, 2011
октомври 03, 2011
Node madness
I may or main not know - I make living as javaScript developer. As such I invested time and energy even beyond my 8/5 work schedule - I often fund myself involved in on-line activities related to augmenting my skills in the language I support my family with.
This said, it is explicable that I as excited when nodejs came around. I was not exactly one of the first adopters and around he time I tried it there were connect and early form of express and other middle ware and frameworks that ease the server side development. And I was relieved! Because frankly who wants to reinvent the wheel.
Yeah, node promoted itself big time in the JavaScript community, promising you the ability to write your logic once and run it anywhere, the server and the client alike. There are even companies that struggled for almost two years to reveal a large scale product based on node (like nodejitsu and cloud9). Interesting and useful (mind you!) things came to life - Socket alternative (like commet for python) at your disposal that you can code for in the language you already know well, for example. I for one was struggling once with Comet!
This however must come to an end. Why? Well, the thing is node might be great for some subset of application cases, I for one have never had one of those however. Node still does not have great SQL linkage (unlike any other server side language you still cannot reliably use stored procedure in the SQL server and have reliable return values in your JavaScript, I my practice we had to modify the procedures to have only one SELECT to be able to parse the results correct in mysql-node.
And today I read this article that says it well : node js is cancer. Why? Because it is over praised and use for "everything", while its niche is in fact pretty small. The fact that get to use language on the server that you already know might be tempting, but the thing is - it is not necessarily appropriate for everything. And while you applications logic start requiring ultra dynamic server side + client side mix of JavaScript it will never be! I mention that because there are good projects out there that allow you to call server side JavaScript objects and method and this sounds very tempting to me, as on the server I can rely heavily on standards (V8 for example) this is mostly not the case in browser environments. On the other side this is somewhat simplified work around for cases where server side calls are performed and executed in other languages - i.e. the client side does not need to care about the server side implementation, which IMO makes this somewhat pointless, unless you need to write the server side logic as well.
My disclaimer: I have release exactly one web project completed entirely in node.js environment. And to tell you the truth - very simple one. And I gave it all up. Why? Because this is simply bull shit! I had to re-create in JavaScript functionality that was build and ready to use for years in pretty much any other server side language. And on top of that I had to learn new tools for server side deployment, 'forever', node set-up, npm set up and other things just to get this one web site going. And mind you - the idea and implementation there was easy! The most simple thing, sending emails, took me a day and a half to start working properly. Not because I don't know the language, just because out of the 8 implementations in npm only one was able to do what it is supposed to to - everything else made the main server dislike us. Try this in any other language, be it java, python or php or really anything server side and you will see - it will just work.
So you see, I am not against node.js. I am against using it as general purpose server implementation.
Yet another thing I have to confess: I use node applications to JSLint my client side code, I use jade executable to compile my client side templates and I use uglify JS to minify my code. I sometimes also use requirejs with node to minify and compile the client side code before deployment. But notice - those are only tools. I would never use those on server side application.
How I see the future? I think most useful it would be to just make node work as library on top of apache like the python interpreter is. And use it only where needed!
This said, it is explicable that I as excited when nodejs came around. I was not exactly one of the first adopters and around he time I tried it there were connect and early form of express and other middle ware and frameworks that ease the server side development. And I was relieved! Because frankly who wants to reinvent the wheel.
Yeah, node promoted itself big time in the JavaScript community, promising you the ability to write your logic once and run it anywhere, the server and the client alike. There are even companies that struggled for almost two years to reveal a large scale product based on node (like nodejitsu and cloud9). Interesting and useful (mind you!) things came to life - Socket alternative (like commet for python) at your disposal that you can code for in the language you already know well, for example. I for one was struggling once with Comet!
This however must come to an end. Why? Well, the thing is node might be great for some subset of application cases, I for one have never had one of those however. Node still does not have great SQL linkage (unlike any other server side language you still cannot reliably use stored procedure in the SQL server and have reliable return values in your JavaScript, I my practice we had to modify the procedures to have only one SELECT to be able to parse the results correct in mysql-node.
And today I read this article that says it well : node js is cancer. Why? Because it is over praised and use for "everything", while its niche is in fact pretty small. The fact that get to use language on the server that you already know might be tempting, but the thing is - it is not necessarily appropriate for everything. And while you applications logic start requiring ultra dynamic server side + client side mix of JavaScript it will never be! I mention that because there are good projects out there that allow you to call server side JavaScript objects and method and this sounds very tempting to me, as on the server I can rely heavily on standards (V8 for example) this is mostly not the case in browser environments. On the other side this is somewhat simplified work around for cases where server side calls are performed and executed in other languages - i.e. the client side does not need to care about the server side implementation, which IMO makes this somewhat pointless, unless you need to write the server side logic as well.
My disclaimer: I have release exactly one web project completed entirely in node.js environment. And to tell you the truth - very simple one. And I gave it all up. Why? Because this is simply bull shit! I had to re-create in JavaScript functionality that was build and ready to use for years in pretty much any other server side language. And on top of that I had to learn new tools for server side deployment, 'forever', node set-up, npm set up and other things just to get this one web site going. And mind you - the idea and implementation there was easy! The most simple thing, sending emails, took me a day and a half to start working properly. Not because I don't know the language, just because out of the 8 implementations in npm only one was able to do what it is supposed to to - everything else made the main server dislike us. Try this in any other language, be it java, python or php or really anything server side and you will see - it will just work.
So you see, I am not against node.js. I am against using it as general purpose server implementation.
Yet another thing I have to confess: I use node applications to JSLint my client side code, I use jade executable to compile my client side templates and I use uglify JS to minify my code. I sometimes also use requirejs with node to minify and compile the client side code before deployment. But notice - those are only tools. I would never use those on server side application.
How I see the future? I think most useful it would be to just make node work as library on top of apache like the python interpreter is. And use it only where needed!
октомври 01, 2011
Project shift evaluation (Target: Closure library)
I have given another though on closure library + compiler + templates.
I have downloaded the source, the compiler and template utilities. The source is really well documented.
Unfortunately I have issues with the fact that the compiler understands only certain subset of the JavaScript language, which means that I as developer need to restrain my work to those limitations for the only purpose to be able to compile the code to a usable size once development is completed.
I have tried to compile some of code as it is - it mostly did not work:
I find this exercise to be tedious for the developer; if a statement is valid JavaScript compilation should NOT break it.
I likes the name spaces idea nice, however the module pattern is equally nice to me.
Now about the templates. Our design guys make the prototypes in plain html. It seem fairly easy for a developer to translate this in closure template. However the fact that I need to use it with closure compiler throws it under the bus. Indeed the generated JavaScript is fast and compact, but fast and compact javascript is generate for jade templates also (and probably other templates for the node platform, those can be 'browserified'. The overhead of translating the HTML markup to Jade markup is not that bug as the Jade is fairly simple.
As of the compilation always valid code with minification is produced by uglify.
I was hoping for some more advances when dealing with UI, for example loading the css, the template and the logic of widget on demand. Nothing like that, at least not at first glance was found in Closure. Seems we will continue handling the css manually and loading the modules with our JavaScript module implementation.
Before anyone gets this personally and start explaining the numerous advantages of Closure, let me tell you, I even went as far as reading "Closure: The definitive guide". I did not found the answer to our problem there. So it might be the greatest of them all, it still relies on coding style, which we do not have and there is no currently plan to port 100000 lines of code to another coding style so that closure compiler can handle it. Maybe one day when it can handle any code we will move on.
Conclusion: The main motivation behind this attempt with closure was the fact it makes maintainability much simpler. For example if we rely on Google to update the core and keep the API, we can assure the longevity of our code.Our code base grew enormous for the last year and we want to support only that, forgetting about browser inconsistencies, we would want to NOT back-port new versions of libraries, we do not like libraries that alter/augment native and host objects and we want either the namespace pattern or the module pattern. We want to be able to minify. Still we have not found all those in one project.
Our current approach is:
I have downloaded the source, the compiler and template utilities. The source is really well documented.
Unfortunately I have issues with the fact that the compiler understands only certain subset of the JavaScript language, which means that I as developer need to restrain my work to those limitations for the only purpose to be able to compile the code to a usable size once development is completed.
I have tried to compile some of code as it is - it mostly did not work:
resulted in:if (!window.console.group) {...}
which is actually pointless. To avoid this I have to write:if (!window.console.a){..}
which is then compiler toif(!window.console['group']){..}
if(!window.console.group){...}
I find this exercise to be tedious for the developer; if a statement is valid JavaScript compilation should NOT break it.
I likes the name spaces idea nice, however the module pattern is equally nice to me.
Now about the templates. Our design guys make the prototypes in plain html. It seem fairly easy for a developer to translate this in closure template. However the fact that I need to use it with closure compiler throws it under the bus. Indeed the generated JavaScript is fast and compact, but fast and compact javascript is generate for jade templates also (and probably other templates for the node platform, those can be 'browserified'. The overhead of translating the HTML markup to Jade markup is not that bug as the Jade is fairly simple.
As of the compilation always valid code with minification is produced by uglify.
I was hoping for some more advances when dealing with UI, for example loading the css, the template and the logic of widget on demand. Nothing like that, at least not at first glance was found in Closure. Seems we will continue handling the css manually and loading the modules with our JavaScript module implementation.
Before anyone gets this personally and start explaining the numerous advantages of Closure, let me tell you, I even went as far as reading "Closure: The definitive guide". I did not found the answer to our problem there. So it might be the greatest of them all, it still relies on coding style, which we do not have and there is no currently plan to port 100000 lines of code to another coding style so that closure compiler can handle it. Maybe one day when it can handle any code we will move on.
Conclusion: The main motivation behind this attempt with closure was the fact it makes maintainability much simpler. For example if we rely on Google to update the core and keep the API, we can assure the longevity of our code.Our code base grew enormous for the last year and we want to support only that, forgetting about browser inconsistencies, we would want to NOT back-port new versions of libraries, we do not like libraries that alter/augment native and host objects and we want either the namespace pattern or the module pattern. We want to be able to minify. Still we have not found all those in one project.
Our current approach is:
- requirejs for module loading
- jade for templating
- css for styling - no processing
- simple build process that minifies all scripts and then runs the requirejs optimizer. We minify all scripts because most of them are dynamically loaded and the optimizer cannot see them.
- documentation is built by an in-house developed script reading the source (comment based as with YUIdoc, however much simpler).
- development environments are created with scripts that produces the base of the library, the project structures and a test server with local and remote debug server that compiles the templates on the fly.
- deployment is created with script and is complemented by a build from the development
- versioning is done with git flow
Абонамент за:
Публикации (Atom)