AngularDart or PolymerDart 2015 - dart

I have been some time away from Dart. What happened to AngularDart and PolymerDart?
What is the way to go 2015?

Angular has released 1.0 but left it quite unmainained and development now focuses on Angular 2.0 which is written in AtScript and transpiled to Dart and JS. An early alpha of Angular 2.0 for Dart is available at pub.dartlang.org.
Polymer has evolved slowly the recent year. Most effort went into core- and paper-elements. Recently Polymer 0.8 (current 0.5.x) was announced and will bring some breaking changes. The architecture is changed to allow to choose between different levels of support (and with it the library size you add to your app) and some breaking changes how attributes and properties are defined and used.
A Polymer.js 0.8 release is expected during this month, availability for Dart will take a few weeks longer I guess.

Related

Which vaadin version will be supported long term?

We have a 5 year old application written in vaadin 6. It only uses basic vaadin UI framework functions. If we want to upgrade to a newer vaadin version that will be supported, what is the version we should go to? I understand that moving from v6 to v7 and above requires some rework. Is vaadin 8 the best version to use to complete this UI migration? How long will vaadin 8 be supported? Are the UI framework stable after vaadin 8, i.e. upgrading to higher versions do not require changes in the application? Thanks for some guidance.
Vaadin versions are either incremental or come with long-term support.
A long-term support version is maintained as an open source product for 5 years after the initial release. Additionally, Vaadin is offering commercial support for another 10 years. An incremental version is only maintained for a short overlap after the next version.
Vaadin 7 is already more than 5 years old and thus only supported based on commercial contracts. Commercial support is available until 2029.
Open support for Vaadin 8 ends in February 2022, while commercial support is available until 2032.
Vaadin 10 is still supported, but there are aren't any good reasons to choose it over Vaadin 14 at this time.
Vaadin 14 has free support until 2024 and commercial support until 2034. This is the version generally recommended for new projects today.
Vaadin 23 is planned (but not absolutely certain) to be released in the beginning of 2022 with long-term support until 2027. It might be an alternative for new projects to go with incremental versions until that.
The other side of the coin is how easy it is to update your existing project. Vaadin 7 and Vaadin 8 is roughly the same from that point of view since Vaadin 8 also includes an extensive compatibility package that covers basically everything from Vaadin 7.
The jump to from Vaadin 6 to either Vaadin 14 or Vaadin 23 is bigger than the jump to Vaadin 8, but there isn't a big difference between 14 and 23 when it comes to the work needed for migrating from 6.

The updated material design (mdc - 2018) vs. angular (dart) components

I'm new to Angular and I'm a bit confused whether the implementation of the angular components reflects the recent (2018) material design system changes or they are just updating the old version of the system?
the Angular components version is been updated:
https://trimox.github.io/angular-mdc-web/#/angular-mdc-web/home
But it seems to me that the Angular Dart components version is still using the old system:
https://dart-lang.github.io/angular_components/
Am I missing something or the Angular components will not get the latest material design updates?
(I think the Angular team is using foundations and adapters to adapt the vanilla web version of the updated material design system, is the Angular Dart team doing the same?)
The specs and M2 components are still being worked on. We have some ready, but I don't see us releasing them until after internal teams have shaken out most of the bugs. They are still going through big API changes to make sure they work well in our products.
There is one that is released which is the material_card.

Is Polymer to succeed Web UI

