I disagree about that point. This "integrated seamlessly", would likely have to be to make JavaScript, HTML, and CSS virtually invisible. It appears to me as something very difficult to pull off. Even in the case of Smart Pascal or pas2js, there will be conflicts between the desktop and web technologies or languages involved, where the user has to have web developer type knowledge to solve. It then creates a conflict of having to jump over one side of the fence or the other. Where the Delphi approach limits such issues. You are more focused on targeting the OS, and web technologies are not on the radar, unless that is what the user is focusing on.
You also have the same conflict in Delphi. Firemonkey is a completely different framework that is completely incompatible with the VCL. If you come from the VCL things like layouting or styling of Firemonkey applications are completely different. A web technology based framework for GUI development would be similarly not compatible with the LCL as Firemonkey is not compatible with the VCL.
Of course with things like pas2js the difference is a little bit larger, as the underlying web technology completely alters some of the behavior of the code (e.g. that every object in pas2js is internally a javascript object and therefore basically a dynamic dictionary).
But a more pressing issue here is that the existing packages and libraries, if they aren't pure high level algorithmic, would probably not work (i.e. everything that contains API calls or something similar). But there is also an alternative to that. The Webapp solutions, like react, allow to bind the javascript code against native libraries. So a solution that is similar to LAMW could be implemented, where the interface is build using web technology, and the pascal code is compiled to a native library, where then wrappers are used for hooking up the GUI controls to the underlying pascal code.
Basically you could build the same thing as Firemonkey, but rather than having an OpenGL rendering interface drawing all the UI, use the browser to render the UI. This would in the long term potentially even be less effort to develop and maintain than Firemonkey is.
Something like that could potentially even be implemented as an LCL widgetset.
But with this discussion I think we are loosing ourselves in hypotheticals, which, while neat to think about, are simply out of reach due to the massive development it would take. A more reasonable and archivable approach here, and what I want to experiment on somewhen I have a little bit more free time, would be to simply use Pas2JS with cordova to develop cross plattform apps, that simply use Pascal as a language, but are not necessarily compatible with the usual FreePascal/Lazarus ecosystem.
I think the web technology based approached works better with people who have advanced web development backgrounds, who are then targeting the desktop. Keep in mind that JavaScript is a "3 or more for 1" package deal, that includes HTML and CSS. Where the Delphi approach would arguably be better for those that are coming from desktop based or Pascal backgrounds. To include those that primarily interface or work with the desktop and desktop apps, such as IT professionals, workers at various businesses, etc...
Not necessarily. You could easiely build a framework that hides all the HTML and CSS, the same way the LCL hides the underlying technology through the widgetset system
I personally would preferr to have HTML and CSS because it is simply more powerful than the conventional GUI editors you have, e.g. in Lazarus. If I want to have a custom tyled checkbox, I basically have to implement the drawing code myself using the Canvas. With HTML/CSS I can simply use CSS to edit everything about the appearance without having to implement the drawing algorithms myself.
Thats for example also the reason why the QT or JavaFX libraries for GUI development chose to implement CSS for styling of the GUI components, even though it is not even build on web technology.
Well, part that is opinion, and another part is how Delphi has implemented it. Add to that, the FireMonkey framework is something that Delphi bought and then integrated, versus developed themselves. As with anything else, it can improve with each new version.
Yes, the thing I think was the single bad design decision with Firemonkey was, to implement everything new from scratch. The advantage of using web technology is that already all of the hard stuff is made for you. HTML and CSS are already doing exactly what Firemonkey wants to do, they are a technology for building GUIs that are able to adept to any screen and resolution dynamically, utilize all the different forms of user input and allow for a high degree of configurability.
The web is the single most well tested technology on the planet. Around half of all humans have access to the internet, using HTML+CSS powered websites for potentially hours a day. All of this experince is considered by expert comitees developing and refining the webstandards over the past decades.
HTML and CSS engines are freely available under OpenSource licenses. Engines like Blink or V8 (as part of Chromium) are also some of the most well tested and optimized pieces of software in existance.
Firemonkey basically tried to implement the very same thing from scratch. Of course it will be worse, how couldn't it be. Don't get me wrong Firemonkey is actually quite good, you can see and feel all the developer hours that went into it. It's just that it is still worlds apart from the state where webtechnology is. Both from the implementation and optimization, but also from the usability.
Software requires time, development time and testing time to get better. When I started using Lazarus in version 0.xx it was much worse then it is now, simply due to more development effort, refinments and more users giving feedback. The same is true for Firemonkey it tries to do basically the same as the already existing web technology does, just that the web technology is 30 years ahead in the devlopment cycles.
One thing in programming is that one should not try to reinvent the wheel. IMHO Firemonkey could have been much better if they would have just said, rather than trying to implement everything themselve, to just use a browser for the whole rendering and stuff. They could have completely abstracted from the underlying technology, build all the Pascal component structure underneath like people know it from the VCL, but just rather than trying to write their own styling and rendering engine, use what has already proven itself and stood the test of time.
I very much agree with you. I think this is where a bit of uneasiness about LAMW comes in, despite it being such a great initiative and project. It's like solving one part of the equation, but not the other. But, it's what is out there. Better there is an Android solution, then none.
Preferably, there be a solution for both Android and iOS. Except to me, and acknowledging the present situation, even if Lazarus had two totally different solutions then that would be better. If there is Laz4Android, which is totally different from Laz4iOS, at least both exist. Though even in that scenario, I do think there would be a significant level of cross-over and concepts.
Some years back, it looked like Lazarus users/independent developers were making iPhone apps and did a significant amount of work towards an iOS solution. Oddly, whenever it looks like an iOS solution is about to come together (to a LAMW level), it seems to get abandoned. Example, from Simon Choi, https://blog.naver.com/simonsayz/221209784815.
Sure having LAMW is nice, and defenetly better than not having it. Back when I used it I was quite amazed that this rather hacky solution was easier to use than the official android studio
But what I think is that at some point, if Lazarus wants to compete with other solutions, not just Delphi but also things like Xamarin, QT, React or others on the mobile market, there needs to be an integrated solution. And I think utilizing the widgetsets and sticking to the "write once compile anyhwere" approach of the existing lazarus ecosystem would be the best solution here.
Because to be honest, I really like using Lazarus, and if I have to write a GUI application for Windows or Linux it is usually the development environment of choice. But if I had to develop a mobile app, even if there was an Laz4iOS and both LAMW and Laz4IOS would both be of great quality, I would not chose lazarus, because even though I like it really, I would not want to do twice the effort for building the same app against two different frameworks, if there exist solutions out there which let me do it in one.
Imagine pitching this to a customer: "Yes, ok I am going to develop the Android and iOS app, but it will cost you twice as much because the technology I am using requires to build evrything from scratch for each system". If I where that customer, I would simply ask why you would use this technology over the alternatives that don't require twice the effort. And most customers would probably then rather hire someone using the technology that doesn't cost them twice as much for the same work