We Keep Coding

Major Ember upgrade - 1.12 to 3.5

In nearest future I will be doing a serious update of the application. I have a little experience with ember.js & have no one who can help me resolving this matter. The app is written in ember 1.12, and there are few dependencies. It has a web version and mobile (iOS+Android) written in cordova - all of them need an upgrade.
What kind of problems should I expect?
How to prepare for them?
How much time should I estimate?
Any help will be very useful- it's first time when I will be doing app upgrade.
I have checked this links, but most of them are for above 2.0 versions.
https://www.emberscreencasts.com/meta_guide_to_upgrading_ember
https://medium.com/ingenious/how-to-upgrade-ember-js-to-3-x-and-live-to-fight-another-day-cfc28c16b726
http://www.ember-cli-diff.org/
https://medium.com/front-end-hacking/everything-you-need-to-know-to-upgrade-your-ember-js-app-including-ember-3-9de5e808dde0
https://medium.com/ember-ish/upgrading-ember-from-1-13-to-2-8-0-f1dbcecc40ca
https://medium.com/front-end-hacking/how-to-use-ember-2-code-in-your-ember-3-app-9ed15c28bad6

Depending on the size of your application and how extensive your test suite is, you'll probably be dedicating a minimum of 4 weeks getting just the web version up to 3.5.
The process will be time consuming and tedious.
1. Upgrade by 1 minor version (1.12->1.13)
2: Run your test suite and fix any issues that come up
3: Manually test the tool by navigating around & fix any issues that come up
4: During the testing, you should have identified a handful of deprecations. Fix those.
5: Repeat steps 1-4
6: After you've upgraded to 2.0.0, you may be able to skip a couple of minor versions at a time, if you aren't using private APIs and your dependencies are small.
Ember maintains their [changelog](
https://github.com/emberjs/ember.js/blob/master/CHANGELOG.md) as well as a page that lists deprecations and their solutions, so you'll want to become buddies with the version you're upgrading to. For each deprecation they mention, check the linked issue history to see what the suggested replacement is. Be proactive - don't wait until the final version to fix a deprecation.
The big/common issues you'll encounter are:
Views are deprecated and removed. You'll need to understand how components work and migrate any existing views to a component.
The select helper gets removed.
If your views & components use targetObject to get the controller, you'll need to make them work without doing it. This means determining what properties & actions need to be passed in and explicitly doing it. Components shouldn't know anything about what called them.
Ember has a solid guide on working with deprecations at https://guides.emberjs.com/release/configuring-ember/handling-deprecations/ that may be of some help.
Keep your changes versioned. You'll break something bad enough that it's easier to just roll back and try again. If you're not using versioning, you're in for a really hard time.
Finally, make sure you clean out your npm directory between versions & wipes - If you don't, you may thing everything is working, but it really isn't.
As Patsy commented - You're probably better off hiring someone who knows ember very well to do this upgrade. If you don't know ember very well, you may be putting fixes in that back you into a corner.

I upgraded a bunch of Ember apps / addons from 1.11 -> 2.18 in advance of the 3.0 release. I don't think there was a single minor version upgrade until the 2.10s that didn't break my app.
I also simultaneously upgraded ember cli with the app. I tried upgrading ember cli to the latest, but I had a bunch of cryptic errors and reached a sort of dead end. What I instead opted for was looking back at the Ember release notes and seeing which version of ember cli was the latest at the time of the Ember release. I would upgrade Ember cli every 4 versions or so, unless if I encountered issues at which point I would immediately upgrade.
The single most important thing is automated tests. I see that you say you have no tests and will just manually test but this is foolish. I had a bunch of code that I needed to upgrade that had no tests. I wrote comprehensive tests over the course of a week since I had two weeks to do the upgrade. These were absolutely vital and some upgrades would break 60-80% of my tests. It would have taken me 2 months without tests probably, but I accomplished it in 2 weeks with the tests, using the first to write the needed extra tests.
Comprehensive tests are best, but far from necessary. At the minimum I would recommend you take the time to mock your API calls and write an acceptance test for each page of your app that serves as a smoke test. The test is as simple as go to the url and check the dom is there. Ember cli page object helps immensely + html5 test-* data classes.
Once you've done that, follow what #Trenton Trama suggested. Upgrade minor version, run tests, fix problems, rinse and repeat until fully upgraded.

Semver is too difficult or what’s going on?

I noticed that in JavaScript world something changed over time. Previously backend and frontend used semver approach when it comes to version a library or app. Now, in JS world some and I see more and more libraries or frameworks follow the approach to release major version 2 or even more times per year. Let’s take Angular, Ionic for example. Some of my ex or just colleagues also are using the approach.
Why is that? I am asking this as I am a backend developer but I am about to release a JS - powered library and I am a bit confused how to version this.

They release much more frequently major versions precisely to comply with server requirements: they gradually introduce some breaking changes (even if most of the time they are small), therefore release with a new major version.
In the case of Angular, as you notice they plan to release a new major version about every 6 months. The idea is to keep freedom to improve the library without being constantly stuck with full backwards compatibility requirement.

Web-Based Game Engines - Request For Input

I'm creating a web-based online game and am trying to find the best fit in terms of a framework for the front end of the game. The back end of the game is currently using asp.net mvc 2. Given that I could take the controller actions and turn them into WCF service actions the choice in the back end should not affect my options of a front end.
One thing that is certain, it does need to play in a browser. I have done some research on an HTML 5-only front end as part of this process and am probably leaning in this direction but I have a few concerns:
Assuming this game is completed this time next year, what kinds of difficulties will I have with current HTML 5 adoption levels? Specifically I'm worried about Firefox 3.6 and IE 7/8 still having a large install base. I have looked at Chrome Frame to solve the IE problem but am not sure if there are drawbacks to that I am unaware of either (other than the installation requirement).
I'm used to doing C# with a nice IDE complete with realtime information about whether the code compiles and intellisense reminding me of symbol names. Am I going to run into a problem with Javascript where my code becomes big and difficult to manage? The accessibility problem that a Javascript only engine solves for my users is more important than convenience for me but it of course can't be unmanageable either.
Are the HTML 5 engines on the market right now mature enough to trust with my time investment? Am I at high risk of adopting a framework that will fall into disrepair in a year from now? Of the engines I have looked at, none seem to have really great community support, am I wrong? Are there others out there that do?
here are those I have found thus far:
CraftyJS (http://craftyjs.com/api/Sprite.html)
ImpactJS (http://impactjs.com/)
PropulsionJS (http://www.propulsionjs.com/)
The Render Engine (http://www.renderengine.com/demos.php)
RPG JS (http://rpgjs.com/)
EaselJS (http://easeljs.com/)
Does anyone know anything of the community with these or have any reason to trust that any of these will be well maintained or available for at least the next several years? Does anyone know of another framework that's out there? ImpatJS has the most impressive demo of them all and it's also the only one that isn't free.
Thanks for any help / advice. I'm just worried I'll choose a front-end that I regret and I don't want to have to start from scratch 4 or 5 months down the road.
This is a 2D browser-game. It's not targeting mobile now, but it will be moving to mobile immediately after first launch. One hope is that it will work on mobile fine if I do HTML 5. I may have to tweak it for display size but if I don't have to port it to mobile that would be a definite plus.

This is my two cents having just been through the same decision making process for my company.
Our goal was to create as broad a game as possible that means it needs to run on as many browsers as possible. I ruled out html5 right away because the adoption is not there and seems to be at least a couple years until it reaches more than 60% penetration.
This left me with Flash vs. Silverlight. Flash's installed base is huge and there are many game engines available for it. Flash is a safe bet unless you have specific requirements for video or 3d.
I choose Silverlight because I wanted a good installed base (60%) and I wanted to leverage my companies’ in-house .Net expertise. I also wanted to use WCF for the backend and did not want to mix environments.
Keep in mind that SL5 is going to support most of XNA which is a big deal. There are a ton of XNA engines and source code that you can use to start with.
Here's a great site for looking at html5 browser support:
http://caniuse.com/

I can't speak with expertise on the particulars of HTML5 and Canvas, but...
As far as support goes, you'll still have probably a large bunch of IE7-8 users. IE is a little different than other browsers because you have to DO something to install updates. (i.e, go to the Install Updates in Control Panel or visit ie.microsoft.com). Other browsers (like firefox) just tell you and make the update easy. So your FF 3.6 users should be gone, but IE will still probably be a problem. Keep in mind, though, that much of the old IE browser share is due to IT depts. keeping their users on older versions - something you won't need to worry about.
This could be a problem. However, developing JS in Visual Studio or a similar IDE isn't so bad - there's still IntelliSense and other helpful things, as well as realtime debugging. It's definitely going to be a bit more difficult than C#, especially as many of the new JS api's haven't been implemented into the Autocomplete's of many IDE's.
I don't think you need be afraid of this. At this point, HTML5 and Canvas have gotten far enough that they won't be revoked, only improved. There may be a few modifications of the APIS and such, but not enough to keep you from using it.

Is HTML5 going to replace Flash? No, because games and RIA that require more out of javascript cannot be done until enough of the world is using IE 15 (which is about 5 10 years). Safari, Chrome, FF (maybe), will be up to par here soon but their js engines are going to require good hardware and that's not always going to be there.
Silverlight is a good option but it's not as well supported as Flash. This is why flash will still be around. The next version will support video controllers. It' called Project Mole hill and you can check out my SO question here.
If you want to make super simple games without good graphics try out one of those services you suggested. impact.js is $100, the others look free. In the future we will be able to use node.js to handle request with servers, but in the meantime Flash is certaily the way to go!.
I would much much much rather use javascript but after you start coding and realize the limitations compared flash will make your application standout.
Then for mobile devise, iPad, iPhone, Android, etc.. If you really think your audience is there build the game in the their language. It's more epensive and and harder, but Objective C, Java, they are much faster than HTML, JS, CSS etc...

I did some trial runs with YUI3, Burst engine & Raphael for SVG animation - everything seemed to run well; YUI's dragdrop module even detects the same drag operations on Mobile without adding a single line of code.
I can only imagine that if I had the time, a YUI3 instance available on a Node.js server with Raphael SVG animation would be my choice. You could drop the SVG aspect and use more standard graphic techniques, or perhaps serve up alternate quality graphics for those User Agents with fewer testes. Maybe it could be that your alternate quality version is just another implementation of your game engine - and you might choose to develop games using non-SVG anyway.
Just thoughts mostly, that doesn't help with your real-time IDE debugging...

impact.js has a great community and documentation. It is well worth checking out. I believe iosimpact.js is part of the package (although beta???) allowing for the development of native games for the iphone/ipad.

Yes, indeed you will lose a large user base. But how relevant that user base will be to you will depend on what your target is. Every-day-RPG players are much more likely to have the latest browser than Sunday-Morning-Sudoku users.
Give Eclipse + Web Tools + Aptana a try. It worked really nice for me.
No experience there.

There are certainly people out there who think that HTML5 is going to replace flash in online games. Here is an HTML/Javascript based engine that I heard about few days ago
http://www.youtube.com/watch?v=_RRnyChxijA
I haven't actually used it but it looks really promising and It's designed for similar set of requirements that you've put. It lets you design 2D / 2.5D ( isometric projections ) games. And it does look promising.

What client web GUI technology to chose Flex or dhtml/JavaScript?

im standing and trying to decide which client web GUI to chose flex or js/dhtml ( one of the frameworks or combination )
i need to build front end to system that user can edit some kind of book format that involved images and texts
and i really don't know what is better . for user experience and easy development

Simply put: Flex will be a much easier framework to work with to provide a good user experience.
Flex is really great (actually the best) to process images and do video and sounds effects in the browser. Manipulating text and images layout just cannot be simpler with any other framework.
When working with Flex, try to target Flash player v9 (not v10) since it's already installed on ~98% of PCs connected to the internet.
On the other hand, js/dhtml might be harder to work with (depends on your experience) but will be able to provide a better user experience IMO. Users will be working with a web page after all which will feel more natural to them.
Performance: The flash player is the fastest VM you can target to run code on the browser as far as I know. It is way much faster than IE6 for example (no doubt about that, a huge gap). But with FF 3.5, and latest versions of IE and Safari, I think the gap is much smaller if there is any. Actually FF 3.5 uses the same technology to run js the Flash player used to run ActionScript. Tamarin
That said, there are other aspects of performance than code execution speed. The flash player will require more memory (special on Mac and Linux). And depending on your application, might be less responsive overall. (this depends on rendering, animation, and how will you implement things).
I really don't consider requiring a browser plugin is one of the cons of Flex since that plugin is there for almost all users, and users are very likely to be running it on another page before visiting your web app.
The only pro for js/dhtml is that it will feel more natural to users and IMO will provide a better experience if done correctly.

Pro Flex:
Better Performance
Stuff like images and sound are easier to handle
Pro JavaScript:
Works in every browser if you chose a well-programmed framework
No browser-plugin required

I made my self the same questions some weeks ago. I have choosen flex because it's easy to use and you can get good looking effects without effort.
I think the issue of need the flash plugin installed in the browser is no problem at all beacause most of users have it already installed and if not it's very easy to install.

Since my relatively large client-server project made the transition from a heavy DHTML front-end into a heavy Flex front end, I'll explain our reasons. We were using dojo 1.1 for our JavaScript library.
We already had flash components because there were parts of the application that were custom-designed animated diagrams (e.g, org-chart type stuff). ExternalInterface was good, but it was nice to move into a single architecture for the front-end. There ended up being some duplication because of the mixed metaphors.
Because of heavy use of dojo widgets (dijit library), upgrading to new versions was difficult, and we ran into some problems when Firefox 3 came out. And likely when IE8 came out. The problem was that dojo had fixed the problems, but would have required a major rewrite if pieces of our application in order for us to upgrade (they had rewritten some of their container widgets in 1.2 or 1.3 (IIRC).
Was tired of fighting with CSS differences in browsers. At least flex is mostly compatible between supported browsers.
I prefer JavaScript to ActionScript 3, but the flex transition made sense for us.

Web desktops - do you find it interesting? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 months ago.
Improve this question
As a win32 developer moving into web deveopment the last few years, I found the
web desktops based on extjs very interesting.
Coolite Desktop (broken)
Extjs Desktop
Puppy Web Desktop
Wikipedia list
Lifehack list
Windows 3.1 desktop (broken)
Do you know about others?
Without any experience of developing applications as web desktops (and I am not promoting extjs, only impressed...),
I have to say I like the concept.
What do you think, is it useful?
Edit Dec 30 More about the subject here:
are-webos-practical-yet

I find it an interesting experiment, but I don't really find much added value in it.
The desktop concept works for an operating system. Most people use one operating system. They are familiar with how it works and what to expect in terms of navigation. That being said, having a desktop at an application (or site) level adds another navigation model that the user must learn. If they are expecting it to be the same at their OS (which it won't likely be), then it can lead to confusion because it doesn't work exactly like what they're used to - although it looks like it should.

NO.
Also, Uncanny valley of UI.

I think they serve as purely tech demos, I don't see the web desktop getting any traction unless Google jumps on this and offers all their major apps (Google Office, Gmail, etc) as apps within a web desktop.
Of course the whole desktop methodology doesn't exactly fit the browser mentality very well.

Really it doesn't look like a huge step forward. I don't care if the desktop runs in my browser vs my actual PC. Desktop environments continue to suffer from a lot of problems.
First, I really need some way to declutter and organize open apps around my personal real-world "logical" tasks. Desktop environments all display a single, poorly organized static list of apps. I feel like I have lost my mind half the time during a busy work day. I often get a feeling synonymous with the "why did I come into this room!?!" feeling when I can't keep track of where I am in the desktop environment, or why a given app is even open.
Attempts have been made to address this by grouping items by application. For example, in Windows, grouping all the Microsoft Word content in one group on the taskbar. The thing is, I need things on the task to actually correspond to my real world tasks. Granted, I don't expect the UI to read my mind, but if there was some really slick way to group multiple instances of different apps together and identify them with one task, that would be awesome.
Another problem with desktop environments is their performance. They continue to attempt to push the limits of what hardware can do. Often, they go to far. As Jeff points out, for a developer, I want my tools to work fast. I can't stand waiting for some GUI widget to load so I can code, or for that matter browse the web or write an email. This, in my opinion, is why straight up command line development continues to thrive and why many of us don't want to give up Windows XP for Vista.
If Vista can't get this right, performance is not going to be improved by having a "web desktop".

Like others have said, this has been around for a while. I think if it was gonna take off, it would have already. I don't think it's a matter of technology catching up, I think it's a matter of developers not wanting to put time into a tried-and-didn't-take-off technology.
Is the desktop a good way to organize your apps? Most people I know don't use their desktop very often, it's rarely actually visible. The Start menu in Windows sees much more use and it's analagous to a list of browser bookmarks.
Also, my opinion is that Silverlight will allow better browser-based user experiences with less development time.

In my opinion but people will never use them as a desktop replacement, there are too many quirks and potential pitfalls to be an actual replacement or even useful.
They do make an cool demo of ajax-y technologies and serve as a guide on how to develop apps with that desktop feel (which I'm not sure it's worth it), but not much more.

The demonstration of capabilities is amazing. To create a desktop environment in a web browser is a beautiful indication of what browsers and javascript are capable of.
With that said, I believe it will (and hope it does) die as a viable development platform. Currently browsers don't provide the processing power that a desktop does and ease of development is much greater for desktop than browser "simulated" desktops.

the desktop metaphor in a web browser is neat, but
the first link was still downloading images after 1 minute so i closed the browser
the second link came up instantly and looked really good
for intranet applications this might make sense
for task-based site with multiple tasks this might make sense
this isn't that new of a concept - BBS software had this 20+ years ago, and extended it to the web 8-10 years ago; the metaphor was not very popular because that's not how people use the web...yet!

No, because the web is the OS, the platform is the browser.
I use several web based application including Google Docs, Gmail and so on. Not all of them are from the same provider. I access them all using my browser.
Forcing me into using a "web desktop" is like the portal thinking of the ISP's ten years back - forcing users into your own "world" to make them use only the application you provide. Instead of just acting as a gateway to reach all the possible choices out there.
IMHO, this is why web desktops will fail. The OS of a PC is there to tap into all the possible resources of your desktop, in the same way the browser is for the internet. Web desktops is to me equal to install yet another OS on your current one and limit yourself to use only that.