Because it's a slow, broken reimplementation of things which Angular already does better and which only work well in any case when you're on a blazing-fast low-latency Internet connection, or better yet browsing localhost -- did I mention those times I posted earlier were on desktop? I shudder to think what'd happen if I tried loading it on my phone.
And it also appears to be implemented entirely in a single 1300-line-long Javascript file, which, okay, I guess? There are no tests -- yes, there are examples in a directory called "tests", but there are no tests, which is to say there's no way to get any confidence that modifications in that 1300-line Javascript blob haven't produced regressions or new bugs.
Presumably the author has learned something in the process of writing it, although I can't imagine what that may be. I don't know why he'd spend his time on this, though; from the looks of his Github account, he's also written an in-browser Pokemon game engine which looks pretty cool, so I don't know what value he sees in hacking up a half-baked me-too web framework.
You gotta love the Orwellian naming on this one. "Ember FastBoot" meaning Ember-we've-been-selling-you-very-slow-booting-for-years-and-now-we're-hoping-to-mitigate-it-slightly-but-it's-still-vaporware.
Meanwhile, the commonsense approach has always been faster and simpler than this model: Use a small JS framework, not a bloated one, and only load the minimal UI and data set that you need to render the initial page at first. Load the rest later. This includes bootstrapping — remembering to put all the data you need to render the page inline as a JSON object in the HTML.
This can often result in less data sent over the wire than a large HTML page with tons of repeated DOM elements. It's also far easier to cache appropriately.
I don't want to get into a big discussion on small libraries vs. big frameworks (your use of the word "bloat" gives away your position here ;).
I would ask readers of this discussion to visit any of the web applications they use on a daily basis, open the developer tools, and look at the size of the JavaScript payload. Whatever libraries or frameworks they're using, the payload size is almost always several hundred kilobytes.
I'd argue that using small libraries is a noble goal, but in practice, you just need several hundred KB of JavaScript to build modern apps. If we're honest with ourselves about it, we can try to do a good job of managing it from the beginning. Otherwise you just end up with an ad hoc mess.
The other point I tried to make here is that, yes, of course, you can do all of this by hand. But in practice, most teams are so under the gun to ship features that they don't do it. If we can make great boot performance as easy as installing an npm package, why not?
Lastly, regarding the vaporware claim: we've got a very alpha version up on GitHub already. I invite Ember users to play around with it and give us feedback: https://github.com/tildeio/ember-cli-fastboot.
I'd like to stand up and be counted as saying that both
1. Ember absolutely isn't to my taste and I've successfully avoided it so far and intend to continue doing so in future
2. The work you're doing is really cool and I'm looking forward to seeing it completed, both for the benefit of my friends with different tastes who're happily using ember and for the benefit of everybody else in that it provides a worked example of an awesome idea.
(and people who dislike it just because they dislike ember might, possibly, need to remember that trailblazing is important for new ideas)
Give him a break, this is how projects - and especially personal projects - develop. You find a cool idea you want to explore on, the end product might be something totally different then what you started with.
Yes, but you don't typically replace the same domain with two totally different services. You create 2 new domains. I would never pay someone for a service when they've repeatedly shown that they're willing to throw out the system people have started depending on and replace it with something radically different. Not only can I not trust the stuff to stay around, I can't trust the developer to have enough of an attention span to care about the old stuff enough to even just leave it alone to keep working in maintenance mode.
A few years ago, Dart was Google’s first foray into web programming languages. Built as a “20 percent” project, Dart developers started conversations, and built web applications that had never existed before. Dart helped shape the future of the browser before people really knew what “Beyond JavaScript” was.
Over the past decade, TypeScript, CoffeeScript, ClojureScript and ES7 have taken off, with communities springing up in every corner of the world. Because the growth of these communities has outpaced Dart's growth, we've decided to bid Dart farewell (or, "adiós"). We'll be focusing our energy and resources on making these other development platforms as amazing as possible for everyone who uses them.
We will shut down Dart within the next 3 months. Until then, there will be no impact on current Dart users, to give the programming community time to manage the transition. People can transpile their applications into JavaScript using Google Takeout (available until next year). Starting today, it will not be possible download or patch updates to existing copies of the Dart compiler.
Dart, the language, may be going away, but all of those incredible web apps that Dart users have created will live on. We are preserving an archive of the best of the bunch, which will be available online during this transitional period. If you don't want your app or name to be included in the community archive, you can remove Dart permanently from your Google account by visiting your YouTube preferences page, and clicking on "Advanced Settings". Please visit our Help Center for further details.
It's been a great few years, and we apologize to those still actively using the language. We hope people will find other programming communities to spark more projections and build even more amazing applications for the next decade and beyond.
---
(This is just in good fun ;) Likely? No. Possible? Sure seems to be.)
Nay, the big companies that care a lot about these languages own them through and through. Look at Adobe's attempt at converging ActionScript and JavaScript in the abandoned ECMAScript 4th edition:
I think Microsoft was key in killing this. With respect to Dart, Google will have the ability to control Dart's future as long as it wants to and if it somehow lost control of the ability to shape the spec it will just do its own thing anyway, just like they have with Blink and standards (directoryReader comes to mind).
You have it backwards with ActionScript. ActionScript 2.0 came out of the initial years of work of ES4, and ActionScript 3.0 came out after yet more work from TC39. Both were designed to directly take what came out of the ES4 process and fold it into ActionScript (so much so that you'll recall that originally Mozilla was going to use Adobe's Tamarin ActionScript JIT compiler as a starting point for their Firefox ES4 engine[1]).
Adobe was a big proponent of many of the big features in ES4, but so were Mozilla and others on the committee. Adobe was hoping that the work in AS2 (and eventually AS3) would anticipate what was coming and that JavaScript developers would be able to easily move back and forth between the web and Flash/Flex/whatever else they had planned at the time.
Of course influence went the other way as well: Adobe's experience with the needs of ActionScript 1.0 developers were informing what was focused on in designing ES4...but that's exactly why you bring people into committees, to help guide what comes out of them.
This is a personal opinion, but I was honestly surprised how nicely the standardization process is going.
I was part of the team that started Dart (right place at the right time :), and helped design the language. Obviously we have some emotional binding to the language and would like to drive it into the right direction, but most of us are perfectly happy with others taking the relay.
We still have some ideas and proposals that we have worked on and that we want to champion, but all in all I just hope that the TC52 members will do a good job.
Yeah, but I think the point is that ECMA standardization does not confer longevity. If Google abandons Dart, the language is no more alive or dead because it's been standardized by ECMA. The risk to Dart developers is effectively the same.
It's a little bit sad that Google pays people to have their entire job be to astroturf for Dart with blog posts like this one.
Being a "developer advocate" is one thing, writing official documentation, answering questions on forums, whatever — but "I ported a JavaScript app to Dart. Here's what I learned." Seriously? More like "I'm on the Dart Team. I ported a JavaScript app to Dart because it's my job."
Open source shouldn't need to be juiced with paid posts. If you scroll down to the "Lessons learned" section at the end, it really strikes to the core of what being disingenuous is all about.
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.
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.
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.
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.
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.
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.
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.
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.
> "Absolutely right. Ember promises—and, we think, delivers—tremendous value."
No matter how often you say it, doesn't make it true. At a certain point, we have to stop just believing the hype at face value, and start actually evaluating what the piece of software really does with a critical perspective.
Aren't the same guys who are telling you that Ember is simple and easy to use and high-performance and well-designed and ambitious and removes boilerplate and cures cancer and kisses babies ... the same guys who were saying the same things about SproutCore two years ago?
Isn't the data layer still totally unfinished? Didn't a lot of folks just get burned by wildly changing router APIs? Isn't it obvious from what few public production apps there are (after 2+ years) that the results end up sub-par, glitchy and wonky? Why would you want to spend time banging your head against the limitations and poor design choices of an over-marketed experimental framework?
Let them actually finish the damn thing first, then let's talk about "getting started" with it.
> Didn't a lot of folks just get burned by wildly changing router APIs?
"To keep things in perspective, we froze the Ember 1.0 API a mere month ago, when we released the first 1.0 RC. Before that, we were focused on iterating the API based on feedback we received from our early adopters. We believe that our willingness to change the API allowed us to build a better product than our competitors that locked in their first attempts."
> Let them actually finish the damn thing first, then let's talk about "getting started" with it
If you'd actually read the linked post you'd see that the framework recently became effectively finished from an API standpoint. Most of the work post-RC is going to be bug fixes and documentation.
Sure, there are still things to improve in Ember and there isn't a 1.0 release yet. But this is similar to how Backbone and Batman.js (which we also tried) had some quirks in their early days.
Despite some of the drawbacks, we are happy with ember and are using it in production for both a web client and mobile app.
Does everything work flawlessly? No. Has it been useful to us and do we like it? Yes, certainly! Should you use it? Maybe, less adventurous people should probably wait until 1.0.
Right on. At a certain point, you have to stop just believing the hype at face value, and start actually evaluating what the piece of software really does with a critical perspective.
Aren't the same guys who are telling you that Ember is simple and easy to use and high-performance and well-designed and ambitious and removes boilerplate and cures cancer and kisses babies ... the same guys who were saying the same things about SproutCore two years ago?
Isn't the data layer still totally unfinished? Didn't a lot of folks just get burned by wildly changing router APIs? Isn't it obvious from what few public production apps there are (after 2+ years) that the results end up sub-par, glitchy and wonky? Why would you want to spend time futzing around with an over-marketed research project?
Let them actually finish the project first, then let's talk about "getting started" with it.
"There are over 42 million American adults, 20 percent of whom hold high school diplomas, who cannot read, as well as the 50 million who read at a fourth- or fifth-grade level. Nearly a third of the nation’s population is illiterate or barely literate. And their numbers are growing by an estimated 2 million a year. But even those who are supposedly literate retreat in huge numbers into this image-based existence. A third of high school graduates, along with 42 percent of college graduates, never read a book after they finish school. Eighty percent of the families in the United States last year did not buy a book."
However, if you read it you'll notice that A) Almost none of the claims are sourced and B) many of them contradict each other C) They completely contradict the data from the government's survey on citizen's participation in literature and the arts: http://www.nea.gov/pub/readingatrisk.pdf.
Thus, leading me to believe that most of the 'statistics' are in fact entirely apocryphal to begin with.
But he's actually not knowledgeable or good at what he does -- if you view his Github page, you'll see that his projects are 100-line thefts or wrappers around other people's work.
He's been a major drain/drag on the Node.js community, and makes the IRC channel a toxic wasteland for a good part of the day.
Say what you will about his interactions with people, but "not knowledgeable or good at what he does" is an unfair characterization.
I find his hook.io project (http://hook.io/about.html) particularly interesting, and the BDD testing app he was building for Node Knockout has a lot of potential as well.
Marak is definitely unpleasant for some. However, he regularly contributes code to the community that people consider useful. For example among many high profile developers, Tim Caswell, a cornerstone of the Node.js community voted 5/5 for utility on the Nodejitsu Node Knockout entry. You're acting like you're a part of the Node.js community? If you or anyone is going to be so negative, they should at least have one or more nodejs projects that have been publicly noted as useful or relevant. So ironically, you're quite a troll.
