The header on the blog says "Dart DevRel @ Google", and the sidebar says "Seth is a web engineer and Chrome Developer Advocate". I apologize it wasn't obvious enough. I agree, it should be obvious that I work at Google.

This particular project was done on my own time, a little bit while at work, and a lot at nights and weekends.

All I heard it from your post is a lot vitriol and hatred.

I don't know who Seth Ladd is. I looked at the page and it skipped over his title and went straight to the text.

I don't care if Google paid him, or if the works for Google, or if he wrote because he was forced to at gunpoint by Colombian mafia. It doesn't matter. It is a good article and I enjoyed reading it. It is very well done, it shows how the IDE works, explains some concepts about Dart.

I can see maybe if you had direct proof that he was forced to do this against his will by Google, ok we could maybe discuss the implications of it. That still wouldn't make that a bad article.

>proof that he was forced to do this against his will by Google

strawman alert.

That's not a strawman. It would be a strawman if the GP characterized the original comment as suggesting that, but it's not. It's saying that even this facetiously extreme example still would not disqualify the content of the post from being useful/interesting/whatever.

Saying X isn't worth discussing but something worse than X maybe would be isn't a strawman.

Your definition of astroturfing doesn't seem to match mine. Seth states several times on his blog that he works on Dart developer relations at Google. Blogging about Dart is part of his job, and in no way is he being deceiving about that fact.

I on the other hand am simply an engineer on the Dart team, as I must disclaim in this context.

Where does he mention that other than the sidebar? I completely missed the fact that he works for Google while reading the article since it's never mentioned in the body of the article itself, and the article is written as if he's completely new to Dart and trying it out for fun. If he's not trying to present that image, then it's a really awful writing style.

The very top of the page:

Seth Ladd's Blog

Dart DevRel @ Google, web engineer, author, conference organizer.

Do you imply a conflict of interest? If you do, please state it explicitly. Your criticism as it stands doesn't add to the discussion and one could say that your writing style is really awful, too.

Sidebar is not an unusual place to place author bio and it is definitely enough for me.

Okay, I'll state it explicitly: I feel that the article is actively deceptive about the background of the author, which makes me distrust the content of the article as well. The sidebar with his background is not visible on the first page of the content, so I would have had to interrupt reading the article to read it.

I say that it is a bad writing style because I am assuming good faith. I assume that the positioning of his bio is merely unfortunate and not specifically chosen to reduce the number of people who read it, and that the article is not actually trying to deceive me about the author. I think it is obvious that coming across as astroturfing to some subset of your readers when that isn't what you're trying to do is a bad thing.

> I assume that the positioning of his bio is merely unfortunate and not specifically chosen to reduce the number of people who read it, and that the article is not actually trying to deceive me about the author

Oh please. Most blog authors barely manage to fill out an About page, let alone a sidebar and a big subheading at the top of the page that says who their employer is. If you're going to claim to be "assuming good faith", how about actually doing so?

The header of the layout says "Dart DevRel @ Google,", as you mention the sidebar has a bio (which I will move up), and I just added a note to the beginning of the article. Thank you for the feedback, and thanks for reading.

I agree. This is getting your panties in a twist because a writer hasn't spelt out his putative conflict of interest in a way that conforms to your norms, when it is certainly plain enough for many readers (I had no problem at all figuring it out and wasn't at all offended by it).

Please don't insult his writing style. That's an ad hominem attack and it is the only thing in this conversation that doesn't belong here. You don't have to agree with his concerns, but please cut that out.

What irks me is that the things he picks on have long since been solved. So the fact that he works at Google tells me that he knows better and is being intentionally deceitful. He picked a project that doesn't use any modern (by modern I mean in the last 5 years) practices like module loaders. It's fine to say that JavaScript doesn't have this by default, but that's not what he did here. He pretended to think that it's hard to know what the entry point file is.

I hope I didn't "pick on" anything. My attempt was to do a before/after and then list out what I, personally, learned. I thought I did say "JavaScript doesn't have some of these features like modules or promises by default" at the bottom of the article.

I picked a project that was written this year, and because it used Web Audio API and looked pretty. I was inspired by the original app, and I wanted to see what a Dart version would look like.

To be clear, I did find it hard to know where the entry point was. I literally opened each file, in order, to see where the program started. I find it hard to believe that other seasoned developers could look at the file names and instantly know exactly, to which line, where the app started.

The problem is that you picked a project that doesn't reflect current (again, defining current as in the past 5 years at least) development practices. Any decent JS project these days is using a modular loader and has a bower.json that has a 'main' property telling you the entry point.

I'm sure someone could look at early Dart projects and find things unpleasant about them compared to today.

This makes me curious... what's the adoption of module loader, bower, etc, today for new small-ish apps. That is, what is the archetype JS project look like? Is there such a thing?

So perhaps the question is, why didn't the original app use bower.json, module loader, etc. Was it that the startup cost is too high? Or was the app too "small" to worry about that?

What do we need to do to help all web devs to use all the awesome that does exist "out there"? It's all "built in" with Dart, what can we do for our JS devs?

The startup costs to using a module loader are the same startup costs to using Dart. That's the point I'm making, Dart is an alternative to JS tools, but it's still a choice that has to be explicitly made. You don't get Dart for free in any browser but Dartium.