Could someone please explain something for me.
I am confused. Currently Polymer and Web UI seems to be two separate projects with a lot of similarities.
Is Polymer to succeed Web UI - meaning Web UI will be discontinued in favour of Polymer?
Yes, Polymer is the successor to Web UI. At some point in the future, once Polymer is more stable, Web UI will be abandoned.
For now though, it still may make sense to use Web UI if you need it for a production app.
As mentioned already, yes Polymer is the next version of web_ui. It is being developed in conjunction with the JavaScript version of Polymer. web_ui is currently in extended support mode, in which bug fixes are applied to keep the library functional (particularly as new SDK releases are made), however there will be no new functionality added to web_ui.
As of yesterday, the integrated build reached 0.8.1, and with Polymer 0.8.1, Polymer has virtually reached parity with web_ui and in some areas already surpassed with additional functionality.
Google has committed to maintaining web_ui for existing projects, however I would highly recommend that any new projects be started with Polymer. It is also the time to look at porting any old web_ui projects over to the new libraries (something I'm in the process of doing myself).

Should MVC 2 - Preview release be easily upgraded to Beta when it's released?

Should I just be able to install the beta on top of this without problems when it is released ?
Not sure how it is treated within the visual studio environment. I'm thinking with it being a type of project in VS it should be ok.
Can anyone clarify?
MVC 2 is looking to be rather good from what I heard from Scott Gu # the Manchester conference, can't wait for the final release :)
There is always a chance of a breaking change when using preview and beta software. If you want to use MVC 2 Preview, you need to accept the fact that there might be some work in your future to make your project compatable with the Beta, RC, and then Final releases. It won't necessarily break, but the earlier in the release schedule (such as a preview instead of a beta) the greater the chances are you'll have to make changes to your code as they move forward.
When MVC 1.0 previews were released, there were breaking changes between the releases. If you try to keep up with each preview, you should be able to resolve any problems rather quickly - and you could provide great feedback, too!

Should I upgrade from Symfony 1.2.9 to 1.4

I am a few weeks from hopefully launching my site (Yes, I know like I may be tempting fate, even merely asking this question).
I am developing using SF 1.2.9 (using Propel ORM), but I am increasingly being tempted to upgrade to 1.4, least of all, I feel it will be less of an effort to migrate a life system from 1.4 to 2.0 later on, than from 1.2 to 1.4. Also, IIRC, active support for 1.2 is being phased out next year, whereas 1.4 is to be supported till 2012 (IIRC).
So, shall I bite the bullet and upgrade, or shall I take the (on the face of it - safer) option and stay put with 1.2.9?
If you want to use some of the new features, you should upgrade of course. As the symfony development is test driven, I assume the new versions are stable and reliable.
But: Do not upgrade to 1.4 but to version 1.3. The later has an extra compatibility layer to ensure that projects based on 1.2 still work. There are some internal changes in 1.4 that forces you to really refactor some parts of your project to keep it working. With 1.3 you can make this changes step by step.
The only differences between 1.3 and 1.4 is this compatibility layer. For specific instructions, read this upgrade guide.
As for support, 1.3 is supported until the end of next year which gives you plenty of time to upgrade to 1.4 step by step.
And in general I belief also that upgrading from 1.4 to 2.0 will be easier than from 1.2.
Edit:
You can find the changes here and the deprecated stuff here.
I don't know if 'internal changes' was the right word. There is some stuff you have to consider if you change to 1.4 but the deprecated stuff in 1.4 still works in 1.3.
I will try to upgrade one of my projects to 1.3 this weekend and I can give you feedback somehow if you want to.
Are their any compelling reasons for the upgrade? Does version 1.4 have more bug fixes, or additonal features that your appliation must have? Are their any breaking changes between 1.2.9 and 1.4? Is there any refactoring to do after you've upgraded to 1.4 from 1.2.9?
I'm looking at this from a .net framework perspective;
.net 1.1 to 2.0 - there were many changes here. many of them were breaking changes, but the benefits of the upgrade were great.
.net 2.0 to 3.0 or 3.5 - a lot of upgrades were introduced here, but not very many if any breaking changes since the last two upgrades were based on the same basic framework. You can live with the 2.0 version without upgrading to any of the other two.
So if the Symfony upgrade is similiar, I would wait for a little while. You've got your application built, tested and ready to go. See what it takes for the upgrade and then see about integrating the new features in during the next iteration of your development.
Good luck with your site, and hope this helps some.

Resources