I don’t give a fig if the IDE is Electron or Shmelectron so long as it works. Full screen if you can’t turn if off is an annoyance but not an obstacle. It doesn’t surprise me that a tool that builds atop .NET would want you to install .NET. As for the OAuth stuff … I’m sure it’s early days. These things in and of themselves don’t perturb me; I would want to build a fairly capable CRUD app with it, without it getting in the way. That would be my criteria.
Right now I am using old fashioned WinForms for any new admin tools, nursing along a Xojo app for the old ones. At some point being able to deploy these in a browser would be handy but TBH these apps should only be used by a handful of trained personnel (maybe a grand total of 3 people) so requiring them to log into a VPC to run the app isn’t a bad idea.
But eventually they may want it in the browser and this is one way I might do it without turning it into a Manhattan Project.
What would of course be ideal is something that an Israeli company attempted with mixed success a few years ago – I forget the name but basically you could take a WinForms app and compile it into a web app by just swapping out some System.Windows.Forms libraries for theirs. It had somewhat limited (and at times buggy) support for controls but as a proof of concept it worked. It just would have required a bigger company (they were no bigger, possibly even smaller, than the Green Ones, although way more technically capable overall) and more resources to mature it properly.
And yes it worked without having massive scaling issues. IIS configuration was fussy, but once you had it right, it wasn’t sending a bazillion messages back and forth between client and server.
I wish that thing had survived but there just wasn’t enough of a user base for them to bootstrap it with the funding they had. The company got a lucrative contract doing something less challenging and just abandoned the product.
Oh React is not a bad thing, but it’s not special either. I’ve got a book here on React that I’ve read cover-to-cover, but I’ve still never been able to create anything meaningful with it. Every time I’ve thought “I know exactly how I’ll approach this problem” when I actually sit down to write the code, I just draw a blank.
But if you think Xojo’s API 1 vs API 2 situation is a mess… oh boy wait until you see what React has done. You can use functional components or class components. Class components are better organized, but can’t do everything functional components can. One used to be the recommended technique, now the other is - I can never remember which - and so you’ll almost always find tutorials for whichever style you’re not using.
And the naming… so unintuitive. Want to update the component after it has been drawn on screen? Is that a post-render function? Should you put that in componentDidLoad? No, you want something called an effect. Why did they name it effect? Fuck if I know.
As you can tell, I don’t like React. I know lots of people do, but from what I’ve seen, it’s JavaScript taken to the extremes. It’s nonsense on top of nonsense on top of nonsense. I like that everything is just a bunch of self-contained reusable components stacked on top of each other. In the Xojo world, imagine having a container control that only contains a button. Then another that contains two of those containers for ok and cancel. Everything is its own separate little piece. That’s about the only thing I like about it.
So yeah, React isn’t really a bad thing because I know React is popular. But to me, it’s a real turn off.
I could never wrap my head around React, Symphony, etc. It might be due to MVC. I really want to use MVC, but in the end it feels super detached, which I guess is a feature.
I would say that about a god-awful lot of web technology. It is mud thrown at the side of a barn. None of the abstractions work for me to actually focus on getting things done for the client. Everything is a regrettable compromise to accomplish a shotgun wedding of technologies that were never originally meant to work with each other. This is why what we get from big tech (MSFT, Oracle, Apple, et al) more often than not is what we have to live with because it takes an 800 pound gorilla to force all the pieces together and then since you can’t just run off to a small vendor with better ideas and be taken seriously and they know it, they just let the abstractions leak without any shame or desire for pride in craftsmanship or elegance whatsoever. Bugs just lay there unfixed for years. Useful and perfectly working functionality is removed from a product because of the perception that not enough users care about it and they don’t want to maintain it (e.g., the ability to step through SPs in SSMS). New and improved abstractions displace old and lousy ones, serially, and you can never be sure that something you have a hard-fought understanding of will even be viable throughout the lifetime of any given project.
The only hope are tools like this Radzen that a least build atop some “accepted” infrastructure and hopefully make some default decisions you can live with to clear the cobwebs away. Done right, such tools abstract away some of the learning curve and smooth out the wrinkles for you provided you can live with the up-front assumptions they make or hope they have more configuration points in the future.
Lol … I didn’t have Xojo in mind but yeah even at MSFT on occasion they can’t make up their minds. For example when it comes to remote procedure calls, is it .NET Remoting, Windows Communications Framework (WCF), or gRPC and Web API? What will it be next year? Who knows! But the difference is that at least WCF will supposedly be supported enough more or less forever that it will continue to work, at least on Windows. I think that’s even true of .NET Remoting, which went out of favor at least a decade ago. But I tend to write systems that endure for 10 to 20 years and so I’m looking over my shoulder more than some folks I guess.
I’d be less annoyed if each of these protocols were simpler than the last, but it’s the inverse.
If Xojo simply supported what they pushed out over the years no one would be so upset with them
They’ve said API will be present for along time - but supported ? improved ? bugs fixed ? I dont recall any such statements beyond API 2 is the future and you should update as you revise your code kinds of statements
Which really doesnt work well as if you update a Window & make it a “DesktopWindow” you’ve opened a nasty can of worms. I’ve given up trying to do that and not have to convert every control as well & just move everything if a client asks - or change NOTHING
It doesnt mix & match nicely at all
At least MS, when they do push something out, DOES realize that someone used it and it needs maintenance and only after a VERY long period pulls the plug
hell VB 6 still works on Windows 10 (haven’t tried Windows 11) and apps made in it are “supported” for a long time still
what is nothing special because Windows is nothing but a pile of legacy hidden beyond eye candy. The Foundations of Windows are quite untouched since the 1990ies. I invite you to a (horror) trip back in time, enjoy!
When it comes to building app in React I as a UI designer to build the layouts in Figma and then I use Dhiwise to convert them to a working React project. this way we save a lot of time.
I also presonally avoid using it where possible. But the need arises the I prefer to use Dittofi as it gives me the best of both worlds. I can build the app visually and the code it generates in in Go so I get blazing fast web apps that use very little resources.
none of those examples show what it takes to create a NSWindow class , or add controls, events etc. This process while similar to iOS can be quite different. Currently I use “Xojo2Swift” to build a basic template app, it takes a 2019r1.1 API1 GUI (just the GUI and events), and writes a proper XCode project file. from that I manually tweek, and modify. I wrote this app, as well as the extensive Swift framework needed to support it.
Currently I am working on a newer version (that won’t use Xojo in any way shape or form), and will be a GUI builder that will create Xcode projects for macOS, iOS (iPhone and iPad) as well as tvOS (AppleTV)
Note : Swift Desktop examples are few and far between… 99.9% are iOS
Well I’ve been playing with Radzen a bit in my “spare” time
TBH Its pretty slick so far
Certainly makes drag & drop web app editing possible
And it based on .Net (6 or 7) both of which I’ve found to be very solid
OH ! And this IS a Mac app generating a .Net app
Best part is that you can design, alter the underlying code, and the design changes on the fly
So you can write code for the layout IF thats your thing
Or not
(oh and you can CODE graphically , in split mode where you see code & graphical code, or just plain text - see below)
It does rely on responsive row & columns layout so its not quite “drag & drop anything any where” but since it build code that is responsive thats not a terrible thing
The apps are basically mobile friendly from the get go
I used the Radzen Studio around the time when web 2 came out, it was really buggy and with a lot of less features. The new Radzen Blazor Studio look like a big leap
How does Radzen Blazor Studio relate to Microsoft Blazor? Is it “just” an $800 designer? Best I can tell, that’s what it is. I haven’t kept up on this stuff. But I guess my concern in the long run is I have no guarantee Microsoft won’t give up on this like they’ve done so many times in the past.
