1,168 karma · joined June 16, 2010
Asking developers to remember the "gotcha" of 600 characters is not really viable. Instead, if this is important to you, consider the addition of minification or comment stripping to your production deployment process. Minification will also make the variable names and syntax use shorter, saving you further precious characters.
Learn the problem, but automate the solution.
Although you could grant notification access to an app and then it could become a bad actor, I expect on the web you will be able to be far more choosy about granting access than with an app.
I believe Android is doing something to bring in granular permissions, there was discussion at Google I/O this year.
For anything larger than a simple widget, I highly doubt you will see a move to use native web components for a long time. There are application architecture issues they have not even begun to tackle.
The jump to Ember.js 2.0 involves API changes, but I see no reason why the majority of application will not move forward.
Your experience sounds very painful, but many Ember applications, even ones that are over two years old, have already made it onto 2.0. That is not meant to trivialize your pains, but just to challenge the idea that we're leaving people behind.
Ember's 2.0 strategy is specifically designed to ensure as many people get to 2.x as possible. That is our goal. I'm rather proud of the number of mature, long-living codebases build with Ember that continue to progress with us.
> I'm just not sure what you are supposed to do if you want to build a multi-year project with modern frameworks in 2015. My current suggestion is that we don't
That is an option. The web, and single-page applications, offer unique advantages but like any platform also come with limitations. Companies like Yahoo, LinkedIn, Zendesk, Twitch, Bustle, and many others have placed big bets on this architecture though, and use it successfully.
bower install --save ember#2.0.0
bower install --save ember-data#2.0.0-beta.1
You can use Ember 2.0 with Ember CLI 1.13.x, just upgrade the dependency:
bower install --save ember#2.0.0
bower install --save ember-data#2.0.0-beta.1
* 155K of vendor JS (Ember, jQuery, addons)
* 76K of app JS
* 26K jQuery
* 6K raven JS
* 127K analytics JS
* 300K main layout JS
* 274K homepage app JS
* + stripe
Ember gives you a big bang for your buck with that 108K (a minified, gzipped 2.0). In practice not many people find this to be the main performance hurdle in their apps, but regardless we're working toward smaller payloads (something we call "svelte builds") and better initial execution performance (https://github.com/emberjs/ember.js/pull/11576).
Personally I would love to see the decoupling of TypeScript's type checker from its transpiler. The ability to use TS with Babel, or Flow with MS's transpiler, would be liberating and spur further innovation.
exactly :-)
* https://github.com/angular/angular.js/blob/v1.4.0/CHANGELOG....
We've started using it for inline templates in tests, but it should work just great with inline templates for components.
The pods convention you described definitely helps though.
This may be true for a codebase of trivial size. With a sizable codebase and many build steps (defeaturefy, babel, es6 modules, es3recast, jshint, jscs) you quickly see grunt and gulp fall flat.
Gulp and Grunt absolutely have a simpler API for blindly chaining tasks. And they have the ability (as task runners) to define multiple tasks and compose them.
Broccoli is tricky to learn. In Ember-CLI we go out of our way to make it invisible to devs who shouldn't need to care what tool is running the internals. For the internals however, it is definitely the correct tool.
Broccoli (https://github.com/broccolijs/broccoli), the build tool written by Jo Liss and supported by the Ember community, is truly an asset pipeline tool. It is concerned with transformations to filesystems and file contents, not tasks.
This makes Broccoli a faster and easier to use tool for implementing complex asset pipelines. The main domain object is "trees". A tree represents a directory hierarchy of files that will be regenerated on each build. Broccoli uses directories of symlinks in tmp/ to cache un-changed files from step to step, allowing it to restart a build at any depth and only process those files that change.
Some links you might enjoy on Broccoli:
* http://aexmachina.info/intro-to-broccoli/
* http://moduscreate.com/better-builds-begin-with-broccoli/
* http://hashrocket.com/blog/posts/broccoli-the-build-tool-not... (how Broccoli is used in Ember-CLI)
I can't speak to the weariness, but I can say that Broccoli is completely unlike Grunt, Gulp, or Yeoman and without it (or something like it) Ember-CLI and the next generation of build tools would be impossible. Broccoli has been in development since fall of 2013, and been used aggressively by Ember-CLI users since summer 2014. Give it a look!
The type check step should be available to run on its own. IMO they should not even worry about transpiling, just be a type checking engine.
The API for TS, last I used it, was extremely limited. It has always been viewed as a black box compiler by the authors- they need to expose more flexibility.
[edit] someone gave me my first down-vote for posting this. I'll stand by it.
This post misses the single most important tool for users (to help them try syntaxes), framework developers (to help them be more productive and consistent), and standards developers (to get feedback):
Transpilers.
Because much of ES5 is reflective (and ES6 even more so), it makes a great target for the translation of a new syntax into old syntax. This cycle of reflective-api-to-new-syntax is exactly what Yehuda is talking about in his post http://yehudakatz.com/2013/05/21/extend-the-web-forward/.
The impact of transpilers on ES module syntax, ES classes, and ES promises as been amazing. You can see the same thing happening with decorators/annotations today- real world use in TypeScript is influencing the discussions of TC39.
> The current support table of ECMAScript6 in browsers, parsers and compilers doesn’t look too encouraging. A lot is red and it is unknown in many cases if the makers of the products we rely on to run JavaScript will take the plunge.
I disagree in the strongest terms. ES6/E2015 is a huge amount of changes, and browsers have been driving the discussion and implementing items as they have stabilized.
I hope the stability and reliability of Ember's process, and its continuing improvement, will tempt you back.
> virtual DOM nodes for static areas of your markup
refers to React's virtual DOM implementation, not Ember's.
> I'm not familiar with Ember, but why not just store the constant value in a variable to solve this problem?
Ember is a complex framework. Suggesting a "solution" to challenges with an acknowledged lack of context, and adding "Simple", shows fairly poor attitude.
> I just stash large, static parts of the tree in variables and only rebuild vdom nodes for dynamic content
This sounds pretty much like what is already described in the PR.
Again, still confused, and still don't know what is being suggested.
For more context, here are a few quick slides from the EmberConf keynote:
http://f.cl.ly/items/0t031v2Z3y001V1N0F3N/Virtual%20DOM.pdf
They, and the PR, tell the whole story about what is happening in the dbmonster demo. We expect this work to land in Ember 1.13 stable!
Look, saying "client-side JS apps are damn fast" is a vague statement.
What we are talking about here is the architecture of a client-side application in any language. If you can ship application code to a local runtime, then that application code will always be able to respond to user interaction faster than fetching the results of a UI interaction (like a click) from partway across the globe.
The benefits of Client-side JavaScript applications do not come directly from JavaScript. They come from the architecture you can build when treating the Browser as a runtime for applications.
Progressive enhancement (beyond very small apps) is a challenge to maintain, since UI state needs to be shared between a server runtime and client runtime. I don't think there is disagreement that a pure server-rendered app or a pure client-rendered application would be simpler.
And your comments about shitty execution of web pages and apps could apply to any shitty app. They have nothing to do with client-side JavaScript applications. I expect a better argument than "I once saw a webpage that sucked".
"A megalopolis (sometimes improperly called a megapolis) or megaregion is typically defined as a chain of roughly adjacent metropolitan areas. The term was used by Patrick Geddes in his 1915 book Cities in Evolution,[1] by Oswald Spengler in his 1918 book, The Decline of the West, and Lewis Mumford in his 1938 book, The Culture of Cities, which described it as the first stage in urban overdevelopment and social decline."
vs megacity: http://en.wikipedia.org/wiki/Megacity
"A megacity is usually defined as a metropolitan area with a total population in excess of ten million people.[1] A megacity can be a single metropolitan area or two or more metropolitan areas that converge. The terms conurbation, metropolis and metroplex are also applied to the latter."
NYC alone is a megacity. The US northeast is a megalopolis.
Nearly every JavaScript ecosystem has a class pattern. Ember, Angular, YUI, React, MooTools etc. All of them are incompatible.
A spec gives us a common target to iterate toward, even if we need to get there via transpilers. Just like standardizing on Promises means I can consume jQuery's ajax method without learning a new callback syntax, ES6 classes will mean I don't need to learn a new API for extending a parent class in every framework.
The Ember community has had amazing success adopting ES6 modules despite there being no browser support at all. I expect any framework would have a similar success story with classes.
The implication in this post is that frameworks are standing still. That browsers have evolved and frameworks are built based on some past version of browsers that no longer exists.
In reality frameworks, browsers, and web standards are coupled together in an important triangle that creates the progress Joe calls out.
Frameworks iterate at an incredible pace compared to standards and browsers. The multitude of frameworks and libraries implementing the component pattern directly influence the spec. Members of W3C TAG and TC39 take the lessons learned from JavaScript development and fold it back into specs.
A great example is promises. This is a standard JS pattern, and now native feature, that began life as a library, became several libraries, then an independent spec, then finally a formal ES6 spec (domenic can correct me if I have the history wrong). When we talk about Move the Web Forward this is what we mean: http://movethewebforward.org/. Frameworks represent the shared and negotiated best practices of a development community- from this we can formalize solutions into specs.
To make a second point: Developing for the web means developing for a spectrum of platforms. A framework like Ember (which I work on) provides you known support for a variety of platforms. I don't need to consider if 5 different libraries all have fixed the ARM optimizations errors on iOS8. I can know all the features in Ember have it fixed. In fact I don't even need to think about the error, most likely.
A third and final point: Of course frameworks don't just influence browser features. The conversation is two-way. Unlike a simple scratch-an-itch library, framework authors are constantly looking foward and thinking about how they can better align with upcoming features. Ember has iterated on its Set, Map, and promise APIs to make them match the specs. Sometimes as we align with a feature we discover unexpected architecture problems with the spec (Object.observe, web components) and push the feedback upstream. Sometimes a spec helps us solidify an un-spec'd solution, and we need to expend effort trying to move apps to that new pattern (ES6 classes).
Most developers who buy into SPA architecture and build complex JavaScript applications understand the value of a framework. They are not panaceas (and setting them up as one is making them a straw man), but they absolutely play a very important part in the JavaScript and web ecosystem.
Which is more than I can say about this post's FUD ("Remember all those MochiKit widgets you wrote? Yeah, how much good are they doing you now that you've migrated to Ember, or Angular?" they work just fine thanks) and call to limit your ambitions for a great client-side app.
The number of challenges a framework should help a developer manage for a long-lived client-side JavaScript application is not trivial. It is absolutely true that Ember is heavier than other frameworks, but it has a specific style of development in mind. If someone chooses to build their app with an alternative, they often end up with a similar amount of code in other dependencies and application code.
And though we aren't there yet, we're working on ideas for modular loading of application code (via the pods patterns) and of Ember itself via tree shaking. This latter strategy leverages the fact that Ember's code and much app code is written in ES6, and thus we can identify and drop un-referenced code.
The style of development CLI introduces makes you incredibly productive. A comparison of Ember without discussing CLI is missing an essential ingredient.
* Most-starred projects mean these are all successful projects. Much software is not successful.
* A successful project means there are likely more-experienced-than-average engineers coding.
* Most-starred projects will be older, more stable code-bases than most software.
* Open Source development is a small slice of software development.
* Github is a sub-set of Open Source development.
And I expect there are a myriad of holes to poke elsewhere. In general I distrust any research that surveys GitHub and tries to make claims about software development in general. It is lazy.
We've worked very hard to make HTLMBars an incremental release, and not a Big Bang rewrite. Partially because of this, it has taken longer to ship than was planned. However I'm personally very happy about how smoothly the transition is going thus far, and if you are a user of Ember.js I think you should feel the same way. :-D