Lazarus
Programming => Networking and Web Programming => Topic started by: Gustavo 'Gus' Carreno on April 04, 2021, 09:58:34 pm
-
[Debate Split from https://forum.lazarus.freepascal.org/index.php/topic,44525.0.html]
Hey all,
I quite understand the feeling of all my fellow programmers who want to chase the current status quo of development, the web.
I even understand the ones that fall into the FOMO aspect of things.
I do, don't get me wrong, I do.
What puzzles me is that, even with all this trend to have apps in HTML5+CSS+JS, independent of what generates it, we're seeing a trend to have the newly minted moniker of "Desktop Apps" based on Electron.
Am I that old that, to me at least, the new is just imitating the old, and we're almost full circle into realizing that native compiled "Desktop Apps" should be the way to go?
Is it just me, or is it that because JavaScript devs have been given a hammer they think all solutions are nails?
I dunno, what do you think?
Cheers,
Gus
-
Hey all,
I quite understand the feeling of all my fellow programmers who want to chase the current status quo of development, the web.
I even understand the ones that fall into the FOMO aspect of things.
I do, don't get me wrong, I do.
What puzzles me is that, even with all this trend to have apps in HTML5+CSS+JS, independent of what generates it, we're seeing a trend to have the newly minted moniker of "Desktop Apps" based on Electron.
Am I that old that, to me at least, the new is just imitating the old, and we're almost full circle into realizing that native compiled "Desktop Apps" should be the way to go?
Is it just me, or is it that because JavaScript devs have been given a hammer they think all solutions are nails?
I dunno, what do you think?
Cheers,
Gus
Is not only JavaScript. Is that you get a better styled application.
Try to make all the components a web can offer, I think you can't and also me that did some bgracontrols for LCL can't.
Animations, full HighDPI Support without problems, scalable graphics, internationalization. All made really simple without the need to compile, just reload the app in the fly. That's faster developed stuff in less time. Every time you hit compile in the Lazarus IDE I already I'm viewing the changes I did in the live reload website.
The same is going for Android with Flutter live reload.
Of course for low level stuff and limited hardware is not good, there is the place for Lazarus. But for the rest I don't see the point of not using HTML+CSS+JS.
-
Hey lainz,
Is not only JavaScript. Is that you get a better styled application.
Try to make all the components a web can offer, I think you can't and also me that did some bgracontrols for LCL can't.
Let me see if I understand your point: Unless someone can do the presentation layer the way a browser can, we're stuck with something subpar on the logic layer, but hey, we have a magnificent presentation layer, right?
Animations, full HighDPI Support without problems, scalable graphics, internationalization. All made really simple without the need to compile, just reload the app in the fly. That's faster developed stuff in less time. Every time you hit compile in the Lazarus IDE I already I'm viewing the changes I did in the live reload website.
Yeap, you bet it's made simple, well kinda right?
No one is using pure JavaScript, right? How many frameworks are there after jQuery got out?
How flat or steep is the learning curve for those frameworks?
Of all these frameworks and shiny things, how many standards have emerged? None?
Of all those frameworks that have died, how much code can we build upon to make it better without having to re-invent the wheel? None?
But hey, let's sacrifice standards and OS supported API's because... How did you say it? Ah yes "Is that you get a better styled application."
And then you say "That's faster developed stuff in less time. Every time you hit compile in the Lazarus IDE I already I'm viewing the changes I did in the live reload website.".
I admit that the false sense of productivity that an interpreted language gives you feels real. But it's not!!
But explain to me how is that most of the interpreted languages are now trying to ditch the dynamic types in favour of static types, you know, like TypeScript and even the newest of PHP(8 and up)?
Well, it's probably because someone has finally understood that the immediate reward of pressing F5 on a Browser is crap when a client is on the phone every 5 minutes because their site is down because of a stupid mistake due to dynamic types. And then no one can find out to fix it because they don't think about dynamic types. Do you want me to link to the widespread hilarious examples of that in JavaScript?
The fact that when you have static types, you have less error prone code out of the gate.
The fact that the coder that falls for the rapid reward of F5, won't implement tests and while it looks good, it performs like crap.
Should I go on?
The same is going for Android with Flutter live reload.
So the main issue is that we need to evolve the widget set into something more HMTL5+CSS and replace the JS with a compiled language, Dart...
So you agree with me under the condition that we have a dynamic presentation layer that comes from a server somewhere.
So again, you're focusing on the presentation layer. Why is the presentation layer that important?
And what happens when the compiled part of that can't cope with the dynamic presentation layer? Don't we have to swap that?
Of course for low level stuff and limited hardware is not good, there is the place for Lazarus. But for the rest I don't see the point of not using HTML+CSS+JS.
Well, if you give me a solution where someone invents a widget set that can be made by pure HTML5+CSS and then we just have to attach the same events to ObjectPascal instead of JS, will you be happy?
You see, at the moment the HTML5+CSS+JS widget set landscape is a bit of a wild west.
There are no standards. There are no widget sets per se. There's a new framework being invented every day.
I've lived through jQuery. Then it was, what? <insert list of JS frameworks that have been popular since jQuery and ending in Vue>. When is this wild west gonna end?
With all this early adopter and AHHH SHINY attitude it's a no brainer that clients aren't really adopting it. On the contrary, they're getting quite frustrated that past 1 year, their website isn't maintainable because the fad is gone and no one wants to update "yesterday's code".
In comparison, in the present, we have the Windows widget set, GTK, QT and KDE. That's 4 sets, over a period of how many years?
My whole argument is that you shouldn't tear the whole house down just because the presentation layer needs a revamp.
And the Browser is getting to the point where it's being used like the Java or .NET runtime. But without the speed or optimizations of a programming language!!
And if you base all your coding in a binary that you need to carry around but is crap at speed and memory management, is the presentation layer THAT important?
Cheers,
Gus
-
Hey egsuh,
1) separate server-side work and client-side work first. Or separate purely logical modules and those which need form or visual control elements. Try to use interfaces to access procedure/functions, even though you can directly access procedures/functions in another module.
2) Define the communication rules between server and client, considering HTML server.
3) Separate two programs - server and client, and try to connect from client to server using THTMLclient. You may use synapse, etc.
4) Think of moving client-side forms to HTML/CSS/Javascript.
Please correct me if I'm wrong in this attempt of mine to generalize and use some technical terms:
Use an MVC abstraction where you have a server side and a thin client.
The server implements the M(Model) and the C(Controller) while the thin client takes care of the V(View).
The thin client can be a Browser or a purpose built one.
Connect the server and the thin client via the HyperText Transport Protocol(HTTP) using some kind of standard like XML or JSON.
Am I getting this right?
If so then why use Lazarus at all?
As professional programmers, don't we agree we should use the best tool for the job at hand?
If the whole thing is based in MVC, isn't RubyOnRails the best option?
Or if you don't like Ruby, why not CakePHP?
Laravel?
Anything that's been used for web in the past 15 years and with a humongous community and a shit tone of documentation?
Aren't those the arguments we should look at when deciding what tool is better? Stuff with sustainability and maintainability?
Yes we're Lazarus fans, yes Object Pascal is a beautiful language, but can we please loop out of the mentality: Have hammer, is all nails, UGH!! (chest thumping)
"It's the fact we don't have to rewrite so much code." you say.
Erm, don't you? Have you ever counted the man hours to swap from a Windows/GTK/QT widget set to the HTML5+CSS+JS?
Have you factored in the amount of time refactoring all your previous code to now accommodate the MC on the server and the V somewhere else?
It may "feel" easy and quick, but how much mullah is it costing the client?
Has this been fully backed up with tests or is this good cuz you have a feeling?
Just as a disclaimer:
I'm old. I started coding in 1985(was 15) but programming in 1997(was 27 out of Uni) and I've lived through a lot of evolving standards.
It was waterfall, then agile, then TDD. Where are we now?
I've also had to work with a lot of project managers/bosses that could only see productivity in the amount of lines of code, and never the whole picture.
I've also had to try and convince bosses that some standards, new at the moment, would make them save money in the long time: Stuff like source version control and tests.
And through all that had to shut up and submit when they thought they knew better. I'm just glad that I was able to bail out before it all collapsed when reality came a knocking.
So I've heard all the buts and all the ifs and all the arguments that "this is so different", but I'm not convinced and still say that you're looking at this with blinders or just obfuscated by the AHHHH SHINY.
Or worse, the client is insisting in the AHHH SHINY and you're just going along for the ride...
I remember, a long time ago, my dad saying to me: Microsoft is here to stay, why are you so intent in wasting you time with this Linux thing?
And now Windows has Linux inside it and GitHub is owned by Microsoft. The majority is doing web related programming and all the servers are in Linux.
Do we really know how long will the current status quo stand?
I'm old and I've been rooting for native "Desktop Apps" to have a comeback because it just makes sense.
Maybe I'll be vindicated, like the Linux thing above, or maybe not. The future is always a tad foggy.
But if I was a betting man, and with the trends I'm seeing, I think we'll get back to some semblance of native instead of so much interpreted...
Cheers,
Gus
-
What I can only see is that you're against a technology.
If it's the most widespread and most used don't matter.
I'm in the other hand im not against Lazarus and see a point using it.
Don't mind to respond to every thing you said because I will keep using the technology despite you can say.
Try yourself to see the good points that web has. Everyone knows it and if not can Google them.
Google is the main word here a website if I'm not wrong the number one app used in the world with web technologies.
I left this post since I don't want to talk more.
Edit: didn't want to say but seems that I'm the younger in this post. I've not lived the desktop era too much time and yes the web era. So we're different from the start.
-
@ Gustavo 'Gus' Carreno
I'm assuming that the original poster of this thread has a lot of programs written in Pascal (maybe I wrong on this --- if then, why ask here?), and is looking for approaches "To avoid having to rewrite a large part of the application". So I'm suggesting one possible approach based on my experience. Isn't he looking for experiences like mine? Or is he looking for most perfect solution for every occasion? If the latter, I have nothing to say, except that such solution does not exist.
It's his decision whether to use Lazarus, or re-write in PHP or whatever. I'm not in his position to judge what is the best solution for him.
-
Hola Leandro,
What I can only see is that you're against a technology.
If it's the most widespread and most used don't matter.
Hell no, I'm not against the technology.
Most of my career was doing PHP backend development.
And some of my career has been doing native compiled solutions.
But because I've done both I've got a better perspective of both and know not to fall from some of their pitfalls.
It also gives me insight on how to choose the best tool for the job.
I'm in the other hand im not against Lazarus and see a point using it.
Well, and to re-iterate, I'm not against Lazarus, I'm in favour of the right tool for the job.
And Open Pascal, compared to PHP in the context of web development will always loose because PHP has better community and documentation on web projects.
Open Pascal has a better community and documentation on native apps.
I'm not even against using PHP to do a desktop app, if possible, it's just the fact that it wouldn't be the best tool for the job, would it?
Why are you taking this as a personal attack? Did I say that you are wrong?
Nopes, I said that we should base our professional choices in logic, not passion.
Don't mind to respond to every thing you said because I will keep using the technology despite you can say.
I hope you do and I don't mind at all!!
Try yourself to see the good points that web has. Everyone knows it and if not can Google them.
Google is the main word here a website if I'm not wrong the number one app used in the world with web technologies.
Like I said, most of my career has been in the Web industry. I know it's ins and outs. And a big out is trying to compete in the native "Desktop app" world!
I left this post since I don't want to talk more.
Okydokes, it's your prerogative to disagree with me :)
Edit: didn't want to say but seems that I'm the younger in this post. I've not lived the desktop era too much time and yes the web era. So we're different from the start.
Well, young just means "have not learned enough yet, should learn more", it's not a bad thing. You still have loads of time ahead of you get old and cranky like me :P
Saludos,
Gus
-
Hey egsuh,
@ Gustavo 'Gus' Carreno
Please call me Gus, that's why I have the 'Gus' as a pseudo middle name there :)
I'm assuming that the original poster of this thread has a lot of programs written in Pascal (maybe I wrong on this --- if then, why ask here?), and is looking for approaches "To avoid having to rewrite a large part of the application". So I'm suggesting one possible approach based on my experience. Isn't he looking for experiences like mine? Or is he looking for most perfect solution for every occasion? If the latter, I have nothing to say, except that such solution does not exist.
Like you I'm not sure if he's asking here due to having a big code dependency on Object Pascal, or just because he doesn't have the expertize in anything else.
And I should've thank you for your input when I first answered. For that I'm very sorry and will now thank you very, very much for sharing your experience.
That, nonetheless, doesn't invalidate me giving advice on what I consider to be the best tool for the job, based on community size, documentation, sustainability and maintainability of a web project.
And based on that, Object Pascal is not at the top, sorry.
This nonetheless does not invalidate your effort. I'm glad you've been able to dish out your solution in Object Pascal, and would love to read a full tutorial on how you've done it.
If you're ever gonna be interested in doing so!
It's his decision whether to use Lazarus, or re-write in PHP or whatever. I'm not in his position to judge what is the best solution for him.
Well, me neither. But, being the opinionated old cranky git that I am, I'll try and pass my experience unto others.
Isn't it the sole purpose of this forum?
Even If sometimes it means we have to say: I'm sorry, your best bet is with something else.
Unless of course it's an experiment, or just a proof of concept, then yeah, go for it and just have fun.
I'm just thinking that this could be for a paying client and then I'm back to the mantra: Best tool for the job!
I hope I'm getting my message across.
I'm not against any of your endeavours in the past.
If you've done it, I'm rather happy for you, really!
It just a sense of responsibility to your client, not your passion or your limitations.
Cheers,
Gus
-
Hey all,
Let me be clear on something...
When someone says: I have no financial obligation on this and I want to perform a fun experiment of doing X with tool Y, even if it's "un-wise".
I'll say: Heck dude/dudette go for it. I admire your humph and courage!! Please leave behind a nice tutorial so we can all increase our collective knowledge!
When someone says: A client of mine wants me to do X.
I'll say: I hope you consider the fact that if you get whacked by a bus/get fired/have a family emergency/just life in general, the next guy that comes along will be able to pick up your project. And if your client really has to replace you or add another dev, it's not impossible to find another "you".
And for that to be true, the best thing is to have it based on a big community, large acceptance and non stale documentation.
That means no AHHH SHINY and no Have hammer, is all nail type of approach, right?
That's it, that's the clarity I wanted to pass along...
Cheers,
Gus
-
You see, at the moment the HTML5+CSS+JS widget set landscape is a bit of a wild west.
There are no standards. There are no widget sets per se. There's a new framework being invented every day.
I've lived through jQuery. Then it was, what? <insert list of JS frameworks that have been popular since jQuery and ending in Vue>. When is this wild west gonna end?
With all this early adopter and AHHH SHINY attitude it's a no brainer that clients aren't really adopting it. On the contrary, they're getting quite frustrated that past 1 year, their website isn't maintainable because the fad is gone and no one wants to update "yesterday's code".
In comparison, in the present, we have the Windows widget set, GTK, QT and KDE. That's 4 sets, over a period of how many years?
You are comparing apples with oranges. On the web there is only one, real widgetset: namely what the DOM provides. Everything else is merely an abstraction of that and the web developers have not yet found the best abstraction for the DOM.
My whole argument is that you shouldn't tear the whole house down just because the presentation layer needs a revamp.
And the Browser is getting to the point where it's being used like the Java or .NET runtime. But without the speed or optimizations of a programming language!!
It seems that you are not aware what kind of optimizations browsers do. After all you're able to run 3D games in the browser using JavaScript and WebGL nowadays with high framerate and polygon counts.
Please correct me if I'm wrong in this attempt of mine to generalize and use some technical terms:
Use an MVC abstraction where you have a server side and a thin client.
The server implements the M(Model) and the C(Controller) while the thin client takes care of the V(View).
The thin client can be a Browser or a purpose built one.
Connect the server and the thin client via the HyperText Transport Protocol(HTTP) using some kind of standard like XML or JSON.
Am I getting this right?
If so then why use Lazarus at all?
As professional programmers, don't we agree we should use the best tool for the job at hand?
If the whole thing is based in MVC, isn't RubyOnRails the best option?
Or if you don't like Ruby, why not CakePHP?
Laravel?
And who says that Lazarus/FPC isn't the best job? There are frameworks like mORMot that can help with the backend. And for the frontend you can use the LCL if you have a custom client or you can use Pas2JS with TMS Web Core or my work-in-progress Web Component Library (https://github.com/pascaldragon/Pas2JS_Widget/) if you want a JS-based solution.
The main advantage of this is that you don't need learn a new language. You can just use what's familiar. I don't care about Ruby, PHP or whatever because I don't want to deal with them. And I want to deal with as less JS as possible as well, thus I use Pas2JS. And a web client is more portable and simpler for users than having to install some binary client.
-
...There are frameworks like mORMot that can help with the backend. And for the frontend you can use the LCL if you have a custom client or you can use Pas2JS with TMS Web Core or my work-in-progress Web Component Library if you want a JS-based solution.
The main advantage of this is that you don't need learn a new language. You can just use what's familiar. I don't care about Ruby, PHP or whatever because I don't want to deal with them. And I want to deal with as less JS as possible as well, thus I use Pas2JS.
+1 :)
-
Let me see if I understand your point: Unless someone can do the presentation layer the way a browser can, we're stuck with something subpar on the logic layer, but hey, we have a magnificent presentation layer, right?
There is a whole thread in this forum talking about it, look for 'modern ui with lazarus'.
Like I said, most of my career has been in the Web industry. I know it's ins and outs. And a big out is trying to compete in the native "Desktop app" world!
I'm using at work Slack, Paymo, Postman, VS Code, all Electron apps. And are the most used, when I choose to don't use the app I use the web application and works the same.
Okydokes, it's your prerogative to disagree with me :)
Maybe =)
Really, I see your post as an attack at the first time, but the second one was better (in a possitive way) telling you're a web developer, so I think you understand about the tools.
I'm using both web and Lazarus.
And yes the missing part is the UI in Lazarus, despite I know how to create custom UI, say BGRAControls, where I contribute, there is nothing compared to HTML+CSS+JS out there.
And yes the UI is that the end user sees, they don't care about the low level or high level code, if we use objects or not, if we do in pascal or javascript or any language.
-
Hey PascalDragon,
I don't care about Ruby, PHP or whatever because I don't want to deal with them.
I don't care about bullies that try to shove their beliefs down someone else's throat.
I don't like that in Jehovah's witnesses, I don't like that in Mormons, I don't like that on (Tele)Evangelists, so I don't really care for that in you.
If you're not humble enough to admit that sometimes you're passion technology is limited and need to pass the bar to some other technology, you're not good to any client.
I could say it's greed, but I'll just say it's an overzealous fragile male ego.
We've had enough of that in our community, so please stop being the dude bro that our community is finally realizing is too toxic to have around.
Cheers,
Gus
-
Hola Leandro,
Really, I see your post as an attack at the first time, but the second one was better (in a possitive way) telling you're a web developer, so I think you understand about the tools.
I'm glad I was able to tone it down and explain, with less passion, what I was going about :)
Thanks for understanding.
And yes the UI is that the end user sees, they don't care about the low level or high level code, if we use objects or not, if we do in pascal or javascript or any language.
That is true when in the context of an open source project where there is no money involved and you're trying to attract the attention of all kinds of people.
But in the context of a paying client, you want to provide the most efficient way of providing value to his money.
If you get all tangled up in promoting your passion tools just for the sake of something new or something familiar, you're not giving the client good service. You're just stroking your ego, no?
If you wan to be a good professional, you have to be prepared to say no and direct said client to something that will provide that value on his money.
And mainly remember that the project may outlive you. So be kind to the next guy that comes along to service your mess :)
Cheers,
Gus
-
Hey PascalDragon,
While you really don't deserve an answer to this post, I'm throwing caution to the wind and just do it anyway...
You are comparing apples with oranges. On the web there is only one, real widgetset: namely what the DOM provides. Everything else is merely an abstraction of that and the web developers have not yet found the best abstraction for the DOM.
If you want to be that technical, and wanna go bare metal, then in an OS there is the pixel and it's colour, alpha, position in the matrix that is your graphic's memory behind your screen.
Ever since Xerox came up with the first Graphical Interface, the rules of what a widget is were clear: A thing within a visual Rect(angle) that you code via events.
From that we've had many ups and downs but we've stabilized on these: Windows, GTK, Qt and whatever KDE uses, that I can never remember.
In light of that, how are we being presented with a new approach to something already solved, on a yearly or biannual cycle?
Now, do we have the DOM limitations to blame? I sincerely don't know. What I do know is that it's been more than 20 years and where still seeing new JS frameworks popping every year...
20 years is 5 years shy of a generation. Isn't that time enough to get the act together?
It seems that you are not aware what kind of optimizations browsers do. After all you're able to run 3D games in the browser using JavaScript and WebGL nowadays with high framerate and polygon counts.
I'm quite aware of the feats being performed inside a browser. I'm not living under a rock.
What I don't understand is why do we have to add another layer of difficulty.
The OS can do all this with a kernel and some drivers. So why do we need WASM/WebGL+Browser+Drivers+Kernel?
As a show off of what you can do in a constrained environment, I say: Well done!! Write us a blog post so we can all learn about it!!
But don't make us have to use it just because you made an effort on something silly and your ego is gonna bruise if we don't!!
And who says that Lazarus/FPC isn't the best job? There are frameworks like mORMot that can help with the backend. And for the frontend you can use the LCL if you have a custom client or you can use Pas2JS with TMS Web Core or my work-in-progress Web Component Library (https://github.com/pascaldragon/Pas2JS_Widget/) if you want a JS-based solution.
Like I said, I acknowledge all those efforts with a big BRAVO. Well done, very nice to have in my passion language.
But that doesn't blind me to the fact that in comparison to other web technologies, they have a bigger community, better documentation and more people in the recruitment pool.
And in the business world, those are the params that count, not that you love Lazarus and have a solution in it.
Repeating myself: If you get smacked by a bus, will the client find an easy and affordable replacement for your niche set of tools?
Cheers,
Gus
-
Hey PascalDragon,
I don't care about Ruby, PHP or whatever because I don't want to deal with them.
I don't care about bullies that try to shove their beliefs down someone else's throat.
Now where does that attitude come from? :o I wrote that I don't care and that I don't want to use Ruby or PHP or whatever. I never wrote that you or anyone else has to use Object Pascal. I simply stated why I do and what possibilities there are for those that want to use Object Pascal for this like I do. So if you took that as some kind of offence or attack, then this was not my intention.
-
Hey PascalDragon,
Now where does that attitude come from? :o
Well, that attitude comes from the fact that you chose to start one of your arguments with "I don't care...".
It doesn't really matter what comes after that. You've already set the tone. Anything after that is just bullish.
You see, looking at your profile, with a couple thousand posts, the classification of Hero Member(granted, not your choice of words) and the fact that day in, day out you demonstrate a firm grasp of the innards of Lazarus/FPC puts you in a rather delicate position of being considered an example to follow.
So when you set the tone that you "don't care" about something, younger fellow programmers, young in knowledge, not in age, will tend to subconsciously imitate you. And that toxic tone is what festers and brings about the rancid tech bro culture that we need to shed.
If you, instead, started your argument with something along the lines: "I've invested a lot on my current path, so I don't have he expertize to comment or advise on something else", I would never have given you grief.
But that wasn't your choice, right? You chose to start with "I don't care...".
Do you now get why the attitude came about?
Cheers,
Gus
-
@Gustavo 'Gus' Carreno: amho, you're getting angry all by yourself, and you are creating a flameware from scratch. You have truncated @PascalDragon's proposals, by deleting his sentence, his thought just before (perhaps due to reading too quickly?). A less impartial quote would have been:
You can just use what's familiar. I don't care about Ruby, PHP or whatever [snip] etc
I read "You can". And then, I don't read "You must necessarily use Object Pascal". Peace between languages.
-
Hey devEric69,
@Gustavo 'Gus' Carreno:
Please, call me Gus. .oO( Is no one aware of the faux middle name as the convention for preferred name to use? )
I read "You can". And then, I don't read "You must necessarily use Object Pascal". Peace between languages.
Well, you see, that's what you've got wrong.
My change in attitude towards PascalDragon is not because he's advocating for this language against some other. In that regard I have no quandary.
I've been doing both sides of this equation professionally and while I have a passion for Object Pascal(Native Desktop Apps) and CakePHP(Web devel), I can't call myself a professional if I let my passions blind me in serving the best interests of a client.
My attitude change is due to the tone of micro-aggression the he used and that such tone is the basis of much of the toxic environment in the tech bro culture.
If it wasn't for that use of micro-aggression, I wouldn't be in this hopeless crusade of social justice. I would be politely going back and forth with my arguments and experience. As I actually did in a second reply (https://forum.lazarus.freepascal.org/index.php/topic,44525.msg400533.html#msg400533) to his post.
Ermm, now who's the one that didn't read the rest of the thread?
Now do you understand where I'm coming from?
Cheers,
Gus
PS: @trev I have to admit that this has devolved into something that the original OP doesn't have to be subjected to.
Would you be so kind to decide where to snip this out and then give it another Title like you did for the other thread?
Many, many thanks in advance!!
-
My attitude change is due to the tone of micro-aggression the he used and that such tone is the basis of much of the toxic environment in the tech bro culture.
I think your imagination is playing tricks on you. Perhaps dial down your micro-aggression detector or send it in for recalibration ;-)
-
Hey Trev,
I think your imagination is playing tricks on you. Perhaps dial down your micro-aggression detector or send it in for recalibration ;-)
While I may admit that you can be right, in the case of toxic community behaviour I think we always should sin on overreacting and not sin underreacting.
It's really stuck with me, ever since I've first heard it, that: For things to go bad, it only takes a good man to say nothing.
And we had the Nazis due to that. We have the current state of misogyny due to that. We have the current state of tech bro toxicity due to that.
I'm not saying that I'm a good man, I have my devastating faults for sure, I just don't want to pile more manure on that pile of sh*t that is the tech bro culture.
That's it. That's what I'm trying to say.
Cheers,
Gus
-
And it only took 20 posts for Godwin's Law to make its appearance.
-
Per the title of this thread, I don't think moving or creating apps for the web is a mere "fad" or "craze". It's been worldwide big business for quite a while now and will remain so for the foreseeable future.
In the context of Lazarus and the LCL, an useable open-source web component library (Pas2JS Widgetset) is clearly needed. Outside looking in, appears it needs more developers with such skills, to speed up progress.
I don't think it will be the "be all, end all" for everyone and clearly for more heavy duty type applications a person may need to target the OS more specifically or have to look elsewhere because the scope of the project is so large.
However, Lazarus focuses a lot on the client-side and desktops, so we have projects like LAMW and cross-compiling for other OSes. I think more focus on HTML client apps is inline with Lazarus. After all, we have the transpiler (Pas2JS), so the next logical step is putting it to greater use. And in that regard, usability appears to have floundered a bit and moved quite slow, thus the full potential is not being realized.
-
Hey PierceNg,
And it only took 20 posts for Godwin's Law to make its appearance.
According to Wikipedia:
Godwin's law, short for Godwin's law of Nazi analogies, is an Internet adage asserting that "as an online discussion grows longer, the probability of a comparison involving Nazis or Hitler becomes more likely.
Godwin's law - Wikipedia (https://en.wikipedia.org/wiki/Godwin%27s_law)
I didn't make an analogy. I stated a fact that has been written in history books and researched extensively in social sciences: When good men do nothing, things go to sh*t.
Mentioning the tragedy that happened pre, during and post second world war inflicted by the ideology of the nationalist party, what we now call the Nazis, is just because it's still quite vivid in the collective mind of us all.
I could explain what an analogy is, or explain what a fact is and how they differ from each other. But I guess you're smart, since you quoted Godwin's law of Nazi analogies, and that would be patronizing.
Patronizing, another micro-aggression that's a red flag in toxic behaviour.
Nonetheless, your total disregard for the 2 following tragedies that I mention is quite intriguing.
Let's mention the Nazis, but let's forget about the harmful misogyny toward women and the toxic tech bro culture, hum?
Cheers,
Gus
-
Pascaldragon "And who says that Lazarus/FPC isn't the best job? There are frameworks like mORMot that can help with the backend. And for the frontend you can use the LCL if you have a custom client or you can use Pas2JS with TMS Web Core or my work-in-progress Web Component Library (https://github.com/pascaldragon/Pas2JS_Widget/) if you want a JS-based solution."
Nice job pascaldragon, when do you think database support on your pas2js_widget modifications is ready?
-
Hey PascalDragon,
Now where does that attitude come from? :o
Well, that attitude comes from the fact that you chose to start one of your arguments with "I don't care...".
I didn't start with "I don't care". The whole part of the post reads like this:
And who says that Lazarus/FPC isn't the best job? There are frameworks like mORMot that can help with the backend. And for the frontend you can use the LCL if you have a custom client or you can use Pas2JS with TMS Web Core or my work-in-progress Web Component Library if you want a JS-based solution.
The main advantage of this is that you don't need learn a new language. You can just use what's familiar. I don't care about Ruby, PHP or whatever because I don't want to deal with them. And I want to deal with as less JS as possible as well, thus I use Pas2JS. And a web client is more portable and simpler for users than having to install some binary client.
Where I wrote the "I don't care" is near the end of the post (which was even larger considering the other quotes).
Do you now get why the attitude came about?
No, I still don't. In my opinion you're making an elephant out of a fly to use a German saying.
If you really want to see micro aggression then look at my replies to posts by jamie when they're defending their abuse of code generator implementation details of Delphi and then complain that FPC doesn't duplicate them. :-X
In the context of Lazarus and the LCL, an useable open-source web component library (Pas2JS Widgetset) is clearly needed. Outside looking in, appears it needs more developers with such skills, to speed up progress.
Oh, definitely. I'm in no way experienced enough yet and I'm essentially learning this whole client side web browser stuff as I go. Not to mention that I have a ton of other projects to work on as well. %)
Nice job pascaldragon, when do you think database support on your pas2js_widget modifications is ready?
I have yet to look at how the LCL handles DB controls. But at least a client side REST based TDataset is already available through pas2js itself.
-
As they do on faceBook, I give a "like" @PascalDragon: +1.
And I give @Gustavo 'Gus' Carreno, a "down": -1.
Peace on the lazarus site :-* .
-
Nice job pascaldragon, when do you think database support on your pas2js_widget modifications is ready?
What are you looking for in terms of "database support" for transpiled-to-Javascript run-in-browser code?
For me I envisage pas2js code running in the browser to be making API calls to some server (or even server-less lambda thing like https://github.com/c600g/fpc-lambda-runtime (https://github.com/c600g/fpc-lambda-runtime)) and let the server-side handle persistence.
-
Nice job pascaldragon, when do you think database support on your pas2js_widget modifications is ready?
What are you looking for in terms of "database support" for transpiled-to-Javascript run-in-browser code?
For me I envisage pas2js code running in the browser to be making API calls to some server (or even server-less lambda thing like https://github.com/c600g/fpc-lambda-runtime (https://github.com/c600g/fpc-lambda-runtime)) and let the server-side handle persistence.
In my opinion cappe is talking about DB-aware controls. Like with the LCL they don't care where the data comes from (be it remote API/REST call like you mention or a local DB) and are simply about displaying the data and allowing the user to manipulate it (which would then result in more API calls of the dataset to notify the server of the changes).
-
If you, instead, started your argument with something along the lines: "I've invested a lot on my current path, so I don't have he expertize to comment or advise on something else", I would never have given you grief.
Suggesting that is as leading as what you accuse PascalDragon of.
-
Thanks for the reply, I intended to have DB-Aware checks. Like the LCL, otherwise I think, it would not make PAS2JS_WIDGET, it was born to simplify and speed up. But I will also take a look https://github.com/c600g/fpc-lambda-runtime. However I managed to do what I was doing with the other web application with some written code. She's very beautiful.
-
Excuse me pascaldragon if I take advantage of your presence. To insert html code in a TWForm, what is the best method?
-
Hey MarcoV,
Suggesting that is as leading as what you accuse PascalDragon of.
When a physicist is asked about physics he knows what he's talking about.
When a physicist is asked about medicine, the right thing to do is to say that that it's outside his expertize and humbly refer to someone that has invested his time and passion on that specific medicine question.
I, myself, during my career have had to hand-over some clients to someone else with better grasp of a solution that better fit said client needs.
I did that because I didn't want to participate in the behaviour of a know it all smarty pants. And no I'm not calling anyone here that. I just didn't wanna be one.
So now that you know my intended context to the quote you mentioned, could you please elaborate on your remark that I'm as leading as what I accuse PascalDragon of?
Cheers,
Gus
-
Hey All,
Like I said earlier, this was a doomed and hopeless social warrior campaign since it's obvious that there is a profound lack of diversity in this forum.
Sure, yes, we have multicultural diversity, but it's still very much a sausage fest of testosterone.
And even if we have female participants, they most likely welcome the anonymity that the forum provides in order to not be perceived as a woman.
I said my peace and it's quite clear where I stand. I won't be re-surfacing this subject any more, I'll keep to the technical parts.
Cheers,
Gus
-
Long live to FPC and the Web. Until something else replaces them.
Anyone choose the tool what he knows better or what works for him or the customer.
Both are great tools.
EOF
-
... doomed and hopeless social warrior campaign ...
May I have some words?
Life will be easier if you try to see things simpler.
This is just a simple forum for people who have problem using FPC/Lazarus. They post their problems, get answers and advises. Sometimes, the answers are not fully correct and advises are not good enough. That's okay, someone who has better experience will respond and improve it.
I am the less skilled member here. Often, I realized some of my answers were wrong, I felt bad. There were times I believed my advises were good but being ignored, some ideas were awesome but rejected. That's okay. Life is not perfect. Being wrong, ignored, rejected are not very important. What most important to me is, I do participate.
-
Hey Handoko,
May I have some words?
Thank you so much for the kind words of encouragement!! I really appreciate them.
But unfortunately, and with my deepest apologies, I must say that you missed the point. Sorry.
Cheers,
Gus
-
Hey PascalDragon,
Sorry, so sorry, I completely forgot to answer you.
In a post directed at @trev, I admitted that I probably overreacted to your post, but still maintaining that we need to sin on the over not the under in terms of pointing toxicity.
Nonetheless, if there is the smallest chance that I did overreact, it's only fair and decent that I apologise to you. After all I kinda picked up the righteous flag and stomped all over the place, so I should listen to my own advice, right?
So, PascalDragon, you deserve my deepest apologies if I did take it a bit too much and overreacted. Really sorry about that!!
Not to take away from that, I still am of the opinion that we should cut toxicity by the root. But we are humans and we do mistakes.
My mind tells me that I probably did a mistake and I should apologise, which I did, very sincerely.
My heart is of another opinion but that's really on me to reconcile with myself.
Cheers,
Gus
-
Nonetheless, if there is the smallest chance that I did overreact, it's only fair and decent that I apologise to you. After all I kinda picked up the righteous flag and stomped all over the place, so I should listen to my own advice, right?
So, PascalDragon, you deserve my deepest apologies if I did take it a bit too much and overreacted. Really sorry about that!!
Not to take away from that, I still am of the opinion that we should cut toxicity by the root. But we are humans and we do mistakes.
My mind tells me that I probably did a mistake and I should apologise, which I did, very sincerely.
My heart is of another opinion but that's really on me to reconcile with myself.
Thank you for the apology. To be honest I had felt quite... let's say hurt by your reply then as I'm no fan of toxicity either and with me being queer I have to face such potentially in the offline world as well.
-
Hey PascalDragon,
Thank you for the apology. To be honest I had felt quite... let's say hurt by your reply then as I'm no fan of toxicity either and with me being queer I have to face such potentially in the offline world as well.
Well, then, please accept my doubling in apologies. "I didn't know" is never an excuse, but now that I know, I feel even worse.
And many thanks for sharing such a private detail of your life. I certainly don't deserve it, but I'm quite thankful that you shared it.
Cheers,
Gus
-
And many thanks for sharing such a private detail of your life. I certainly don't deserve it, but I'm quite thankful that you shared it.
I don't make a secret of it, it's simply due to habit that most people here don't know it. The other core devs know for example and it's also visible on various social media platforms.
-
First of all, this is an answer to the original post, I skimmed through the other answers, but I don't want to take part in that mud fight, but if there already where some answers to what I am going to write, I might have missed them.
One thing before I start, I don't think that this phenomenon is so new. Big electron desktop apps like VSCode exist for like 6 now.
So let's first consider the web technology itself. As many languages have a webasm or javascript transpiler, this is completely independent of language.
The first point is of course the most important one, cross compatibility. Your code needs to be developed for a browser, not a platform. No matter if it is running on an android smartphone, a Samsung SmartTV or a Windows Desktop, it will always work the same. This is something you can not say about native solutions like Lazarus. If you consider developing an app that should work on iPads, PCs, Macs and Mobile, web technology is a great choice.
If I for example would write a chat application, I would definetly use web technology because if a chat does not work on mobile it is basically useless in a Smartphone world. And just between Android and iOS are so many differences when developing native that mobile alone is a reason to use webdev.
Then you can also provide portability through the browser itself. Apps like slack are basically just a bottled up version of the browser code, with a few extensions to make use of the native API (like notifications). But in general, if you want to provide a service via browser and natively, like many chat services such as slack, using web technology halfs the amount of work you have to do.
A big point is also the graphic features of the Browser. Browsers are optimized for very fast rendering of complex graphics. From the HTML DOM styled with CSS to the "handrawn" functionality of the Canvas using Javascript, the browser is really really fast. Things for which with Lazarus you would need to fall back onto using OpenGL or something comparable.
Many applications using web technology have a custom design. Slack, Riot or VSCode make no use of any "standard" components like the default system style buttons, but are completely customized. And users like pretty applications. Every time I see Java users switch from IntelliJ to Eclipse, you can see how much they dislike the Eclipse design, even though it is much more classical then the fully customized IntelliJ. It has a reason why Microsoft has introduced WPF to .Net. Maybe it is just a trend (I remember back to like Windows 2000-xp times there was also a trend to custom designed applications that died out a few year later when Win 7 rolled around), but at least right now, it seems to be something users like if an app has a unique style, as long as it is pretty and well structured.
Not only graphics, but more generally speaking browsers heaviely support Multimedia functionality. To implement a cross platform video player in a native GUI app is pretty complicated and often requires additional dependencies like VLC or so.
Then there is of course the tooling and support. It is vast, well tested and most importantly free. There are other frameworks that try to replicate these advantages for other platforms like Xamarin for C# with .Net core or Firemonkey for Delphi, but here you are paying for things that are free with web technology and have a bigger community, better support, more libraries than these payed alternatives
Also it is just very easy. Native system APIs like the Windows API are, due to having to be very generally applicable, very complicated. Web APIs are usually much more straight forward. I had to go and read something up in the POSIX standard more than once to build a native Linux app, I never had to read any standard for web stuff like IndexedDB or something similar.
Lastly, web platforms are designed for event based development, which perfectly aligns with how GUIs operate. Most APIs in the web are designed around asynchronous single threaded callbacks. This avoids mangling with multi threading problems, deadlocks and so on, while still allowing for a fluent GUI design.
There are the buildingblocks for this available in most other platforms, for example Lazarus GUIs use the Synchronize function to schedule function calls within the event queue of the main thread. This is used by some libraries (I think indy uses this method to schedule event calls), but this is just a "patch" to make an inherently synchronous system asynchronous, and only works if it is specifically implemented. All the system apis, etc. are inherently synchronous.
The in browser on the other hand everything revolves around the asynchronous event queue. All APIs are designed to make use of that, which matches very well with the way GUI applications operate. This btw also to a very frustrating degree (e.g. you have old style callback functions mixed up with new style promises, which can be really confusing) but from a design perspective for GUI apps its fantastic.
This is where you can't spearate that well anymore between the platform and the language design, because the browser is made for Javascript and Javascript is made for the browser. And while there are a lot of issues with JavaScript (as it is grown historically it has some really annoying things about it, e.g. iterating through an array via for ... of because for ... in was already taken), it clearly shows that this language was designed for event based GUI development, especially with the DOM.
For example the event based structure of the APIs synergises really well with Javascripts heavy reliance on lambda functions, a feature that came really late to many other languages.
And of course not to forget, to start developing with Javascript, all you need is a browser and a text editor. No toolchain is needed, which is why prototyping in Javascript works really well.
So to summarize, why to use Javascript for desktop apps?
- Cross compatibility to all platforms
- Great for complex graphical interfaces
- Publishability through websites allows for inherent portability
- Large community, many libraries and a lot of support
- Inherently designed for GUI development
- Easy
A development environment is only as good as it fits the use case. Let me give you two examples, one where webtechnology is very useful and one where it isn't.
Let's say you want to build a chat, that should run on all platforms as app, be accessible via a website if you can't install the app, e.g. to check in from a foreign pc, and this chat requires a lot of multimedia functionality, like playing voice messages, or viewing videos sent via the chat. I would definitely choose web technology, no questions asked.
If I had a program that needed to load and parse binary data, e.g. file compression or something similar, which probably can be parallelized in multiple threads and is very IO heavy then I would defenetly not use web technology.
-
Hey Warfley,
- Cross compatibility to all platforms
- Great for complex graphical interfaces
- Publishability through websites allows for inherent portability
- Large community, many libraries and a lot of support
- Inherently designed for GUI development
- Easy
- Cross compatibility to all platforms
If and only if there's a full/headless browser present. So same inherent issues as the Java Runtime and the .NET runtime without adding any value. - Great for complex graphical interfaces
HTML was not created with this in mind. With the craze of browser stuff, it's been mangled to accommodate it, with no real sense of future proof or even standardization. - Publishability through websites allows for inherent portability
About the only thing that web has over compiled: Easy distribution - Large community, many libraries and a lot of support
I still think its a craze/fad but I'm not futurist to see it's cycle end. But granted, there is a crowd that as chosen to board that train. - Inherently designed for GUI development
You're repeating yourself and still I say, HTML has been mangled to do what it does now, in a willy nilly way - Easy
This is always a matter for discussion. Easy for you is hard/nonsensical to others
And then you reply: But you know there is this, and this, and that etc... that make compiled stuff so cringy.
Yeap, I'll agree to all of those, and I'll probably pile on some more you've forgotten.
But in the end, native only depends on the OS. It does not depend on the interpreting platform(JavaScript/Python/PERL/PHP).
If for some wacky reason the interpreting platform goes away, so will all the effort put on it.
If the OS goes away, errrmmm, well, then the computer doesn't work and the argument is moot.
Adding another layer of complexity and resource hogging software is not something I'm very interested in, even if all your bullet list points where true.
Is it harder going the compiled way? Well, it's bloody easier from the assembly days and the IDE's help a bunch.
But like I said, easy is very subjective and should not be on the table to discuss.
Yeap, that rando on the internet that disagrees... Sorry!!
Cheers,
Gus
-
Reason for web applications: deployment, deployment, and, not to forget, deployment.
Deployment "portability" on the handful of targets that have a full, up to date browser, and keep that so for your apps lifecycle. No hope whatsoever on others.
Moreover, javascript is an excellent Laptop fan exerciser
-
Hey Marco,
Deployment "portability" on the handful of targets that have a full, up to date browser, and keep that so for your apps lifecycle. No hope whatsoever on others.
Wow, thanks for reminding me that I didn't rant about that!!!
@Warfley: A compiled 32b app made in the Windows XP era, can still run in all it's glory on a Windows 10 64b machine of today.
If you try to run your power hungry, memory hogging HTML5+CSS+JS web app on an Internet Explorer of the time, you're shit out of luck aren't you?
This whole Web craze really looks like the way Microsoft kept pumping out new versions of Windows, just to make people upgrade their hardware...
Like Marco says, if you have state-of-the-art gaming rig, then you can run, PROBABLY, 2 Electron apps at once.
If you still have Windows 8 and don't update hardware, it's 1 Electron app and the computer turn into a heat exchanger!!!
Moreover, javascript is an excellent Laptop fan exerciser
Yeah, forgot about that LOL!!!!
Cheers,
Gus
-
Internet Explorer of the time
Using Internet Explorer "of the time" is like using an alpha version of FPC, like less than 1.0, you can get into trouble with unsolved bugs as well.
-
Internet Explorer of the time
Using Internet Explorer "of the time" is like using an alpha version of FPC, like less than 1.0, you can get into trouble with unsolved bugs as well.
It's not about the tool, it is about the product. If the generated application worked fine with the version at the time, it probably still works fine on current windows (except for some very minor things that changed like direct portaccess and UAC).
Now run the web product that you made back then in the now default browser.
-
This is the oldest I have
https://leyendadigital.blogspot.com/2013/04/tu-nombre-al-reves.html
2013 and works still in Internet Explorer, Latest Chrome as well.
And this other 2013 (AngularJS 1.0)
https://ventaja-comparativa.blogspot.com/
Using very old libraries, still at CDN, I never changed them!!!
Edit!
In the other hand, I have an Angular 11 (latest version) application that uses angular material design, and its working on Internet Explorer! Almost all the animations and style works the same like in Chrome, because that library is well designed. I code in the latest typescript version and is compiled into old javascript versions, compatible with Internet Explorer and as well it does another bundle with modern javascript for modern browsers, and it loads automatically the version is compatible with your browser.
-
If and only if there's a full/headless browser present. So same inherent issues as the Java Runtime and the .NET runtime without adding any value.
The thing that adds the *value* of cross compatibility adds no inherent value? Are you kidding me? Cross compatibility is the value and you even acknowledge that. This is exactly the reason why languages like Java, Python or JavaScript are so popular. You need to install just 150mb or so once, and from that point onwards you can use any application using that technology.
If you look at the most popular languages according to their prevalence in open source projects on github, the three most popular languages by a long shot are Javascript, Python and Java, making up together nearly 50% of all the repositories.
Also this argument simply does not work at all, because if you ever used Linux, you might have noticed that Linux does not provide any native system apis for creating graphical user interfaces. In fact you need at least a display server. Modern applications also don't talk to the displayserver directly, but use a framework like QT or GTK for this.
So any argument against a runtime environment must be able to explain why why relying on a 150 mb electron installation is bad, while relying on a 150mb QT5 installation is no issue at all.
HTML was not created with this in mind. With the craze of browser stuff, it's been mangled to accommodate it, with no real sense of future proof or even standardization.
Originally not, but things can change. Today the W3C consortium designs future versions of web technology with exactly this in mind. And what about that there is no standardization? HTML, CSS are all standardized by the W3C. The last version of the HTML standard, HTML 5.2 was released in 2017: Link (https://www.w3.org/TR/2017/REC-html52-20171214/). The last version of the CSS (2.1) standard was published in 2016: Link (https://www.w3.org/TR/CSS2/) the CSS3 standard is not finalized yet, but the consortium is currently working on it with many features already finalized.
JavaScript is standardized, under the name of ECMAScript, by ecma international, and the latest version ECMAScript 2020 came just out last year: Link (https://262.ecma-international.org/)
All these standards are developed in close relationship with browser developers and web developers to be designed to serve the emerging needs of the userbase.
So this point is just plainly and factually wrong, front to back. Pretty much everything on the web is standardized and graphical abilities are a major concern in the standardization process.
Also a bit bold by someone who uses Pascal to criticize lack of Standardization. Because Pascal is one of the few languages where there are Standards but everyone decides to ignore them completely.
I still think its a craze/fad but I'm not futurist to see it's cycle end. But granted, there is a crowd that as chosen to board that train.
You can think what you want, personally I also don't like web technology, because everything feels like they reinvented the wheel, like storing data for offline usage, instead of allowing an internal filesystem it deploys a complete database system, which makes the very simple act of storing and loading files a real pain in the neck.
But a large community is a major argument for a development environment. It means more libraries available with more users to be using and testing them, more support and less likely to loose support in the future.
But in the end, native only depends on the OS. It does not depend on the interpreting platform(JavaScript/Python/PERL/PHP).
If for some wacky reason the interpreting platform goes away, so will all the effort put on it.
If the OS goes away, errrmmm, well, then the computer doesn't work and the argument is moot.
You can't be serious here. Have you never updated your computer? If Windows XP goes away, I can still use the computer using Windows Vista, 7, 8 or 10, but there will be software that will not run anymore. Whats the difference between software that does not work anymore because the only OS it was running on was going EOL vs a program not working anymore because the only interpreter it was working on going EOL.
Except that it is often much easier to run outdated interpreting environments on a modern machine then it is to run outdated operating systems. Windows XP would simply not work on my new PC, but from personal experience I can tell that I was able to easiely run Java 5 on my new machine, which I needed for a very old application to run locally.
Adding another layer of complexity and resource hogging software is not something I'm very interested in, even if all your bullet list points where true.
Is it harder going the compiled way? Well, it's bloody easier from the assembly days and the IDE's help a bunch.
Yes it is harder in certain circumstances. How about we do a simple experiment. We write both a calculator, I using only web technology, you fully native. Requirements are: It has to run on Android, iOS, Mac, Linux and Windows. Who do you think will have to put more work into this? I am pretty sure that using webdev I could do that in like 10 minutes.
@Warfley: A compiled 32b app made in the Windows XP era, can still run in all it's glory on a Windows 10 64b machine of today.
This is a property of windows which Microsoft pays a lot of money to have. Neither on Android, iOS, Linux or Mac will this work. You basically just picked out the single platform this works with.
To me your whole post feels like you are also just talking about windows and windows alone. But thats not what reality is like. Windows is not the be all and end all for software development, it isn't even anymore the most used operating system, android is. Tablets have taken over a lot of the market from home PCs, and Android and iOS together make up 56% of the market.
Even on desktops windows is falling especially in the US, ChomeOS already makes up nearly 7% of the market, Mac OS another 30%, with windows only left with 60%.
Modern software must be designed to reflect this change. Most applications must run on mobile, for many apps like mail clients or chat services, this might even be the most important requirement. Corporations are using more and more using Chrome Books, for whom web development is the native platform.
Sure you can say that you personally only develop for Windows, in which case you are right, there is no reason to use web technology. This is why Microsoft still develops native apps for Windows using C++ or .Net and not with web technology. But don't act surprised that people with different requirements might choose a different development platform
If you try to run your power hungry, memory hogging HTML5+CSS+JS web app on an Internet Explorer of the time, you're shit out of luck aren't you?
How can you complain about standardization earlier and then mention internet explorer, which was notorious for ignoring the HTML, CSS and JavaScript standards. But that aside, this comparison is very lackluster, because this is exactly the other way around as your previous claim. You develop apps for the current system, not for the past. A modern Windows 10 64 bit application won't run on 32 bit Windows XP either.
To make the analogy more fitting consider a website written in XHMTL 1.2 from 2003 and run it in a modern day browser. And this works still really well, because backwards compatibility is also a major concern for browser developers. In fact a webapp from 2010 will still work in a modern browser. A native android app from 2010 will not work on a modern android device. This is again a point for web tech and against native
This whole Web craze really looks like the way Microsoft kept pumping out new versions of Windows, just to make people upgrade their hardware...
Like Marco says, if you have state-of-the-art gaming rig, then you can run, PROBABLY, 2 Electron apps at once.
If you still have Windows 8 and don't update hardware, it's 1 Electron app and the computer turn into a heat exchanger!!!
Which is completely wrong. VSCode, one of the most complex electron apps out there even runs on my 7 year old macbook air completely fluently, much better than for example XCode which is a native app, even developed by Apple themselves.
In fact, I have VSCode open nearly all the time, and I don't notice it at all.
Yeap, that rando on the internet that disagrees... Sorry!!
Well disagreement is one thing, but the thing that bothers me with your response is that it is factually wrong on like half of your points. You claim that the thing that adds cross compatibility, which is a value, has no inherent value, is plainly a contradiction. The claim that there are no standards and that HTML is not developed for complex graphical usage is also just wrong, and that it if an OS goes EOL or "disappears", you can't use your computer is just comically stupid. Your last post about backwards compatibility sim completely missed the mark because of a analogy that simply does not work and makes it even ridiculus to think about because backwards compatibility is one of the major concerns for web development, and browsers are in that regard even better fitted than Windows.
I don't like webdev, I think its practices are often overcomplicated, reinvent the wheel on nearly all issues and disregards any best practices that developed on native development. I think JavaScript is a stupid language that should be burned to the ground and completely reworked, and the idea that you should include a whole framework just for one line of code, which is a common practice in web development, is just beyond me.
But it has it's merits, and to conclude here, every argument of yours that does not boil down to "I don't like it" (which is completely fine) relies on misconceptions, faulty comparisons or being factually wrong.
You seem to have a very strong opinion on that matter, but it is build upon misconceptions, an outdated view of the technology and really the points that you are bringing up are, for anyone who knows even a little bit about the technology, just comically wrong.
-
I just want to add one thing about this, which I think does not fit that well in the previous post (which already got a little bit long), so I add it here
@Warfley: A compiled 32b app made in the Windows XP era, can still run in all it's glory on a Windows 10 64b machine of today.
The thing that amuses me about this the most is, that earlier you complained about the complexity and resource hogging of another interpreter, but the reason why this backwards compatibility on windows works so well is, because Windows is shipping a complete set of 32 bit libraries, the windows on windows 64 (WoW64) system, with it's installation. Besides this there is a lot of old versions of apis and libraries which windows links against programs compiled for older windows versions to ensure backwards compatibility.
The reason that old executables run on new versions of windows, is literally because windows basically ships with it older versions of itself to make it work. You don't like the overhead from additional runtimes, but praise windows for having exactly that baked right into the system.
This level of irony is just of the charts, honestly I had to lough out loud when I read this
-
Hey Warfley,
Not gonna contribute, any more, to this ongoing mess that is probably my fault to begin with.
Some of your points are valid and some are just you digging your heels and covering your eyes.
I'll agree with the former but will not go into any discussion into the latter.
You are set in your ways, as am I. We both have rigid opinions.
I concede and say: Agree to disagree.
Cheers,
Gus
-
@Warfley: A compiled 32b app made in the Windows XP era, can still run in all it's glory on a Windows 10 64b machine of today.
This is a property of windows which Microsoft pays a lot of money to have. Neither on Android, iOS, Linux or Mac will this work. You basically just picked out the single platform this works with.
To be fair, FPC binaries that don't link to other libraries (e.g. the compiler itself) run on Linux quite far back (I think 2.4 or so).
-
To be fair, FPC binaries that don't link to other libraries (e.g. the compiler itself) run on Linux quite far back (I think 2.4 or so).
In fact with carefully versions of the compiler and features used you can compile for even older distros. We still have a fairly large program maintained on old machines with Debian Potato (which IIRC is Linux 2.2 or thereabouts).
I don't remember ATM which version of the compiler we had to use but I kind of think it being one of the late v1.x (1.4 or 1.6). It needs quite a lot of memory (IIRC 64 or 128 MiB) but it's doable.
-
Some of your points are valid and some are just you digging your heels and covering your eyes.
Cheers,
Gus
Gus, I really have to say that your posts are generally helpful or at least amusing (and I don't mean anything particularly negative by that), but in this particular thread, you have engaged in what can only be referred to as "rampant projection."
Seriously. The quoted statement is just one tiny example.
-
Hey ASBzone,
Gus, I really have to say that your posts are generally helpful or at least amusing (and I don't mean anything particularly negative by that), but in this particular thread, you have engaged in what can only be referred to as "rampant projection."
Seriously. The quoted statement is just one tiny example.
First of all, many thanks for the compliment. :D I'll take the funny and the helpful with pride ;)
Second of all, I think you're absolutely right!!
I got to a point, in this thread, where I didn't really like what I was doing and where I was going. So I decided to end it.
I have to admit that it was abrupt and most possibly not the best way to do it.
For that I sincerely apologise. I guess I was hating myself and I lashed out AT myself, but TOWARDS others, with no clear indication of this fact.
Also, thanks for taking the time to point it out. I guess I needed a bit of a reality check.
Edit: This probably means that I need to apologise to Warfley too...
@Warfley: I'm sorry I accused you of digging you heels and closing your eyes, that was mean of me and I profoundly apologise for it.
But I will still maintain that we have very opposite views and I'm conceding that we should agree do disagree.
Cheers,
Gus