Well that's a plain "ad hominem" argument right there sir. I found the post interesting and useful, and the fact that the author works for Google or Apple or Microsoft or Walmart doesn't affect it in the slightest.

He presents the post as if he was learning something new, when he's really a seasoned Dart expert which has access to resources most of us don't have. Then there's the background that he could cherry pick his project to make the outcome look good, and doing so is in fact his job.

A misleading presentation potentially leading people to false conclusions is worth calling out.

I picked the Music DNA app not because it makes Dart look good, but because I never really used Web Audio API before and the app looked good. If I really wanted to cherry pick, I wouldn't have picked an app that uses a third-party JS lib. The JS interop in Dart is sufficient, and it works, but obviously is not as seamless as it is in JavaScript. JS interop in JS is better than it is in Dart, and I didn't hide that.

I welcome anyone to pick a random JavaScript app, port it to Dart, and write up their experience. I'm sure the community would love to learn more about that experience, especially me.

I don't have access to anything you don't. Dart is open source. Heck, in my job, I don't even write Dart code every day. :)

I even reported issues about the original Music DNA app (bugs, code quality) to the original author. I helped make the original Music DNA app better.

Can you help me identify the false conclusions?

He's not saying that you have false conclusions. He's saying that you have false pretenses. It appears as though you are new to the language, porting over some javascript code.

The truth is, you are not new to Dart at all. I believe he feels duped by you.

My personal problems with your post is that you go far too deep into the guts of how Dart works. 90% of your blog post is the internals of Dart as if you are writing the first few chapters of a Dart book. I would personally prefer it if you focused more on the specifics of the library you were porting over. That's what feels illegitimate to me when I read this article.

Thank you for calm and reasoned explanation. It's easy to address. Aaaaand, done, I added a little note at the top.

re: your personal feedback, thanks very much. The Music DNA app is pretty simple, there's not a lot of specific business logic there. It is a good example of Web Audio API, async, code organization, drag and drop. Are you saying you'd like a more detailed explanation of those APIs? I guess I assumed that web developers would read the post.

Open to ideas.

Honestly, I tried to work with Dart. I hit a few stumbling blocks during the tutorials. One difficulty was javascript interop. I also remember the drag and drop tutorials not working when I downloaded the code from github. It is really good that you covered those topics. Javascript interop in particular was a good choice. I can imagine a lot of developers may want to dip their feet in without migrating an entire project into Dart.

I think the post was a good writeup. I think that there is a void in Dart tutorials in general. It is incredibly easy to set up a standard Dart project. The idea of Futures are incredibly easy to follow. The code itself is very direct and easy to follow. The part that I always end up turning back on is when I try to integrate a real life project with Dart. I looked up the Angular port and found an incomplete tutorial. It gives me the feeling that others have not navigated that road before me, which in turn makes me wary to continue.

Perhaps a few blog posts that go heavy into the business logic of whatever app you decide to make would be more comforting. As a person who is on the fence, it would give me great comfort to see all the nuances of common CRUD apps blogged about. If you look at tutorials for Angular in javascript and are able to match those in Dart, I'll switch over.

No, it's not. It's not an argument of any sort, and doesn't make any claims about the quality of the article.

edit: so "ad hominem" is just going to mean "disapproval" from now on, and not implying that someone's argument is incorrect because of who they are?

This was an simple assertion about clear disclosure, not a logical fallacy.

Couldn't it also be the case that he's not doing it because he's paid to, but because he loves Dart? People at Google can move around between projects, and generally, if you're working on a particular project, it's not because you are disinterested in it and simply collecting a paycheck, but you're enthusiastic about it.

This is especially true of developer advocates. No one's whining about all the HTML5 advocacy that Google does on sites like html5rocks.com, do you think the developers that write those articles merely do so because orders came down from above, or because they chose things they thought were exciting or that they were enthusiastic about.

I do not work at Google and yes, I love Dart. By following Seth's work for two years and a half, it is obvious to me that he loves Dart.

Why do I love Dart? As a developer and a university professor, for the first time in my long career, I can do the following with Dart:

I can use Dart both on the client and on the server; with Dart, I can apply both object-oriented and functional way of programming.

I can develop in Dart and deploy applications in JavaScript.

I can be a productive developer with many Dart tools and libraries, and get a very good performance in either Dart applications or their JavaScript versions.

I can start developing a prototype without data types and introduce them when I need to convert the prototype to a deployable application.

I can use Dart for both synchronous and asynchronous programming.

I can use many publicly available packages and reuse their libraries.

I can be a web engineer on the client-side and a software engineer on the server-side, with the same language and many reusable libraries.

I've never minded harsh HN criticism b/c it's good at exposing design/develop weaknesses, but picking on presentation style while completely ignoring the technical aspects of the article is just bikeshedding. We all know he's a Dev Advocate. If you might have some great criticism on js/Dart, that would be very helpful. He could be wrong, so chime in.

I don't get your point. If a guy is going to advocate for anything presumably it is better if the guy has some practical experience and what is wrong with him sharing that experience? Do you honestly imagine that anyone reading this piece was in any way deceived or confused by his role at Google? It's not like he hid it.

So what?

I don't care who writes the article, all that matters is whether the content of the article is interesting.

For this particular article, I think the answer is "Very", so thanks to the author.

"I replaced all my Python code with Go. Here's what I learned." Several times a week. Why is that OK and this is not?