ganarajpr

I was not aware of Concurix . Thank you for the link. I am aware of such monitoring tools though. They seem to be aimed at a different audience though ( monitoring I guess is the key word here ). I was wondering more about the day to day developer who is trying to acquaint himself with a new codebase ? Wondering if a visually shown callgraph / data flow etc would be much easier to digest than a wall of text ( the actual code base )?

Just wondering if people would be interested in a call back / data flow visualization for their entire application ? Would it be helpful ? Are there people looking for something like that ?

+1.

I hate this part about Mozilla and Apple. I dont have qualms about javascript. It has its good parts and as a full time javascript contractor I earn my living with javascript. But... I dont really want the next generation of developers to be stuck with whatever we have today. I am not in favor of "Here is what you get - do all your innovations inside this box" mentality. Yes, there is scope for improving javascript or ECMAscript but there are limits to this. As Peter Thiel says in his book - this is incremental-ism. This will never produce 0 to 1. In order to produce something like that people should be allowed to innovate - even if initially they have to do stuff like this AtScript or Dart or TypeScript! Criticizing those attempts as "breaking the existing tool-chain" is as foolish as criticizing a spaceship because it does not make use of roads.

I would be interested in knowing where the RTTS library is ( source-code ).

FWIW, I believe they are using traceur-compiler. https://github.com/google/traceur-compiler

If you look at this page here https://github.com/google/traceur-compiler/wiki/LanguageFeat...

You can see annotations in the "experimental" features list.

You are probably pretty awesome at setting things up. I am not. I tried GDB, golang and windows as a combination and its an exercise in torture.

This is the highest and most important thing I want from go. A proper debugger that is not insanely hard to setup ( on any machine! ). Gives a complete stack trace and such info. I am not sure how people can live without a debugger in 2014. GDB is not the answer to this - for sure. There are soo many things that can be done ( tooling wise! ) and this one is , I personally think, the first things the golang guys need to do .

Atleast the fact that this was written and its currently at the top of Hacker news says that this pain exists. The author of the post is saying that no solution has been found yet. You should consider this a blessing in disguise and not get disheartened. There are perhaps atleast two things to take away from this.

1. The problem exists ( and is a genuine problem that quite a few people care about! ). 2. A good solution has not been found yet. ( also kind of good for you! ).

Apart from this, it also gives you a lot of information about the industry. Especially the discussions that are happening here. So, why dont you consider this a loooot of great feedback and go back to the drawing boards and go disrupt this industry ?

I am working on a platform that helps you to write unit tests for your application code. Unit testing is currently yet another code base that you have to maintain and change each time you change your main code base. There is surely value in it, but I believe that we dont extract extra value out of them than mere assertions.

http://www.dhi.io

If someone was using angular and wanted to use the native html5 drag and drop, I created a directive for it here https://github.com/ganarajpr/angular-dragdrop if you are interested.

There is documentation as well in here : http://ganarajpr.github.io/angular-dragdrop/

Having read the blog ( from top to end ) I kind of agree with some of the things that the author says. There are a few edge cases that we need to take care of if using native drag and drop. There is also the not-so-slight issue that it doesnt work on mobile browsers....

This is utter BS.

Riot's TodoMVC - 59 LOC html, 185 LOC js.

Angulars TodoMVC - 70 LOC html , 145 LOC js. ( I DINT even discount the extra lines used for comments and stuff - which angulars has quite a lot of ! ) . https://github.com/tastejs/todomvc/tree/gh-pages/architectur...

The other implementation is 71 html and 162 js. https://github.com/tastejs/todomvc/tree/gh-pages/architectur...

Stop claiming that your "framework" allows writing less loc.

There are sooo many useful constructs that all these frameworks provide. I generally abhor Backbone for its "minimalistic" approach. But looks like even jashkenas is taking issue to what you are doing here.

You are saying that / claiming that - me / we are soo damn good that we can do in <1KB what a whole bunch of developers have not been able to do in xKB where x is a larger number.

I am not sure if this will be of any help. But you could actually globally override $watch - without it feeling like a hack. Angular does provide a mechanism to do that. Since $rootScope is a service, you can have a decorator for it where you can override the $watch which will override the $watch for all scopes.

Angular Batarang overrides $watch too for instrumentation.

Consider this one more request for publishing your directives and changes :)

