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.
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?"
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.
> 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.
> 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?
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!
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?
> “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".
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.
> It literally produces the website that the user is looking at.
Your definition is meaningless because EVERYTHING in the pipeline literally produces everything "you are looking at" from the database to the css.
> Unlike, say, a micro-service that retrieves some data.
That data still produces part of "what you are looking at". What a useless phrase. Stick to industry definitions, yours do not make sense. And there is no language called "micro-service". I asked you to name the so called "non-user-facing" part of the web development stack.
> If you paid attention to what I write you could've seen this: "Client-side dev has hijacked the term frontend to describe purely client-side development. ".
So, old man yells at the cloud and uses his own idiosyncratic terms. What matters is not who hijacked what. What matters is that the industry has settled on the term "front-end developer". Complain as much as you want, but realize that train left the station. Go ahead and use your own terms that no one understands because "my 23 years experience", but that's exactly how people fall out of touch. And then when you say thinks like "PHP is front-end dev" people will immediately dismiss your knowledge, so you have to keep reminding them "but look.. my experience!" The term is "front-end dev", deal with it.
> "OMG PHP runs in the server this is backend unlike this JS code that literally does the same"
Old man yells at a language that can be used both in the cloud and browser.
When JS is executed in the server (e.g. Nodejs) is it part of the back-end stack. When it is executed by the browser, it is part of the front-end stack. When it executes on both, it is full-stack. Kapish?
> I'm not sure how long you've been in the industry. But you sound like it is less than maybe 10 years.
Okay. No offence, but so do you.
> Before react and such, you were considered a frontend developer when you delivered your javascript + html + css from any backend, though typically it would be served by php, RoR, or, more limitedly, by some python.
Not really. Back in the day, before the great divide [1], the terms we used were "Web Designer" and "Web Developer". We also had "Flash Developer" but I digress. A web designer was expected to know all the front-end stuff including JS, since the front-end was not that complex. Almost all complexity was at the back-end, and that was the job of a web developer. The term "front-end web developer" simply did not exist in 2003. There was nothing to "develop" in the front end, since all complexity was on the back. Yes, there were some exceptions, but in those days, PHP was king. React is current king, and it's funny how it gets the same hate PHP got back in the day. Some people just like to tear down and burn whatever is at the top. Reacts successor will get the same hate. Thats how you know who the king is.
> Again, back in the day, you wouldn't call yourself a backend dev if you did anything meaningful with html UI. You would still call yourself frontend even though you had to work through templating in a given backend language.
Wrong. Why would someone working on PHP and MySQL call themselves frontend? So who were the backends back then? Strange thing to call yourself "front", when no one called themselves "back", don't your think? Like I said, the
terms back then were web developer and web designer.
> Source: I've been doing this for a couple of decades.