Comments by "Charles M." (@charlesm.2604) on "The Shocking State of JavaScript // The Code Report" video.

@sooomats Svelte is legit the most vanilla way to build a web app using a js framework. Jsx and hooks of React provide too much abstraction, Vue and its object based syntax is also different than vanilla js. A Svelte component is just a script tag where everything is vanilla js, including the state management, event functions, component lifecycle handling, etc... We're at a point where React codebases feel like they are written in a completely different language.
14
That's because JavaScript is a language that most devs started with so it is known by the majority of devs. Someone in the robotics making state of the art embedded systems knows JavaScript. People who want to enter the mobile ecosystem will start with JavaScript mobile framework before going native (Kotlin, Swift, etc...), people who want to enter back-end will start a nodejs framework before diving deep with Ruby and PHP, people who want to develop cross platform desktop applications will start with Electron before going the Java/C route. And also: startups. The amount of money and time they save is enough motivation to push their devs into all the headaches they'll suffer from because of JavaScript.
5
@ETXAlienRobot201 For a scalable MMO with https request, if you don't want to use managed services (Google/Amazon/Microsoft platforms or the Epic/Unity services), I'd say write your server with a WebSocket implementation in C#/Java. People shouldn't go in production with JavaScript for things JavaScript isn't intended to be used for, especially when you rely on third parties to make your project work.
1
@ETXAlienRobot201 Well you're kinda obligated to go with Web Assembly for Web clients though. Imagine the computing power your infrastructure will need if you do all the operations on the server side. It's either Web Assembly or JavaScript. Not that long ago we had Flash for this, but let's be honest it was ever worse. ClojureScript is a great superset for this purpose.
1
@ETXAlienRobot201 Flash is the runtime, the language is ActionScript and it was a different flavor of JavaScript, following the same convention authorities as the later. There is currently no alternative way to write web clients other than JavaScript or Web Assembly. When your project need a web client (e.g: most end-users targeted projects), you have no way to cleanly write it unless you use a superset and compile it down to JavaScript (languages like TypeScript, ClojureScript, Haxe, etc...). SaaS and managed back-end platforms aren't bad at all. They fill a need that we desperately needed, enabling access of highly advanced infrastructures to businesses of any size. Before GCP/AWS only a handful of companies had the resources and years required to build such infrastructure without getting into millions of dollars of debt. The pricing is also fair, it scales. So I don't see how one goes thinking it's a scam when it is as transparent as it gets. What I do agree with you on is the use of JavaScript and web technologies in a context different than the browser. Mobile, Desktop, Back-end, embedded, etc... Shouldn't be crowded by JavaScript considering its current state. For example it makes no sense to use WebSocket for a MMO instead of the TCP/UDP protocols unless you plan to make the client run in the browser.
1
@ETXAlienRobot201 Ok ok I'll stop you right there: by web client I mean a client that run in the browser, a front-end or a website in other words. Most end-user targeted projects need to be a website because that's the expectation of the consumer. The consumer expects to be able to use your application on any devices (laptop, mobile), everywhere (offline support), to be connected with other applications (Google G-Suite, social medias, etc...) and to be as fast as native (client-side routing, code splitting, hydration, etc...). Projects that don't need to be web clients are business targeted projects, the software that's being used inside your company (by your employees or applications) such as project management, APIs, communication, etc... There are a few exceptions and some end-user targeted projects don't need to be web clients (videogames, CLIs, etc...) and shouldn't be written with web technologies.
1
From my understanding WebSocket are a just a classic HTTP request being upgraded into a keep alive and you basically send and receive message on that. I never said that everybody was a company and needed an advanced infrastructure. I'm just saying it's a good thing it exists, not that everyone should use them. If you don't need a SaaS you can still get yourself a dedicated server like we've always done. It's good to have the choice though because it makes a lot of projects become a reality.
1
@ETXAlienRobot201 I think you're right about this philosophy being pushed by large corporations, after all these frameworks came from Google and Facebook in the beginning, GraphQL came from Facebook, TypeScript came from Microsoft, Node came from the Chrome Engine and Flutter came from Google as well. But why ? Is it because it makes the life of their devs more difficult since it add complexity as you rightfully stated or is it because they saw in the trends of how their users used their services an opportunity to make products that the consumer would prefer ? Before front-end frameworks it was a pain in the ass to make a web client, let's be honest we both remember the PHP + jQuery days. It's still a pain in the ass but it definitely got better. At the end of the day it doesn't even matter who instigated this trend and what their reasons were. The users want to consume software that way so we make the software that way. And JS frameworks definitely help us in that regard. I'm not talking about the wider state of JavaScript and Node. That I agree with you with all my heart (Kotlin guys, Kotlin ffs !), I'm purely talking about front-end.
1