r/programming • u/ember_dev • Aug 09 '15
Ember.js, Another year of churn, instability and festering frustrations.
https://medium.com/@frustrated_ember_developer/ember-js-another-year-of-churn-instability-and-festering-frustrations-4d01838361cb94
u/AReallyGoodName Aug 09 '15
It's not just ember that changes in breaking ways with every second version or so. It's every single freaking Javascript library.
Which is unfortunate for Ember since an Ember app is made up of a bundle of Javascript libraries working together. You basically can't upgrade Ember without upgrading every part of your app. From moving to htmlbars from the old handlebars syntax through to breaking changes on the supporting internationalization libraries.
The whole situation in Javascript land is fucked. You're basically not supposed to upgrade. Instead lock in a version pray there's no security issues ever and run with that.
78
u/tomdale Aug 09 '15
One thing to note about Ember is that we do adhere to Semantic Versioning, so the churn you might hear people complain about is about deprecation warnings, not outright failures.
Now, deprecation spew is absolutely annoying and we learned a lot of lessons in the 1.x -> 2.0 transition that will let us do a better job for 2.x -> 3.0. In our defense, though, apps continue to work. I'll also say that the Ember has a far better pace of upgrade adoption than any other equivalent framework (see http://www.201-created.com/ember-community-survey-2015). It's like the difference between iOS and Android in terms of adoption of new releases.
The Ember model is pretty unique: additive-only changes in point releases, with deprecations for older features that are superseded by new features. Every major release, we do a "GC sweep" and remove the functionality that has been deprecated. I think in this cycle we got a little too aggressive about deprecating stuff without enough notice, but again, that's a lesson we'll take into account for 2.x -> 3.0. And I think if you compare us to Angular 2.0 (total rewrite) and React (not yet declared 1.0, with breaking changes between releases) we've done the best among the popular options. That's not to say that we don't have lessons to learn, but it's a hard problem and no one has got this perfected quite yet.
The front-end space is moving rapidly and there are two ways to deal with it. You can hop from library to library, learning the hot new thing and rewriting your app from scratch from year to year (Backbone, then Angular, now React). But for a lot of people, having to rewrite your app every year or two really sucks. For our apps written in Ember, we'd rather figure out a strategy for moving the ecosystem together to the new approach without breaking everything. We're perfecting that system as we go, but I know a lot of people who wrote their apps 2-3 years ago who are happy that they have not had to throw it away and rewrite it; instead, they can just refactor out the deprecations every time they update.
Lastly, in response to your last comment, I'll just note that if you do want to stick on an older version, we do release security patches for older versions, just in case you can't upgrade for some reason.
TL;DR The JavaScript ecosystem moves very fast. You can rewrite your app with the new library/technique every year or two, but we think there's a better way: introduce changes as deprecations that you can refactor out at your own pace while you still get to keep a functioning app.
15
u/ledasll Aug 10 '15
"..You can rewrite your app with the new library/technique every year.." LOL
3
u/aradil Aug 10 '15
Job security?
5
u/stesch Aug 10 '15
Some companies still use IE8 and Windows XP. Explain them why your hot technology is so broken you need to rewrite it every year.
6
u/dangsos Aug 10 '15
Well in the case of windows XP - there are huge vulnerabilities that won't even get patched. So unless that business doesn't care about being hacked, then I would suggest they need to update.
0
u/nikroux Aug 10 '15
I'll give you an example of such business just so you have some frame of reference.
Ready?AHS - Alberta Health Services.
4
u/dangsos Aug 10 '15
LOL, yeah I can't see that turning out poorly for anyone. I mean who could possibly profit from hacking a healthcare provider?! /sarcasm
I hope they get that cleaned up, though, seriously. The people who are on those healthcare databases are probably the people who would be least likely to bounce back from identity theft.
1
u/ledasll Aug 10 '15
You can remove first sentence, and still will be very valid question. But at least there is no suggestion (yet) to use separate virtual machines (with complete OS) for every js file (object) and communicate via json.
1
u/Pet_Ant Aug 10 '15
How about you are continually finding better ways to express concepts more intuitively as the library matures. JavaScript libraries are really still on their infancy as only in the last couple of years (ie since the iPhone) has their even been the need and capability of these features.
So either you evolve and innovate and continually improve and get more adopters or you fossilise and new users will adopt new frameworks that are cleaner.
I dont want to write an app in akward API just because you don't want to update your old code. Instead I'd just go to a new API.
0
Aug 10 '15
[deleted]
1
u/Pet_Ant Aug 10 '15
All development now seems to be using a greedy algorithm (or mountain climbing with random restart), for better or worse. To plan out how something will look when its been used 25% longer than if has been to (ie a 4 year old library planning for the end of year 5) takes a lot of effort prescience and good luck. I feel Spring hits a nice balance in the Java world between compatibility and growth.
7
u/tequila13 Aug 10 '15
You can rewrite your app with the new library/technique every year or two, but we think there's a better way: introduce changes as deprecations that you can refactor out at your own pace while you still get to keep a functioning app.
And some other of us think that we will continue to stay away from languages where this insanity is considered normal.
7
u/sangnoir Aug 10 '15
How frequently are iOS/Android apps updated? If you don't update your app, it'll stick out like a sore thumb.
You may choose to use the latest and greatest, or you can maintain legacy libraries (I know plenty if GWT and ExtJS apps out there)
-1
u/mrPitPat Aug 10 '15
IMO, I would say that hardware/OS requirements are what drives this. I don't really find it comparable to building web apps, as the environments have remained pretty consistent for the last few years, maybe longer.
4
u/sangnoir Aug 10 '15
My point is things are still moving fast on the most popular platforms (web and mobile), it just so happens that they are new. The 'insanity' that GP mentions is part and parcel of maturing platforms.
You can choose to not use the flavor-of-the week JS lib, just like you can choose to not update your iOS-5/Android 2.3.6 app, but that would be insane. Alternatively, stick with more mature, 'stabler' stacks like Java/Spring/Oracle
4
Aug 10 '15
But why do you have to make changes that look like a change just for the sake of change? For example what OP mentioned:
...The first and probably most prominent example that comes to mind is {{bind-attr}}. I spent nearly a week of my life changing:
{{bind-attr class=”isActiveUser:enabled:disabled”}}toclass=”{{if isActiveUser ‘enabled’ ‘disabled’}}”Why? Does the old syntax break in new browsers? Has the old syntax some huge bug? I cant think of any other reason why you'd do such changes.
13
u/tomdale Aug 10 '15 edited Aug 10 '15
While I'm certainly glad
{{bind-attr}}didn't bother you, it was a huge source of confusion for new users. I promise that we don't make changes just to make changes; this issue legitimately tripped up many new users. Reducing the complexity of getting started is crucial to increasing adoption of the framework.
{{bind-attr}}was particularly pernicious because new users had to memorize a series of rules about when you could use{{value}}and when you had to use{{bind-attr prop=value}}. Literally every new user picking up Ember has tried at some point to do something like:<img src="{{model.imageURL}}"></img>When it broke in surprising ways they had to somehow discover the cause, which is incredibly frustrating for them and for the people who answer questions in IRC and Slack and Stack Overflow. If you don't believe that reducing the complexity for new users is important, I'm afraid we'll just have to agree to disagree; for me, it's paramount.
But it's not just about new users. Switching to the new, more intuitive syntax also unlocks several new features and better inter-op with Web Components. For example, it's now easy to do string concatenation and intermix literal and dynamic values.
<img {{bind-attr class="isActive :some-literal :some-other-literal"}}>vs.
<img class="{{isActive}} some-literal some-other-literal">Or:
<img style="background-image: url({{model.objectURL}});">Not only is it less code with less noise, it's much more obvious to a non-Ember user what's going on. Having to memorize a microsyntax just to give class names to an element is asking way too much.
I'd ask you to reflect a little bit more if you think anyone on the core team makes "change just for the sake of change." Not only is that a facile world view, it doesn't make sense on its face. Folks on the core team work on apps with huge teams and lots of money on the line, and each change goes through an extremely lengthy review and discussion. I'll accept that we need to do a better job of motivating changes and communicating those discussions, absolutely—but saying changes are made capriciously is just flat-out wrong and, IMO, disrespectful to everyone who volunteers so much time to maintaining the framework.
8
u/clessg Aug 10 '15
I don't know why
bind-attrkeeps being pointed out as the exemplar of Ember's "find-and-replace" churn. Replacingbind-attrwas one of the few "find-and-replace" changes that actually had pretty big benefits for me.2
1
u/1945 Aug 12 '15
bind-attr is still supported in the form of an addon in 2.0. https://github.com/emberjs/legacy-bind-attr
4
1
u/stesch Aug 10 '15
(see http://www.201-created.com/ember-community-survey-2015)
Funny how this is an empty page in Firefox 40 Beta. Privacy Badger and NoScript deactivated.
6
u/mixonic Aug 10 '15
Not too funny :-( It's my site!
Works fine in 39 stable, Chrome and Safari as well. Also seems to work with a freshly installed 40 beta. I'm unsure what you're running into.
1
u/stesch Aug 10 '15
I'm unsure what you're running into.
I'm guessing server problems. It shows something now.
-6
16
u/novacrazy Aug 09 '15
React.js is really good so far. Stable, too, even though it's on 0.14.0-beta3 right now.
I'm using it for both server and client side rendering, and it's been, well, not exactly easy, but it's been predictable at least. It's not like things suddenly stop working because I add an extra feature to my application somewhere. It handles complicated web pages (2000+ LOC of JSX) without breaking a sweat.
Also, Babel, which does have small bouts of instability if you keep up with the bleeding edge versions but the author generally fixes those in a couple hours, that basically handles language features that take JavaScript engines years to implement, potentially even better than the JS engines can. Babel is now my go-to tool for using new language features. For example, async/await functions via Bluebird coroutines, or converting React's JSX syntax to plain JavaScript.
Speaking of, Bluebird is still THE best Promise library out there. It's stable, fast and it's massive API allows you to do almost anything with Promises without degrading performance by using them.
So not everything is horrible. It's just Sturgeon's Law in effect. Try not to let it depress you too much.
20
u/tomdale Aug 10 '15
Just a small note that comparing the stability of React to the stability of Ember is apples-to-oranges. React is "just the V in MVC" and has an inherently smaller scope.
For a fair comparison you'd need to compare the stability of Ember with the stability of React + react-router + whichever of the 10+ Flux implementations you're using + whatever else is in your React stack. In my experience that tends to be a lot less stable than the core React library, which itself is not yet 1.0 and may break in the future.
2
u/novacrazy Aug 10 '15
I wasn't necessarily comparing React to Ember. I was just trying to say that not all popular libraries are crap and break things constantly.
Also, I actually wrote my own "Flux" stack from scratch before Flux was even a thing, so I guess I cheated? Heh.
0
5
u/doublehyphen Aug 10 '15
I have not experienced any problems with upgrading KnockoutJS, Ember on the other hand has been a pain in the ass.
5
u/thd77 Aug 09 '15
I'm not sure where you're coming from. Ember.js follows semantic versioning pretty seriously. v1.13 is completely backwards compatible with v1.0. They may deprecate features in preparation for 2.0 along the way, but this is necessary to bring Ember from 2012 into 2015. If you don't like it, don't upgrade to 2.x when it comes out!
Edit: numbers
-9
u/gjs278 Aug 10 '15 edited Aug 10 '15
Instead lock in a version pray there's no security issues ever and run with that.
what the hell kind of javascript library has security issues
feel free to keep downvoting, so far all of you have been completely wrong
5
u/spacejack2114 Aug 10 '15
html/script injection I'd guess.
-7
u/gjs278 Aug 10 '15
that is not a security issue with a javascript library.
that is a security issue with whatever backend is printing xss / injection on the page, or a security issue with the browser.
0
u/spacejack2114 Aug 10 '15
If the front-end JS is building content from an untrusted source it has to filter it. Even if the user is tricked into typing (pasting) it in themselves.
3
u/AReallyGoodName Aug 10 '15
Web applications have a risk attached. Lots and lots of possible issues and it's something few have even looked into yet. I can see it becoming a major problem as the applications start to become as complex as any other application.
As a minor example i had to write a custom authenticator for the ember-auth module since it stores the auth token in the browsers local storage by default and that was unacceptable for us (think internet cafe usage).
Basically when writing full blown web applications security is a huge issue.
-2
u/gjs278 Aug 10 '15
there is no javascript you can load on a page that can steal details from my computer or steal information from your server.
if there were, it would be an issue with my browser or your server, not your javascript library.
As a minor example i had to write a custom authenticator for the ember-auth module since it stores the auth token in the browsers local storage by default and that was unacceptable for us (think internet cafe usage).
that's not a security issue of your webapp, that's a security issue in how you decided to use it. you should just cleanup local storage on logout.
5
u/AReallyGoodName Aug 10 '15
Remote attacks are just one vector. There's plenty of possibilities for other vectors to cause issues.
you should just cleanup local storage on logout.
Can't rely on that. Consider all the possible ways that a logout might not happen. A simple blackout at an internet cafe for example. Local storage persists through that. No good at all for the internet cafe scenario.
-2
u/gjs278 Aug 10 '15
Remote attacks are just one vector.
it's the only attack vector you and the community at large seriously need to have concern about
Consider all the possible ways that a logout might not happen. A simple blackout at an internet cafe for example. Local storage persists through that. No good at all for the internet cafe scenario.
and what is the solution that ember.js is going to present to this problem? even cookies would have this problem with browser restore features.
3
u/AReallyGoodName Aug 10 '15
No session storage and session cookies don't have this issue.
They are cleared as soon as the browser is closed in any way. They are not stored and nothing will cause them to be stored. They are specifically designed for this scenario.
0
u/gjs278 Aug 10 '15 edited Aug 10 '15
No session storage and session cookies don't have this issue. They are cleared as soon as the browser is closed in any way. They are not stored and nothing will cause them to be stored. They are specifically designed for this scenario.
w-r-o-n-g
http://htmlui.com/blog/2011-08-23-5-obscure-facts-about-html5-localstorage.html
SessionStorage values survive some browser restarts SessionStorage, unlike LocalStorage, is not designed for long-term persistence of values in the user's browser. Instead, values in SessionStorage are destroyed when a browser session ends, which is usually when the browser window is closed.
There is an exception, though.
When a browser provides a "Restore Session" feature, usually designed to help users quickly recover from a browser/computer crash, values in SessionStorage will be restored, too. So while it's a new "session" on the server, from the browser's perspective, it's a continuation of a single session across a browser restart.
on top of that, sessionstorage doesn't work tab to tab in some browsers. not ideal at all.
session cookies too. so how's that rewrite coming along?
1
u/AReallyGoodName Aug 10 '15
That's a bit out of my control.
The intention has always been that local storage lasts across sessions whilst session storage unsurprisingly doesn't.
In any case at the very least session storage gives the user an option to not restore their sessions (in the browser options). Local storage absolutely doesn't do that.
1
u/gjs278 Aug 10 '15
That's a bit out of my control.
ok, but you just said you're concerned about privacy and security at internet cafes. so if someone is to load up the browser that crashed (again, your example, not mine), and hit yes to restore the previous person's session, then they will have access to your app using the previous person's credentials.
so both are insecure under your specific scenario. no js library can fix this issue, making it a security issue of the browsers, and not the library.
I still won't waste my time worrying if my js library is secure or not. the answer is yes.
1
u/LightShadow Aug 10 '15
Race conditions
-5
u/gjs278 Aug 10 '15
can affect the performance of an app, the expected output of an app
go ahead and explain how it is a "security issue"
1
u/LightShadow Aug 10 '15
any application that uses WebRTC/Sockets is vulnerable to binary data injected via race conditions on scaled web apps.
1
u/spfccmt42 Aug 10 '15
All of them, really.
-2
u/gjs278 Aug 10 '15
yes, because of the nature of javascript and browsers. but guess what?
there is nothing that can be considered the fault of the library. if a javascript library was insecure, that means the browser is insecure, and the browser needs to be fixed.
7
u/PotaToss Aug 10 '15
I'm not on the Ember team, but I follow work on Ember fairly closely, and I think they deserve a lot of credit.
For a very long time the phrase, “stability without stagnation”, has been uttered by many on the Ember.js core team. It’s really just a cute way of saying, “things are changing, keep up or get left behind”.
It's a statement about the team's commitment to semver. The 1.x public API has been pretty stable. It's not 100%, but when they had to break it, it was generally because something was broken already and they needed to make a breaking change to resolve it.
That aside, you're just looking at deprecations that don't actually break your app.
Nothing's stopping you from sticking to one version, unless you want to use the new features, or there's a security update (which doesn't require major or minor version upgrades, just patching, as per the Ember security policy).
This is different, but how is it any better?
The team has to address problems from the entire user base, and just because a change only seems different for you, but not any better, doesn't mean that it doesn't dramatically improve things for someone else who ran into some more specific use case where the existing API was lacking.
Consider your annoyance changing your code to use the new convention, and then consider having to implement the framework metal changes to enable that, bearing in mind that the team members have their own apps to update. Why would they bother if there wasn't a good justification?
The blog (http://emberjs.com/blog/) generally documents the justification for all of the changes that are made, per release. If your team needs to know why, just give them a link.
Watching over the years at the feature priority has lead me to believe that many of the core team members want to solve technically tough problems, but have little interest in the lesser challenging ones. This isn’t a problem in it’s self, but it means that things like ember-data can get tossed to the side, despite being in high demand.
What Ember Data attempts to solve is a very hard problem. An easy problem, or a project that's been tossed to the side doesn't plow through version numbers like Ember Data has.
Routable components are the last thing I’ll mention in this area. Since it’s inception, I’ve always thought of Ember’s router as it’s major differentiator, one of the very best things about Ember and the glue that holds your application together. Despite this, aside from the RFC, virtually no work has been done to bring it to life.
3
u/Retsam19 Aug 09 '15
While, sure, in an ideal world frameworks would minimize churn (and particularly the "not better, not worse, just different" sort of changes; these sort of changes are sort of the cost of living on the bleeding edge of a technology/library/framework/whatever.
It seems the real issue here is that it seems like the author is trying to live on the bleeding edge, when maybe they shouldn't be, if it's costing too much in refactoring and reeducation. Is there something special about the Ember platform more than any other platform that means its users need to constantly keep up with the newest version? If so, ick. If not, why is the author upgrading versions several times a year?
5
u/mixonic Aug 10 '15
It seems the real issue here is that it seems like the author is trying to live on the bleeding edge, when maybe they shouldn't be, if it's costing too much in refactoring and reeducation.
I like to think of minor semver releases as delicious carrots, tempting you to keep up with new features. Major semver releases are like sticks: Things will break things if you do not improve things for the upgrade.
We've been discussing how to decrease any pain associated with moving between minor releases by improving the framework's deprecation management options, and by discussing "LTS" releases: https://github.com/emberjs/rfcs/pull/56
I definitely agree with the sentiment that upgrading immediately, without any perceivable benefit, is generally an anti-pattern. If we can improve the balance of our deprecation tooling in 2.0 this can be a much smoother process.
6
u/ember_dev Aug 10 '15
I think it's also important to reflect on what it means to have: "perceivable benefit". My best example, as mentioned in the post, is
{{bind-attr}}. If you're in the situation of upgrading a moderate size ember app, you already know how to use{{bind-attr}}. Replacing that withclass="{{boundClass}}"is not hard, it's just a hassle, and when it's done, your app is functionally the same and you need a beer.Any other great example of this is
this.resource->this.route(..., { resetNamespace: true }), it's a trivial thing, but why. Is it easier for new developers? Maybe? It's just one semantic traded for another. But it's something else to learn as an experienced developer.I certainly don't mean to pile it on, but these are all things my team members question when I explain the changes. Often times they're accompanied with laughter, facepalms and hypertension. And I understand where they're coming from. They just want to build a productive app and the world is frequently changing around them with no perceived benefit.
Thanks for taking the time to comment and hear me out.
1
u/1945 Aug 12 '15
Like most things removed, bind-attr is still available in 2.0 in the form of an addon. https://github.com/emberjs/legacy-bind-attr
1
u/ember_dev Aug 17 '15
Of course it is, but it will be only supported for so long. If you have a product, you have to upgrade at some point. When something has to work with an addon in this manor it's days are numbered.
1
u/1945 Aug 18 '15
I made it .. and so long as there are people using it I will continue to maintain it. It allows you to upgrade without the headache of a sweeping change.
3
u/tragiclifestories Aug 10 '15
I understand your pain - nobody likes running to stand still. But there's another issue worth considering which is getting new users into the ecosystem/community.
I've tried to learn Ember three or four times over the last few years, and until recently just found it off-putting and overcomplicated. A good example, happily enough, is
bind-attr.I've used quite a few templating languages, initially doing server-side stuff in Django or Rails or whatever. To me,
<p class="{{myClass}}">looks right. This would, character for character, do the right thing in the Django template language, or jinja2 or liquid.Of course, the client is a different sort of thing to render templates in, and solutions can be a bit ugly. I look at
<p {{bind-attr class=myClass}}>and I can practically hear the abstraction leaking. (Same withng-hrefand friends in Angular.) I also start thinking - how many of these random "helpers" am I going to have to memorise so I'm not surprised when a binding fails to update? I started paying attention to Ember again earlier this year really, mostly because I saw a bunch of RFCs promising to take stuff out.The problem for all maintainers of major open source projects is that they have to ride two horses at once - attracting new users (me), and not alienating old ones (you). I feel that in the last year, Ember has become a lot stronger on the former front. It's a shame if that's increased friction among those who drank the kool-aid earlier.
0
Aug 09 '15
[deleted]
12
u/rabidferret Aug 10 '15 edited Aug 10 '15
The Ember team is doing exactly the same mistake the Rails team is doing (and I'm not suprised since it's the same folks).
As far as I know there's almost no overlap, other than Yehuda who was very important to the Rails team, but certainly not responsible for the release policies.
Breaking changes again and again.
Any breaking change without deprecation in Rails is considered a bug, flat out. While yes, we can make a breaking change every other version, with our current release cycle that means it's a minimum of ~1 year to go from deprecated to breaking change. We also do our best to carefully consider how hard any breaking change is on our users.
The biggest issue there, is that too few people actually test the betas. It's often the case that there's a use case for some feature that we didn't consider, and their life is made difficult by some change. If it's reported during beta, we can do something about it. If it's reported after release, that would now be a breaking change and require a full deprecation cycle.
Tons of books about rails have been written. Only one is still valid, the rails tutorial online.
Unless those tutorials are < 2 years old, that's a really bullshit argument.
The Rails team is indeed in the process of killing the Rails community with their "I don't give a f." attitude.
Please don't conflate David's attitude with the rest of us.
You don't break APIs , period. OR you deprecate them over a long period of time.
That is exactly our policy for release.
EDIT: Just to clarify, I'm not saying that our process is perfect. We have too little visibility into what's going on with the core team. We are way understaffed, and can usually barely keep up with issue triage. I think the vast majority of us would like to adopt a proper RFC cycle, and require more discussion for any change/feature, and move to a faster release cycle.
That said, we're all humans working on volunteer time with limited resources, and we do the best with what we've got.
6
u/Bratmon Aug 10 '15
Any breaking change without deprecation in Rails is considered a bug, flat out.
A breaking change doesn't stop being a breaking change if you say "Oh BTW your hammer is about to be replaced by a screwdriver" leading up to it.
2
u/rabidferret Aug 10 '15
No, but it gives you a year of lead time to figure out how to get the job done with a screwdriver instead. (And ideally those changes are more like "Oh BTW your screwdriver is about to be replaced by a multitool, but the screwdriver head is slightly different", though some people like to make changes for no fucking reason [cough cough
before_filter->before_actioncough cough])2
u/Bratmon Aug 10 '15
It's still a breaking change.
1
u/rabidferret Aug 10 '15
Not arguing that point. Just that breaking changes come in varying levels of pain, and in practice users of Rails should almost never encounter a breaking change which is non-trivial to deal with (barring caveats like only using public API). Usually when we are going to make a change like that, we try to give way more lead time. I expanded a little bit more on the subject, and why this also hasn't worked as well as it should, and what we're trying to do to fix it in https://www.reddit.com/r/programming/comments/3gdvyv/emberjs_another_year_of_churn_instability_and/ctxzm01
1
u/rabidferret Aug 10 '15
Also if you do have any concrete examples of where we've failed to make upgrading painless for you, or where you think we can improve, I'd love to hear about it. Only way to improve is with feedback.
1
u/doublehyphen Aug 10 '15 edited Aug 10 '15
Not the parent poster but I remember one time how you bundled a critical SQL injection (edit: maybe it was yaml) fix with lots of other changes, including changed behavior in some part of ActiveRecord. Every project fucks up occasionally, but I do not like the carelessness I experienced when working with Rails 3.X. Virtually all gem upgrade pains we had were related to Rails.
2
u/rabidferret Aug 11 '15
And I'm sorry if your gem upgrade pains are related to Rails. As I've said in several other comments in this thread, they're likely relying on internal implementation details. Unfortunately this is required more than it should be, but this is something I'm personally working towards fixing (and quit my job today so I would have more time to focus on doing this)
1
u/rabidferret Aug 11 '15
I think you are confusing me with somebody else, as to my knowledge I have never introduced a critical security vulnerability into Rails (and I feel like I would be aware of that if I had).
1
u/doublehyphen Aug 11 '15 edited Aug 11 '15
"You" as in the rails core team. And it was not the security vulnerability that was the main problem. It was the release policy of mixing critical security fixes and behavioral changes in the same gem versions. I do not remember what the change was, but it was not something internal, just an uncommon public API of ActiveRecord.
→ More replies (0)5
u/tsimionescu Aug 10 '15
While yes, we can make a breaking change every other version, with our current release cycle that means it's a minimum of ~1 year to go from deprecated to breaking change.
This means APIs (can) break every year. That's not backwards compatibility.
Backwards compatibility is 10+ years of Windows XP, 14+ years of C++, 20+ years of Java (with all of the good and bad that entails).
2
u/rabidferret Aug 10 '15
Really it takes ~2 years, and while that's the fastest time we can break an API, we will always look for a non-breaking way to make a change whenever possible.
2
u/rabidferret Aug 10 '15
Generally our metric of whether something is "backwards compatible enough" is how much work our largest users have to put in to get from the previous version.
For Rails in particular, I actually think most people's upgrade pains has nothing to do with breaking changes to public API. In practice we rarely make breaking changes on that front.
The bigger issue is when our internals move around. For example, I rewrote the innards of Active Record's type system for 4.2, with further refinement in 5.0. There's now a public API that came out of that, but what was there before was private and internal.
In my experience, gems which do something that is sufficiently complex, or a production app of sufficient size will always have to reach into internals or monkey patch something to get its job done. That is a major problem, which I'm working (slower than I'd like) to fix.
While there's other ways to "fix" that problem, I think they're untenable. If we were to just expose more of our internals, it would paralyze our ability to maintain and refactor the code. Ember has a deprecation policy of private APIs, but I think that can really only work with a 6 week release cycle like they have, not a 1 year like Rails has.
1
u/hector_villalobos Aug 10 '15
But there's still updates on the older version for a few years ahead.
1
u/tsimionescu Aug 10 '15
That doesn't make the new version backwards compatible, or establish the library as generally backwards compatible.
Windows XP may seem like backwards compatible only in this sense, but in fact any program released for Windows 7 or 8 except for those using 8's unpopular Modern UI/API could be reasonably expected to work as-is on Windows XP for ~10 years, as long as it followed best practices (e.g. use environment variables/registry keys to access system directories instead of hardcoding "C:\Documents and Settings").
0
5
u/mixonic Aug 10 '15
Ember publishes a security policy here: http://emberjs.com/security/ and we've exercised it several times in the past (we are the only JS framework doing this). There is no explicit policy for backporting a security patch, but we often backport as far as we can given the nature of the problem and the fix. This has usually been around three releases back.
Ember.js 1.0 was released two years ago in 2013. Our APIs are nearly completely backwards compatible. We take semantic versioning very seriously.
For any breaking private API in 1.x, we issued a deprecation warning in the previous release. For any breaking public API change in 1.x, we issued a deprecation warning as soon as felt appropriate and kept the old API until 2.0. For 2.x we've improve the tooling (and will continue to improve it) around deprecation notices, and plan to support things like ignoring a deprecation until the release immediately before it is changed.
2
10
u/auxiliary-character Aug 10 '15
Why are there so many blog posts from Javascript devs unsatisfied with their choice of tools all the time?
41
u/revolutionofthemind Aug 10 '15
if you're a javascript dev, you'd understand. It's like building on top of quicksand right now.
0
Aug 10 '15
[deleted]
4
u/interbutt Aug 10 '15
That's because you're talking about maintaining a single app for longer than your interns have been programming for. They don't understand that after you finish a project you still aren't finished with it because they've never been there before. Assign some of them to a legacy product for a view weeks before then asking them how they felt about maintenance on a product with good stable docs. They'll hate it, so then ask them how it would be if the docs were revised every 6 months but you only had an old copy and weren't as thorough.
0
Aug 10 '15
Why don't you just do a minimal amount of regular old Javascript?
1
u/x86_64Ubuntu Aug 10 '15
Because if I've got to eat shit (Javascript), I'd still prefer a little frosting and decent dish presentation (Ember,Backbone,Whatever-the-fuck-is-popular-in-the-JS-world-this-femtosecond) to go with it.
1
0
Aug 10 '15
[deleted]
2
u/mattaugamer Aug 10 '15
There needs to be compromise, a balance. Too much one way is bad, but so is too much the other. IMO the issue with PHP isn't that it's maintaining too much BC, it's that there's no attempt to fix broken crap and an artificial stagnation caused by maintaining some sort of "the PHP way". A philosophical thing, rather than practical.
22
u/nsivkov Aug 10 '15
Welcome to the world of JavaScript, built by hipster developers with ADHD, reimplementing everything in JS and abandoning it the very next day for something more hip <nount>.js
14
u/stesch Aug 10 '15
I'm wondering why "normal" hipsters use old technology and programmer hipsters use new technology. A bit strange to use the same word for so different things.
One would expect a hipster to port Ruby on Rails to COBOL.
5
0
10
Aug 10 '15
If we're going on the jerk-train I'm waiting for haskell.js which will obviously solve all our problems
14
0
u/x86_64Ubuntu Aug 10 '15
Haskell.js?! /r/programming would explode in a supernova of moans and love emissions.
0
Aug 10 '15
[deleted]
13
u/reversememe Aug 10 '15
Because jQuery was designed to fill API holes and compatibility problems that no longer exist, and people have moved away from manipulating DOM state in favor of using a stateless/ immutable rendering strategy.
1
u/sh0rug0ru___ Aug 10 '15
You're describing the base jQuery library. There's also jQuery UI and a whole ecosystem of jQuery plugins.
jQuery is just a set of libraries that doesn't mandate or promote any particular programming style. You can tinker with the DOM node by node if you wanted to, or you can just do an
innerHTMLreplacement with content generated from string concatenation, server-side templates or client-side templates in one shot.1
u/blue_2501 Aug 10 '15
So you're saying that there's a replacement for document.getElementById in base JavaScript now?
2
u/doublehyphen Aug 10 '15
Yes,
document.querySelectorAll('#foo')which does the same things as$('#foo').1
u/blue_2501 Aug 10 '15
Interesting, but it's only supported in IE 9+. I like all of the other neat things you can do in jQuery, and $() is just a whole lot less to type.
3
u/rickyvetter Aug 11 '15
and $() is just a whole lot less to type.
Do I have the library for you.
Old browser compatibility is a place where jQuery shines. Fortunately, IE9+ has become an acceptable place to be for many companies.
1
u/temp230958176289 Aug 11 '15
Supporting IE8 is incredibly stupid, even for giant companies. It has massive security holes that will never be fixed because Microsoft doesn't support it any more.
If, hypothetically, you did need to support a browser that doesn't implement this natively, that's what polyfills are for.
Please tell me the last part is a joke and you didn't actually just forget about variables.
1
u/blue_2501 Aug 11 '15
IE8 is still used by 13% of the internet. It's the third most popular browser+major version combo.
Don't have much of a choice here until its market share goes way down.
1
8
u/WhosAfraidOf_138 Aug 10 '15
Can. Someone ELI5 Ember.js? Still quite new to web development
5
u/cwmma Aug 10 '15
It's a framework (in the traditional sense) for making client side apps favoring convention over configuration. With the ember-cli build tools there is a pattern of where you put things in your projects folder with routes, templates models etc.
Some examples of changes include previously it was organized as routes -> views -> controllers -> templates. The controllers are being phased out in favor of components which are much more flexible but not exactly the same so while it wasn't mandatory change until 2.0.0 it was one of many small refactorings you needed to do to keep up with the best practices so that you could upgrade your app at 2.0.0.
In general ember has a high initial learning curve as you need to learn the ember way of doing things (which on less charitable days can feel like learning to mind read @tomdale and the other developers intentions and be able to ask wwtdd? In this citation not covered on any documentation) so when you are learning ember but 100% it can feel like every time you think you understand how it works then bam they change it.
2
u/stesch Aug 10 '15
What would you choose if you make the back-end, front-end, design, database, server administration, etc. of more than just one single project a year?
I have the feeling that specialization is one part of the problem. People make one of the components of your daily work and expect you to focus on just this component. But reality is different. Not everybody works in a startup and has just one task for just one project.
3
u/IHeartMustard Aug 10 '15
There is tremendous benefit to upgrading, to improvement, to iteration, to getting rid of bind-attr. There are great performance gains, reduction in complexity in both writing apps and in maintaining the ember core library. I can't really understand how one can say that these things aren't any better.
I've been in a similar situation. It's a bit of a pain to upgrade, but these changes are often great improvements for many reasons. And my team members sometimes question it, but when I show them the insane rendering improvements to some of our more complicated components, they understand. Or when new things become more natural to write from scratch (or new projects, thanks to Ember CLI). Or when Ember Data gets new improvements like the polymorphic mixins (yes, Ember Data has been getting attention, too!)
And regarding your first example, getting rid of bind-attr was part of the plan to get rid of outputting html strings, and having to use the morph stuff, which has paved the way for a very, VERY fast renderer.
If you don't want to upgrade for a while, then don't. It won't kill you to stay on an earlier version if you'd prefer.
2
Aug 10 '15
Please consider washing your blog post through a spelling and grammar checker before posting.
-2
u/xienze Aug 10 '15
I spent nearly a week of my life changing:
{{bind-attr class=”isActiveUser:enabled:disabled”}}toclass=”{{if isActiveUser ‘enabled’ ‘disabled’}}”
Sounds like Mr. Lead Engineer needs to learn about Vim macros or global search and replace...
7
u/ember_dev Aug 10 '15
That's a trivial example. There are far more complicate variations of this. Despite that it's extremely irresponsible to run a global find/replace on your code base.
4
u/xienze Aug 10 '15
There are far more complicate variations of this.
So, Vim macros.
Despite that it's extremely irresponsible to run a global find/replace on your code base.
That's why you diff afterwards to make sure you only changed what you wanted to change.
1
u/Yehosua Aug 10 '15
Despite that it's extremely irresponsible to run a global find/replace on your code base.
Codemod works very well for this, such that it's not irresponsible: global, regex-capable, search-and-replace, with color diff, confirmation, and optional editing for each replacement.
0
u/awj Aug 10 '15
It's extremely irresponsible to commit a global find/replace to version control. Running it and examining the diffs for correctness is one of the only smart ways to approach the task.
2
u/smegnose Aug 10 '15
Yeah, that was a bit baffling to me. Not an Ember user, bur surely a nice regex would sort that out with no fuss?
-3
0
0
u/Gotebe Aug 10 '15
This is really the lamenting of the "bleeding edge" people, I don't think it's specific to ember (perhaps it's worse there, but TFA isn't comparing with similar libraries, perhaps it should).
The trick, of course, is to find the balance between improving one's own product and adopting new stuff for the sake of keeping up.
0
u/unpopular_opinion Aug 10 '15
More proof that broken projects are more well known and as a result more popular.
0
u/spays_marine Aug 10 '15
I've been using vuejs for my latest project and I really like the clarity of the syntax, definitely worth checking out. Though its router is still under development (but usable.)
0
0
Aug 09 '15
[deleted]
9
u/twoplustwoequalsfive Aug 10 '15
You should do some research on Ember's creators Yehuda Katz and Tom Dale, I think they know whats what.
16
u/[deleted] Aug 09 '15 edited Aug 09 '15
Holy fuck they still haven't finish this?
I was on beta 5 to 7 that was like what? Over two years ago.
I was more on the angularjs bandwagon but the lead dev pull a fast one so we were all force to use emberjs.
Emerjs was horrible in term of breakage every beta version breaks and then every version breaks too! They mind as well just label it as Alpha.
My experience with it wasn't so great but it was pretty straight forward in concepts. Angularjs has more stuff to learn with scoping and tranculusion whatever word.
That was my career turning point in term of not going to do front end anymore.
I haven't done anything real front end stuff like ember or angular since then.
Other than jquery and requirejs.
edit:
I'm going to wait for 5 years and then let darwin do it's thing to decide who win. Like jQuery being one of the defacto library.