> “This time we can make an app based on web technologies for real!”
> - it failed when Microsoft tried it
VS Code is one of the most successful open source cross platform GUI apps of all time. Who would have thought that good ol' HTML would finally fulfill the promise of "build once, run everywhere".
VS Code is a great success of Electron-based apps but also has massive memory usage and performance bloat that comes with this style of app, see https://news.ycombinator.com/item?id=19144039
Sublime Text is implemented natively (C++) and uses a fraction of the resources to accomplish similar functionality. I know we live in a period of plentiful system resources where RAM usage no longer practically matters, but using 1.5GB RAM for a few files open seems insane, even more so that this is now normalized.
> Sublime Text is implemented natively (C++) and uses a fraction of the resources to accomplish similar functionality.
If VS Code is slower than sublime with the same level of functionality, why does it currently totally dominate the market? Is it because devs just love Microsoft?
VS Code has a quasi-IDE implemented for a bunch of popular languages including a debugger [1]. Sublime is a straight text editor, with limited debugging capability. Sheer usefulness beats performance, so VS Code won the editor war.
Sublime Text is an independent product from a small developer; VS Code is actively pushed and marketed by Microsoft, one of the biggest, best-known companies in the world.
That may or may not be the primary reason for the difference, but I don't think it can be ignored.
> If VS Code is slower than sublime with the same level of functionality, why does it currently totally dominate the market? Is it because devs just love Microsoft?
Because it only has the same level of functionality when you conveniently ignore how easier it is to write plugins
Sublime Text and VS Code are pretty different, despite looking superficially simmilar. VS Code gets much further along the path to being a full IDE (albeit not completely), where Sublime is more of a pure text editor.
At what cost? VS Code is a trillion dollar company throwing thousands of man-years at the problem and still running into issues like "we can't make the terminal fast enough because of web tech": https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...
It is free! Free as in free beer. So all those trillions are going to very good use, considering it is the most used editor. And its open source too!! What a web tech success story this one...
> and still running into issues like "we can't make the terminal fast enough
Imagine that! A cross-platform code editor with its own configurable integrated terminal that hooks into the apps extension system. But someone wrote a blog post in 2017 explaining some performance improvements, so bring out the pitch-forks and burn it all down!
Yes. Not all discourse has to be literal. It's called a a metaphor. And your "trillion dollar company throwing thousands of man-years" is called a hyperbole. You are talking about the most successful cross platform code editor of all time, so if you want to be taken seriously, use level-headed arguments rather than emotional exaggerations.
> but at this point it's clear you're not interested in discussion beyond low-level trolling.
> Adieu
I wouldn't consider a discussion where someone cites a 6 year old blog post about performance improvements as proof of "throwing thousands of man years" as a serious, or worthwhile discussion. You can go. Don't let the door hit you on the way out.
So what exactly are you asking for here? A list of PWA api's that must be used all the time in every single PWA app? What's the benefit of that? Which application development API has such an asinine requirement in the first place?
> Because of this you will always have people scream "Apple is killing PWAs" because they don't support a yet another random API.
I like the "yet another random API" phrase. It creates the impression that PWA APIs are being generated fast and furious, and apple is trying very hard to keep up with all these "random" new APIs.
Yet, the reality is that apple has for a long time deliberately crippled PWAs on their platform by not supporting just 4, crucial, old and fundamental APIs. I will list these for you:
- Background Sync
- Web Push
- Before Install Prompt and Installation Banner
- Background audio for PWAs
They do not have to implement any "yet another random API". Just those four. Everything else is a bonus, considering this is Apple's Safari (the new IE) we are talking about.
Imagine going 2000 years back with a book and showing it to some caveman. To you they are words, with meaning and purpose. To him, they're just random gibberish scrawled on some leafy stuff. He might even nibble on one of the pages and declare "it doesn't even taste good, what can be its use?"
Imagine having a discourse in good faith. Imagine not resorting to false analogies. Imagine not resorting to low-effort trolling the moment you run out of arguments. Imagine...
Anyway. I bid you adieu in a sibling thread, I'll do the same here.
haha. Seriously though, do you honestly believe that is what you are doing here? You think you are acting in good faith?
> Anyway. I bid you adieu in a sibling thread, I'll do the same here.
> Adieu.
You cannot even keep track of all your "adieus". Are you saying goodbye to a thread, or to an individual? Or is it all just random. lol
FYI: I do not respond to individuals. I respond to comments. Usually asinine comments because they trigger me. So the best way to say goodbye to me, is to think before you post.
I feel you are putting yourself, and others in a box. We all can gain more clarity from an idea by talking, writing or drawing about it. You don't have to be good at it, it will still improve your grasp of the problem. Of the three, writing is the slowest, meaning your mind takes more time and effort. And the time spent on something has a direct relation to its quality.
Long story short, you will become an even greater engineer by drawing and writing out your ideas.
This kind of reminded me of the module pattern [1] popular with ye olde jQuery plugins. Just realized that hooks try to emulate what JS does natively, which is keeping track of all local variables in a functions calling scope. Meaning that if that function returns an object, that Object still has access to all the variables declared when that function run.
