So ive been digging abit and ive come to the conclusion components isnt working with version 1.1.5 of angular which umbraco uses, is this correct?
The "correct" way to implement features like this would be a directive then right?
Is there any plans to upgrade this in the near future, that is a very old version :)
I found this documentation: https://our.umbraco.com/apidocs/ui/#/api for already used api's but i cant find the js corresponding to this so i could see how it was done originally :)
Yup, you're correct that for now you will need to use directives.
The plan is to use AngularJS 1.7 in Umbraco 8. The upgrade is in progress, which you can see in this issue from the issue tracker here http://issues.umbraco.org/issue/U4-10928
That hurts my heart abit that we arent going into typescript i really have come to like angular 2 with typescript and all the good parts its bring, CLI, proper intellisense, typechecking, i could imagine a bunch of usecases for umbraco, create api controllers from within umbraco and build out your frontend from pure generation have all interfaces upheld within typescript etc.
Actually you could make a documentation generator from the typescript classes present in the project and use comments to show usage of components, which is direly needed atm.
Do you know why this decision was made seems abit odd to use an old technology when making a new version of the CMS, or is umbraco 8 just an upgrade of 7 really?
Yes we all want the latest and greatest and bestet don't we? :) But the essence of it all is that rewriting the entire backoffice from scratch switching to Angular 2...or is it 6 now? Is that it's been fundamentally re-written so the concepts used in AngularJS has changed and I don't think it's a simple task to re-build it all from scratch. Now I have not got that much experience with Angular 2+ so I don't know what is possible and what is not.
Therefore I will quote Matt Brailsford thoughts on the issue from his thoughts about using VueJS in Umbraco in the future:
The logical thought process would appear to be, "let's move
over to Angular 2 then", after all, whilst there are many new
concepts, there are still some that are the same, so it shouldn't be
as bad as starting from scratch. Unfortunately, though, Angular 2 just
isn't looking like a suitable match for the Umbraco project.
Some of the core concepts Umbraco uses to have a "pluggable"
architecture are no longer present in v2 which would require HQ to
rewrite these features back in. In addition, the v2 build process is a
lot more convoluted than v1, forcing developers to learn webpack,
typescript, and others just to be able to contribute.
Realistically then, Angular 2 just isn't looking like as good a
solution for Umbraco moving forward.
Everyone is of course entitled to have their own opinion on these things but I think the decision to only go up to 1.7 is the right call. If HQ should change the underlying architecture on the frontend each time a new framework is released or had a major overhaul we would never see a new major release. And also using the latest and greatest should not be the ambition the way I see it.
But don't take this as I'm saying the backoffice should never have a major rewrite or overhaul. I don't think that it can be avoided and it will happen at some point. But it's just not what is being focused on right now.
Perhaps when V8 see's daylight and plans on v9 begins to see the light. But remember that we've actually been doing quite well with the 1.15 version, which is also pretty old these days. But it's still easy to extend and bend Umbraco backoffice to your own will relatively easy to the benefits of the content editors.
Who knows maybe the next logical step would be to ditch the frameworks and rely on using WebComponents? :)
I hope some of all my ramblings above makes sense. Bottom line, it's not easy to "just" switch to Angular.
I understand you cant just rewrite everything i was of the conviction that a rewrite would happen with umbraco 8 anyway since it wasnt upgradable, and this was one of the reasons to actually switch angular out with something else, i wouldnt mind vue.js either its not my favorite but i can see the advantages for templating, its like a hotreplace.
This for sure will affect our use of umbraco 8 we where expecting abit more i guess, but i can see it from HQ's perspective its not easy when you have alot of legacy you want to port over.
I'm going to express an opinion on Typescript (and by extension Angular 2+). This is based on my experience as a senior developer, training and mentoring junior developers, and on a whole lot of experience with JavaScript.
Typescript solves the wrong problem. I have yet to hear someone say, "the problem with Javascript is that it's a fully dynamic, extremely object oriented language without classes." Rather, The Problem with Javascript is that it's a difficult language with lots of different gotchas that will blow up in your face.
Following from there, the problem with Typescript is that it lulls people into a false sense of security with Javascript. But, when things crash down around them, they often don't have the base skill in Javascript to grok and fix the problem.
I think that if our industry is going to adopt Typescript, we need to get significantly better at training and mentoring people to write Javascript. Over the past few years, I've worked with way too many talented developers who have never written a line of vanilla Javascript. But, before our industry moves any further down the Typescript path, we need to think carefully about whether Typescript solves a problem, or whether it's just another abstraction on top of the real problem.
Clearly, I think it's an abstraction on top of the real problem. The real problem being that Javascript itself is a minefield. But, I'm open to other ideas.
I dont agree with your statement: "the problem with Javascript is that it's a fully dynamic, extremely object oriented language without classes."
This is exactly where it goes wrong usually for our juniors, they mutate stuff and it doesnt work anymore, you cant do that in typescript.
Especially as a project grows you will need your typesafety, interfaces, di setup for interceptors and what not that is hard to achieve in pure.
If you also generate stuff like providers from the api you will spend 0 time on debugging what changed from backend to frontend.
I agree that javascript is the underlying problem where its very old and have some very curious bugs which needs some senior staff to solve once in a while but by boilerplating and making a decent setup we have alleviated most of these problems we usually encountered and can more safely audit our javascript.
This is my opinion ofc im biased coming from C# webapi where stuff like angular just works out the box :)
Our industry is adopting typescript and alot of bigger companies like M$ and google swear by it so i wouldnt say it isnt adopted.
See articles like these:https://www.excella.com/insights/typescript-vs-es6-vs-es2015
You think azure and adwords would have been based on this if it wasnt mature and had alot of smart people working on it?
What i see most is the unwillingness in alot of frontenders to learn typescript cause its scary and takes time to get good at, but isnt that more an underlying problem in the frontend then, especially considering the ES6 specs?
I don't actually disagree with anything you said. Professionally speaking, I made as much money last year with Typescript as I made without. I actually like Typescript as a language and know it well. Despite liking it, I still think it will provide a negative net value to the overall industry.
In many ways, its adoption reminds me of Coffeescript. Coffeescript emerged to help Ruby developers write JavaScript in their Rails projects. Coffeescript might have been easier and it showed tremendous adoption, but at the end of the day, it still didn't solve any of JavaScript's fundamental problems. Now, we're finally starting to see Rails projects switch to ES6. I think that is an excellent move.
Typescript has a lot of good to it. But it solves problems that can be solved through solid design, thinking through a codebase and enforcing coding standards across your organization. If your team solves problems through well designed, thought out JavaScript, you gain another thing - a bunch of well trained developers who can think through all of JavaScript's minefields.
At the end of the day, this is what senior developer types need to do. Our job needs to be to turn junior developers into senior developers so we can have our heart attacks and become unintentional subsistence farmers. :)
From an overall industry point of view, that will equip the next generation of developers to adapt to a constantly changing JavaScript ecosystem.
I wonder if this difference maybe comes down to experience with dynamic languages. I have as much professional experience with dynamic languages as I have with static languages. They're dramatically different beasts, but I think that once you learn to think through, design and test projects that are written in dynamic languages, that skill will carry over to other dynamic languages.
Sorry if I'm getting a little too big picture, but teaching people to write good code has been on my mind a lot lately. I've generally used Python to teach people to write code, but lately, I've been wondering if getting them started on something static might be the answer. I was lucky enough to start with a static language, so when I finally tried a dynamic language, I got a rapid and brutal primer on type theory. Maybe that changed how my brain works through code?
Thanks for engaging with me! You're a smart cat and I look forward to learning more from you.
First of all Greg, thank you for the compliments, its very nice to have someone to talk these wild concepts with, you clearly are a gent of ample magnitude!
Apologize if i came of strong i use alot of my days on these topics :)
I have a couple of issues with the way alot of people seem to think about typescript and javascript, usually the arguement goes as you described, "but you need to know the underlying tech".
Now if that is correct why doesnt 95% (out my ass) of c# programmers know IL or Machinecode?
Eventually the compiler will be as great as the c# compiler and make very few mistakes where its not needed to know the underlying language anymore, i agree right now its needed but mostly because of poor packages being used from my experience, or wanting to force dynamic behaviour found in some shorthands.
Using a static language and di i enforce alot of coding rules from the IDE itself, the learning curve is substantial higher and speed is abit slower in the beginning but with the tradeoff of quality and test/replacability, plus easier to maintain over the long run, as the application grows.
I agree for now you need to understand javascript for typescript to compile and its abit of a struggle to get working on everything, heck sometimes you want the dynamic properties on a language :)
But seeing c# history evolve which had the same hickups along the way and what it is now where people dont need to know the underlying tech to make good use of the language , its probably not too far fetched to see typescript compile to javascript better than humans can do sometime in the future.
Or maybe webassembly just takes over who knows :D
Ive done both types aswell i still largely prefer static languages in almost any situation i encountered as a webdeveloper, but as you said this might be my bias from working mostly with static languages most of my dynamic languages being JS/node and the whole npm ecosystem(6 major versions 2 years OMG), now i prefer stuff like webapi and angular2 since most boilerplating is done for me and i spent less and less time worrying about buildprocesses/JS errors.
So are javascript programmers becoming fewer with compilers coming out, like assembly/machinecoders?
Maybe but its another beast since javascript is so simple to start off with its only when you get to a critical point in your application you need all of this stuff really.
Sorry for my wierd ramblings ill stop now, happy weekend everyone!
I wouldn't call them weird ramblings - you've thought about this a lot and you have a great understanding. You're changing my mind on a few things and making me think deeper on a lot of things. Thanks for that.
But, you brought up one of my favourite topics - I love thinking about when it's useful to know an underlying tech and when it's just an obstacle to being productive. In the case of C#, you're right. Hardly anyone who uses C# knows MSIL. I can't think of a single reason (other than extreme amounts of malice) that I'd suggest that someone learn to program in IL before they get into C#. But, I'll still hold onto my belief that to be really productive in Typescript, you've got to know JavaScript.
I think that when it comes to the C#/IL comparison, you actually have to have a base understanding of IL in order to write good C#. But, IL is highly logical so I suspect that most students would have that base knowledge by the end of primary school.
The Typescript/JavaScript comparison is a different beast because JavaScript isn't always very logical. Or more accurately, there is a logic behind it all, it's just a very particular JavaScript specific logic.
Check this out:
1 == 1 //true
1 == "1" //true
This is a really good start! Let's see what happens if we compare two objects.
[] == [] // false
That is weird, but we can deal with it. Check out:
[1] == [1] // false
[1] == -[1] // true
On its own, this isn't much more than a funny little JavaScript riddle. Lots of languages have little riddles like this. But, JavaScript is absolutely full of them. None of them are insurmountable and they can all be debugged or designed around. But when things go to hell, it's hard to know where to start debugging without a sense of JavaScript's quirks and the underlying 'logic' beneath all of them.
I'm not even sure that this is JavaScript's fault. It was originally designed in about a week, then it got caught up in the browser wars, went through all kinds of twists and turns and despite that, there has never been a release with breaking changes. That's quite impressive. And maybe a superset will become the answer, or maybe something like WebAssembly will actually take over. But, for now, it's just hard to convince people that they should console.log(x!=x) to check if x is really NaN unless they have a sense of how strange JavaScript is under the hood.
You give some great examples, this is excactly where i find an abstraction on top of javascript makes so much sense, then these things doesnt happen, atleast not in our production since we abstracted this and we know how js is handling this so we take a position on it and fix the issue and our newer frontenders never have these issues while we build on our TS library.
When issues arises like those we have our senior frontenders to take care of it, it will give a small hicup with the newer dev but usually they figure it out quite fast.
I used Dart aswell before typescript so im quite into abstracting javascript away because of issues like you mention :)
But in the end someone in our stack needs to know javascript (for now) i believe this will change with maturity of dart/TS.
I really hope stuff like webassembly could become standard instead of javascript but there is a long way to go, also javascript is excellent giving complete greenhorns a quick rundown in easy to understand code, but then having to tell them that they will need to learn a bunch of frameworks etc. to actually become efficient is sort of a turnoff, its alot better in typescript since the premise is so much better from the getgo and they can use some of that knowledge in their further work, and we usually added some framework or similar so the intro to programming is smaller and oop is enforced from the getgo.
Angular Components
Hi guys
So ive been digging abit and ive come to the conclusion components isnt working with version 1.1.5 of angular which umbraco uses, is this correct?
The "correct" way to implement features like this would be a directive then right?
Is there any plans to upgrade this in the near future, that is a very old version :)
I found this documentation: https://our.umbraco.com/apidocs/ui/#/api for already used api's but i cant find the js corresponding to this so i could see how it was done originally :)
Hi Jakob
Yup, you're correct that for now you will need to use directives.
The plan is to use AngularJS 1.7 in Umbraco 8. The upgrade is in progress, which you can see in this issue from the issue tracker here http://issues.umbraco.org/issue/U4-10928
I hope this helps :)
/Jan
Hi Jan
That hurts my heart abit that we arent going into typescript i really have come to like angular 2 with typescript and all the good parts its bring, CLI, proper intellisense, typechecking, i could imagine a bunch of usecases for umbraco, create api controllers from within umbraco and build out your frontend from pure generation have all interfaces upheld within typescript etc.
Actually you could make a documentation generator from the typescript classes present in the project and use comments to show usage of components, which is direly needed atm.
Do you know why this decision was made seems abit odd to use an old technology when making a new version of the CMS, or is umbraco 8 just an upgrade of 7 really?
Hi Jakob
Yes we all want the latest and greatest and bestet don't we? :) But the essence of it all is that rewriting the entire backoffice from scratch switching to Angular 2...or is it 6 now? Is that it's been fundamentally re-written so the concepts used in AngularJS has changed and I don't think it's a simple task to re-build it all from scratch. Now I have not got that much experience with Angular 2+ so I don't know what is possible and what is not.
Therefore I will quote Matt Brailsford thoughts on the issue from his thoughts about using VueJS in Umbraco in the future:
Everyone is of course entitled to have their own opinion on these things but I think the decision to only go up to 1.7 is the right call. If HQ should change the underlying architecture on the frontend each time a new framework is released or had a major overhaul we would never see a new major release. And also using the latest and greatest should not be the ambition the way I see it.
But don't take this as I'm saying the backoffice should never have a major rewrite or overhaul. I don't think that it can be avoided and it will happen at some point. But it's just not what is being focused on right now.
Perhaps when V8 see's daylight and plans on v9 begins to see the light. But remember that we've actually been doing quite well with the 1.15 version, which is also pretty old these days. But it's still easy to extend and bend Umbraco backoffice to your own will relatively easy to the benefits of the content editors.
Who knows maybe the next logical step would be to ditch the frameworks and rely on using WebComponents? :)
I hope some of all my ramblings above makes sense. Bottom line, it's not easy to "just" switch to Angular.
/Jan
Thank you for your answer.
I understand you cant just rewrite everything i was of the conviction that a rewrite would happen with umbraco 8 anyway since it wasnt upgradable, and this was one of the reasons to actually switch angular out with something else, i wouldnt mind vue.js either its not my favorite but i can see the advantages for templating, its like a hotreplace.
This for sure will affect our use of umbraco 8 we where expecting abit more i guess, but i can see it from HQ's perspective its not easy when you have alot of legacy you want to port over.
I'm going to express an opinion on Typescript (and by extension Angular 2+). This is based on my experience as a senior developer, training and mentoring junior developers, and on a whole lot of experience with JavaScript.
Typescript solves the wrong problem. I have yet to hear someone say, "the problem with Javascript is that it's a fully dynamic, extremely object oriented language without classes." Rather, The Problem with Javascript is that it's a difficult language with lots of different gotchas that will blow up in your face.
Following from there, the problem with Typescript is that it lulls people into a false sense of security with Javascript. But, when things crash down around them, they often don't have the base skill in Javascript to grok and fix the problem.
I think that if our industry is going to adopt Typescript, we need to get significantly better at training and mentoring people to write Javascript. Over the past few years, I've worked with way too many talented developers who have never written a line of vanilla Javascript. But, before our industry moves any further down the Typescript path, we need to think carefully about whether Typescript solves a problem, or whether it's just another abstraction on top of the real problem.
Clearly, I think it's an abstraction on top of the real problem. The real problem being that Javascript itself is a minefield. But, I'm open to other ideas.
I dont agree with your statement: "the problem with Javascript is that it's a fully dynamic, extremely object oriented language without classes."
This is exactly where it goes wrong usually for our juniors, they mutate stuff and it doesnt work anymore, you cant do that in typescript.
Especially as a project grows you will need your typesafety, interfaces, di setup for interceptors and what not that is hard to achieve in pure.
If you also generate stuff like providers from the api you will spend 0 time on debugging what changed from backend to frontend.
I agree that javascript is the underlying problem where its very old and have some very curious bugs which needs some senior staff to solve once in a while but by boilerplating and making a decent setup we have alleviated most of these problems we usually encountered and can more safely audit our javascript.
This is my opinion ofc im biased coming from C# webapi where stuff like angular just works out the box :)
Our industry is adopting typescript and alot of bigger companies like M$ and google swear by it so i wouldnt say it isnt adopted.
See articles like these:https://www.excella.com/insights/typescript-vs-es6-vs-es2015
You think azure and adwords would have been based on this if it wasnt mature and had alot of smart people working on it?
What i see most is the unwillingness in alot of frontenders to learn typescript cause its scary and takes time to get good at, but isnt that more an underlying problem in the frontend then, especially considering the ES6 specs?
Jakob,
I don't actually disagree with anything you said. Professionally speaking, I made as much money last year with Typescript as I made without. I actually like Typescript as a language and know it well. Despite liking it, I still think it will provide a negative net value to the overall industry.
In many ways, its adoption reminds me of Coffeescript. Coffeescript emerged to help Ruby developers write JavaScript in their Rails projects. Coffeescript might have been easier and it showed tremendous adoption, but at the end of the day, it still didn't solve any of JavaScript's fundamental problems. Now, we're finally starting to see Rails projects switch to ES6. I think that is an excellent move.
Typescript has a lot of good to it. But it solves problems that can be solved through solid design, thinking through a codebase and enforcing coding standards across your organization. If your team solves problems through well designed, thought out JavaScript, you gain another thing - a bunch of well trained developers who can think through all of JavaScript's minefields.
At the end of the day, this is what senior developer types need to do. Our job needs to be to turn junior developers into senior developers so we can have our heart attacks and become unintentional subsistence farmers. :)
From an overall industry point of view, that will equip the next generation of developers to adapt to a constantly changing JavaScript ecosystem.
I wonder if this difference maybe comes down to experience with dynamic languages. I have as much professional experience with dynamic languages as I have with static languages. They're dramatically different beasts, but I think that once you learn to think through, design and test projects that are written in dynamic languages, that skill will carry over to other dynamic languages.
Sorry if I'm getting a little too big picture, but teaching people to write good code has been on my mind a lot lately. I've generally used Python to teach people to write code, but lately, I've been wondering if getting them started on something static might be the answer. I was lucky enough to start with a static language, so when I finally tried a dynamic language, I got a rapid and brutal primer on type theory. Maybe that changed how my brain works through code?
Thanks for engaging with me! You're a smart cat and I look forward to learning more from you.
First of all Greg, thank you for the compliments, its very nice to have someone to talk these wild concepts with, you clearly are a gent of ample magnitude!
Apologize if i came of strong i use alot of my days on these topics :)
I have a couple of issues with the way alot of people seem to think about typescript and javascript, usually the arguement goes as you described, "but you need to know the underlying tech".
Now if that is correct why doesnt 95% (out my ass) of c# programmers know IL or Machinecode?
Eventually the compiler will be as great as the c# compiler and make very few mistakes where its not needed to know the underlying language anymore, i agree right now its needed but mostly because of poor packages being used from my experience, or wanting to force dynamic behaviour found in some shorthands.
Using a static language and di i enforce alot of coding rules from the IDE itself, the learning curve is substantial higher and speed is abit slower in the beginning but with the tradeoff of quality and test/replacability, plus easier to maintain over the long run, as the application grows.
I agree for now you need to understand javascript for typescript to compile and its abit of a struggle to get working on everything, heck sometimes you want the dynamic properties on a language :)
But seeing c# history evolve which had the same hickups along the way and what it is now where people dont need to know the underlying tech to make good use of the language , its probably not too far fetched to see typescript compile to javascript better than humans can do sometime in the future.
Or maybe webassembly just takes over who knows :D
Ive done both types aswell i still largely prefer static languages in almost any situation i encountered as a webdeveloper, but as you said this might be my bias from working mostly with static languages most of my dynamic languages being JS/node and the whole npm ecosystem(6 major versions 2 years OMG), now i prefer stuff like webapi and angular2 since most boilerplating is done for me and i spent less and less time worrying about buildprocesses/JS errors.
So are javascript programmers becoming fewer with compilers coming out, like assembly/machinecoders?
Maybe but its another beast since javascript is so simple to start off with its only when you get to a critical point in your application you need all of this stuff really.
Sorry for my wierd ramblings ill stop now, happy weekend everyone!
Hi Jakob,
I wouldn't call them weird ramblings - you've thought about this a lot and you have a great understanding. You're changing my mind on a few things and making me think deeper on a lot of things. Thanks for that.
But, you brought up one of my favourite topics - I love thinking about when it's useful to know an underlying tech and when it's just an obstacle to being productive. In the case of C#, you're right. Hardly anyone who uses C# knows MSIL. I can't think of a single reason (other than extreme amounts of malice) that I'd suggest that someone learn to program in IL before they get into C#. But, I'll still hold onto my belief that to be really productive in Typescript, you've got to know JavaScript.
I think that when it comes to the C#/IL comparison, you actually have to have a base understanding of IL in order to write good C#. But, IL is highly logical so I suspect that most students would have that base knowledge by the end of primary school.
The Typescript/JavaScript comparison is a different beast because JavaScript isn't always very logical. Or more accurately, there is a logic behind it all, it's just a very particular JavaScript specific logic.
Check this out:
This is a really good start! Let's see what happens if we compare two objects.
That is weird, but we can deal with it. Check out:
On its own, this isn't much more than a funny little JavaScript riddle. Lots of languages have little riddles like this. But, JavaScript is absolutely full of them. None of them are insurmountable and they can all be debugged or designed around. But when things go to hell, it's hard to know where to start debugging without a sense of JavaScript's quirks and the underlying 'logic' beneath all of them.
I'm not even sure that this is JavaScript's fault. It was originally designed in about a week, then it got caught up in the browser wars, went through all kinds of twists and turns and despite that, there has never been a release with breaking changes. That's quite impressive. And maybe a superset will become the answer, or maybe something like WebAssembly will actually take over. But, for now, it's just hard to convince people that they should console.log(x!=x) to check if x is really NaN unless they have a sense of how strange JavaScript is under the hood.
You give some great examples, this is excactly where i find an abstraction on top of javascript makes so much sense, then these things doesnt happen, atleast not in our production since we abstracted this and we know how js is handling this so we take a position on it and fix the issue and our newer frontenders never have these issues while we build on our TS library.
When issues arises like those we have our senior frontenders to take care of it, it will give a small hicup with the newer dev but usually they figure it out quite fast.
I used Dart aswell before typescript so im quite into abstracting javascript away because of issues like you mention :)
But in the end someone in our stack needs to know javascript (for now) i believe this will change with maturity of dart/TS.
I really hope stuff like webassembly could become standard instead of javascript but there is a long way to go, also javascript is excellent giving complete greenhorns a quick rundown in easy to understand code, but then having to tell them that they will need to learn a bunch of frameworks etc. to actually become efficient is sort of a turnoff, its alot better in typescript since the premise is so much better from the getgo and they can use some of that knowledge in their further work, and we usually added some framework or similar so the intro to programming is smaller and oop is enforced from the getgo.
Thank you for engaging :)
is working on a reply...