Closed volkanceylan closed 8 years ago
I think it is a great idea, to be honest. I hate to say it but Saltarelle has been a pain, mainly because I've learned nearly as much, if not more, about how to use it by studying your imports than their documentation provides. There seems to be extremely little learning resources, and it feels like I'm stuck trying to use it. TypeScript will be a much easier learning curve for many people especially with already having JavaScript experience. Before I found Serenity I was trying to create this very app using React, Redux, Express, Node and MySQL. It was a pain, and I was thrilled to dump it, but the mindshare online around JavaScript is incredible. It may help to boost the popularity of our small community too.
If there is any way I can help I would love to. I have posted to the .NET subreddit and want to see this community grow and contribute however I can. I'm still a "junior" developer - pretty much entirely self-taught. I don't know what I can do to be of help, but if there is anything let me know.
I think that is probably the way forward. Agree with all your points about Saltarelle; having that as a dependency is a big risk for Serenity anyways. At least moving to TypeScript you'll have a lot more direct control.
My opinion on the subject is summed up by one of the last statements of @volkanceylan: "If it is working do not fix it". I know it sounds simplistic, but the truth is that we are thinking hypothetically ... I'm not a fan of Saltarelle nor even look kindly the acquisition by Bridge.NET, but we should at least give them the benefit of the doubt before you dismiss it. Probably TypeScript will be the future of Serenity for all the reasons that has exposed @volkanceylan and also because certainly the support and resources that Microsoft can / will invest are not comparable to those of Bridge.NET (with all respect), but nevertheless I think that at the moment there are not enough reasons to justify a "migration" of this magnitude.
Anyway thanks for asking our opinion!
Best Regards
Let's switch to typescript.
Thanks to all for ideas, i'll keep this topic open to hear more.
@jsbUSMC, thanks, you're trying to help others here often, so its good enough as contribution. Saltaralle is not a pain, actually i think Erik Kallen did an excellent job, it has 5000+ tests, but yes docs are missing, i would help with that part.
@wldkrd1, i'm actually not so concerned about risks. Saltarelle is open source, so i might fork it and do little changes if something goes bad, np. I'm thinking more about "which will be better".
@marcobisio, yes i agree. Another way is two make it optional, choose Typescript / Saltarelle in Sergen for example. I'm just not sure how long i can keep developing two separate architectures in parallel.
Ok, @VictorTomaili then you are gonna write typescript importer ;)
@volkanceylan hahah :D i will soon
To be honest I'm new to website design. I come from a background of self-taught C# and have only experience in WPF applications. The Serenity Platform has introduced me into an entirely new world of programming and I'm excited about it! So thank you guys for that.
I'm new to the world of Saltarelle and I'm not really sure how it works with the application fully just yet. Still have to study the template and see how things match up.
So if TypeScript is going to be the future of how the platform is going, I say go for it. Once you decided to go tot TypeScript how will that affect current sites deployed under the Saltarelle code base? Will it be a breaking change resulting in either building an entirely new website or? I'm still learning so bare with me lol
I am thinking this before for this reason
It feels like natural javascript with proper refactoring / intellisense / compile time checking
@marcobisio, yes i agree. Another way is two make it optional, choose Typescript / Saltarelle in Sergen for example. I'm just not sure how long i can keep developing two separate architectures in parallel.
If I've learned anything in these almost 10 years of work, is that replicate / duplicate things is not only prone to error, but also a major cause of headaches! Personally, although not a supporter of immediate swich to TypeScript, I still prefer the idea of a complete migration rather than a hybrid solution ... Between asphalt and dirt track road, I prefer to choose the dirt one rather than try to take them both and end up on the road signs :D
Once again, thanks for asking our opinions. Best Regards
@wdhodges It won't affect existing applications using Saltarelle as i can't also afford this. They both transpile to javascript, so in the end they are kinda compatible. Saltarelle has some non-standard behavior for generics, class hierarchy, type checking at runtime etc. so some compability layers between two might need to be developed.
Just to add my own 5 cents in this, and I am by no means a advanced programmer, I'd say you'd want to try to go with something that is most likely to have a long term, fluid support and development.
The reason why I say this is that if you continue with Saltarelle and then Bridge.Net decide they don't really like what they are getting anymore and decide not to support it anymore, which happens often with new acquisitions, they'll be more likely to drop the support and then you'll be forced to do the transition at that time. At the same time, since it is a recent acquisition it is also more likely they'll try to bring out a version with a ton of bells and whistles which could make for more functionality in an attempt to ramp up the client base.
From what I've been reading on "Bridge.Net 2.0" it appears that they are planning on making it TypeScript Compatible so it may not be such a bad idea to start redesigning the code in a more TypeScript manner since you'll have the ability to maintain Bridge.Net 2.0 functionality if it turns out to be the better option. Also, if they are willing to become compatible to the competition, then that means even they see the growing trend with TypeScript. That could be their backup plan; to transition to a TypeScript-ish design.
Additionally, you'll have the opportunity to review the code in a different perspective which may help make it slimmer and more adept since you've been looking at it the same way for so long. A change of perspective may not hurt.
I'd say my vote is for TypeScript simply because it holds a longer-term support probability with more, better supported, documentation.
I also wouldn't worry too much about loosing your base since you've developed a phenomenal design that can only keep getting better. I may have only found you a few months ago, but I do know I am not going anywhere. I like and see a lot of promise with your design and I'm actually excited to see how things will continue to change, regardless of the growing pains. You maintain communication, you are approachable for for help and you do excellent work. What you have accomplished so far speaks for itself.
I may not be much but I also offer my services to help in any way possible if you ever need help.
Side Note: From what I see, they originally, wanted to try to get 2.0 out by end of last year and they are scrambling to get something running. They supposedly had an open Beta though. Do we know anyone who may have taken part in it?
"we are gathering a list of users who are willing to test a private Bridge 2.0 Beta build, which will be available on-or-about the end of July 2015."
Here is some update and proof of concept for TypeScript / Saltaralle interop:
In ts-experiments branch, i have a working customer dialog written in TypeScript that works alongside other Saltaralle code:
namespace Serene.Northwind {
import D = Serenity.Decorators;
@D.formKey("Northwind.Customer") @D.idProperty("ID") @D.nameProperty("CustomerID")
@D.service("Northwind/Customer") @D.flexify() @D.maximizable()
export class MyCustomerDialog extends Serenity.EntityDialog<CustomerRow> {
}
}
Of course there are some syntax differences but i think not much. Here is same thing in Saltarelle:
namespace Serene.Northwind
{
[FormKey("Northwind.Customer"), IdProperty("ID"), NameProperty("CustomerID")]
[Service("Northwind/Customer"), Flexify, Maximizable]
public class MyCustomerDialog : EntityDialog<CustomerRow>
{
}
}
Also a custom formatter in TypeScript:
namespace Serene.Northwind {
export class MyBoldFormatter implements Slick.Formatter {
format(ctx: Slick.FormatterContext): string {
return "<b>" + Q.htmlEncode(ctx.value) + "</b>";
}
}
}
I have better hope now to not break much while offering TypeScript as an alternative option.
If all goes well, my next idea is to write an alternative version of Serenity server side on Node.js with TypeScript.
Node is interesting. Any idea what server frameworks to use? Express is normally the default/go-to, but I think that Koa is a very nice alternative, because it has nice built-in use of the JavaScript generator function: *function() { ... }
which allows for yield
statements using ES6.
I don't have much experience with node for server apps, actually hear about Koa first time ;) Anyway node version is several months away to start and will have enough time to discuss with more experienced ones like you.
Focus is now on typescript. First tried to write a poor mans parser for TypeScript. It looked like worked but couldn't be sure if it will work for all cases so now switched to calling original typescript services using chakra to parse .ts files and generate formatters / editor imports server side.
Serenity 2.0.0 Nuget packages with TypeScript support has just been published. Should wait for Serene release tomorrow and migration guide. It will take some time for it to stabilize, as there has been so many changes underneath. Please test and let me know.
Make sure you install TypeScript 1.8 before updating, otherwise you'll have many errors in VS.
Here is migration guide for old projects:
For new projects, just download latest Serene.
An impressive job! I'll try the migration in the next weeks... Once again. thanks for sharing with us your wonderful template!
For some time, I'm considering about switching to TypeScript from Saltarelle for client side code.
I would like to hear what you think about this change. First, rationale behind this:
Current Situation with Saltarelle
Why TypeScript:
Advantages of Saltarelle
Changes and Compability Considerations
There may be some points i missed. I'd like to hear your ideas. Thanks.