The point is why do you want to write things from scratch each time you start a new project? That is a huge waste of time and also a huge waste of resources ( money ? ) for whoever is paying for the project.

It uses the closure compiler. Not the closure library.

@Author : What you should do ?

Use Angular. Every single thing you mentioned there is covered. Except coffeescript, but thats unrelated anyway.

Whats covered ?

Async code : check. ( timeout flush )

Wrapper for XHR : check ($httpBackend ).

DOM abstraction : check ( No DOM Manipulation in controllers! )

fast feedback : check ( karma ) .

The point is - "All DOM manipulation belongs to a directive" but still it can be made application agnostic. What he is mentioning there is making it application agnostic - like for example not assuming in the directive that you have $scope.users on the $scope etc..

You are absolutely right. But this is a problem and the sooner we fix this ( is it possible? ) the better it will be for India ( or any other country for that matter with a similiar population ) .

There are a few things that I think requires serious change in India :

1. We need to develop a culture that supports, encourages and rewards innovation - which means we need to develop a startup culture that is akin to US. We should make it damn easy for people to start companies in India (Hopefully you are listening Mr.Modi and Mr. Manmohan Singh ). So far all I have heard is that its hard. With a labor force like ours we can surely go far ahead.

2. The second part ( and the part that is addressed by this blog post ) is training or bringing this large labor force to a level that is usable by the companies that are thus created. This is a much harder problem but perhaps there is a way this too can be disrupted and changed. Changing the mentality of people towards something is not really that easy. But considering how people flock towards all those Indian Idol, Saregama etc.. maybe something similar ( I dont know what that is ) might help.

Looking for something like this ?

http://blog.nebithi.com/backbone-and-angular-demystifying-th...

I do the same as you. Group by Module - which in my humble opinion is the real intention of the modules.

Oh between I do group by Type inside of a module.

I would be very curious to know how the code would be "further" reduced when you move from angular to meteor. Could you elaborate on this point? Are you talking about meteor (backend+frontend ) or just meteor-frontend reducing the code size?

This Sir, is a sound advice..

You stole the words in my mouth.. I am going to cry plagiarism ;)

This is amazing.. The greatest thing you have done ( I havent checked out the whole IDE yet ) is to reduce the whole step of setting things up down to 1 click.. The biggest gripe I had with Clojure / Cljs was the setup process.. I am not familiar with the java world and I hate setting things up before getting my hands dirty. This sir, does everything for me.

Just wow! and thank you.

The problem with javascript and the tooling related to it isnt something to do with the existence of great tools. Ofcourse, tools that are pretty mature and really good, as found for other languages dont exist for javascript ( like the tooling for java for ex ) but that doesnt mean there is nothing out there.

I use Intellij and I have noticed that I dont do any mistakes likes missing commas, accidental global declarations etc because my IDE ( intellij ) tells me about them. It infact corrects me when I make any such mistakes. The real problem is with people still using simple text editors to write javascript code because they dont think there is any advantage of using a full fledged IDE which does anything , because they think that there is nothing out there which actually helps.

If you try to reinvent the wheel, you will get another wheel. I think what Bret is talking about there is wondering about if we could create airplanes and spaceships perhaps!

So what is ractive.js's equivalent of $scope.$apply ? $scope.$apply is used for this specific purpose, to notify angular of any external changes.

Can some of the clojure and clojurescript gurus take some time to write beginner friendly, hand holding tutorials? I mean, I can see the power of these technologies but the very thought of climbing a learning curve AS WELL AS a getting started curve ( that too without any external help! ) is the single most important thing that turns people off.. especially me. My general complaint is with regard to how many tutorials and even books are out there on these topics! Countable, with the fingers in one hand perhaps!

A set of other tools that also do the same thing :

http://www.webflow.com/ https://jetstrap.com/ http://www.divshot.com/ http://html.adobe.com/edge/reflow/ https://www.easel.io

That is probably the wrong way to think about it. Its like saying "Well, we shouldnt be using motor cars because thats puts Horse carriages out of business". Or something to that effect.

We are moving towards a world where js is ubiquitous. Its everywhere..already. If web-crawlers dont support js completely ( looking at you google! ) then we should force them to (by creating more js based apps thats outside the crawlability of google ). If screen readers dont read js ( they should and thats why we have ARIA ), they will eventually. At the end of the day, as long as you are trying to adapt to them ( which is backward ) they will never move. Start moving swiftly and they will have to adapt to you.