The JavaScript ecosystem is 'hopelessly fragmented'... so here is another runtime: Deno is now a company Deno, the JavaScript runtime from the creator of Node.js, is now a company with nearly $5m to fund development – though its developers say it will remain "permissively free." Deno 1.0 was released in May 2020 by Ryan Dahl, Bert Belder, and Bartek Iwańczuk. Dahl, the original developer of Node.js, had reflected on what he …
Pah Javascript, when the One True Language is making a comeback (admittedly in 20th place)
Smalltalk is not even on the list :-(
gone south like Trump in the Forbes' World's Billionaires List. Though he is still on the list, so more like Kylie Jenner who is no longer on the list.
https://www.bbc.co.uk/news/world-us-canada-56657188
"C" would therefore be "Jeff Bezos" of programming languages
Have you ever tried to download Firefox Android without GooglePlay?
You can't even get the APK these days, they send you a link to open in Chrome to take you to Google Play *Store*. It's not even a link to the APK. So people who don't want Google surveillance crap have to accept Google play store surveillance crap instead.
I mean, big whoosh. They bang on about privacy but require you give an email address to send a link, and the link they send is to one of the most privacy invading app stores on the planet. Once downloaded they even opt you into their metrics sending by default too.
So the major reason for opting for Firefox is neutralized by trying to install it.
There seems to be a disconnect there between their stated aims and their actions at Mozilla. Clueless leadership methinks.
Sorry, but where you get it from does not make it any less privacy-respecting.
Unless you have a recent Huawei phone, you've got the Google Play Store and there's no other option to get stuff without rooting the phone, so it's hardly a dent in Mozilla's efforts to get you a privacy-respecting browser.
By 'fragmented' are they referring to the fact that even installing a relatively simple project with a few direct dependencies can instantly cascade into npm downloading over a thousand sub dependencies?
I'm afraid I've always thought that server side JavaScript was utter madness and the dependency hell on steroids from Node.JS just gives me nightmares..
I know Java developers who couldn't tell you what a file descriptor or a BSD Socket is, so it comes as absolutely no surprise that JavaScript developers who are even further abstracted from the hardware and OS, may not have any clue about the core principles of what happens underneath. Perhaps some would argue this is unimportant and throw in a car engine analogy for good measure, but in the real world when this magical code isn't working, a grounding in the underlying tech can pay dividends when trying to diagnose issues.
It's curious that the very creator of Node.JS is now claiming that it's really broken. I wonder whether Deno is any less horrible.
It's exactly that but as a scripting language itself, it's fast with strings... that's about it. The other thing is about using the word "Server" combined with "WASM". This doesn't make much sense as if you're going to write it in C or C++, then you can just create a C/C++ module for both Node and/or Deno. So bragging about supporting WASM (A.K.A. C/C++) when you already support it seems desperate and oddly forgetful. Deno isn't less "horrible", but it's Typescript nature seems a little late to the party (see next paragraph).
Lastly, WASM can call JS directly so you can embed JS calls right in the C/C++! So, instead of using a POSIX/OS analogy, a more efficient analogy in context of WASM (if you care about wall clock, assuming 100% you do) would be something like embedded C in SQL. This fact is overlooked by 99% of the WASM articles you read about yet it's the most efficient way to use WASM.
https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#calling-javascript-from-c-c
The Deno security model is different - e.g., file system permissions are granted at the execution level. There is also a Deno-verified library, as opposed to npm which is, yes, messy. And many other fundamental changes. I see it as potentially more of a thoughtful well designed incremental improvement than a duplicate "me too" equivalent standard. Might or might not succeed. The is no improvement without the risk of trying. I see no harm in duplicating the successful parts, i.e., I don't think "incremental improvement" is necessarily inferior to "revolutionary improvement".
According to it's history, Javascript was designed in order to remove the need for a server call when performing simple operations such as validating input (obviously this waaaaay pre-dates the current situation where server-side validation is a must for security reasons and people are deliberately disabling Javascript because of how badly it is abused for tracking/ads/malware delivery).
Javascript is for client side development - it is not fit for purpose as a server-side language. This situation with node is just the latest proof of this fact.
Javascript is for client side development
I think we need to distinguish between the language and what it is actually doing. As a language, JavaScript is very much in the same bag as PHP - simply needing the addition of a few rocks and dropping in deep water. Why anyone would voluntarily use it for server-side programming given myriad more suitable options is a mystery.
On the client side, the problem is not Javascript, it's the fact that a document-oriented model is being violently abused to approximate a graphical UI and the "security" model facilitates and encourages fine-grain stalking. Use any other client-side language and the results would be as awful, slow and inconsistent.
Mind you this is hardly the first example in computing history of displacement activity - attempting to solve an already-solved problem while studiously ignoring the elephant in the room, the irresoluble dichotomy of the browser as on the one hand a presentation model for structured documents and on the other as a GUI toolkit.
Almost all the comments so far seem to come from developers (or at least technical commentards) and I can appreciate the differing opinions from that perspective. However I'd like to consider this from the perspective of the oft forgotten web user. It seems that this is yet another move (whether intentional or not) towards excluding anyone who isn't on the "upgrade" treadmill. There are plenty of very good reasons for not being on it - not least a need to avoid a constant learning curve that gets in the way of just using systems to do jobs, and of course the desire to avoid the constant spend that the industry demands of us all. However we are progressively being bludgeoned onto compliance with its demands - not least by "bleeding edge" web devs. For example, an online portal I have to use for business has recently been progressively "updated". It worked perfectly well before, but first one of its services, then another, and finally a week or so ago even the login ceased to work on anything but the latest browser with all security disabled. This does not seem like progress to me, as no new services or features have been added - it's just been made less accessible to authorised users.
And the latest abomination - Streetmap, the only UK mapping site that worked perfectly well (at least a couple of days ago) without js enabled, doesn't any more, even with js enabled. Probably needs a typescript enabled browser - thank you so much.
I'm amazed that service providers, retailers and other businesses don't seem to be concerned that their web devs are losing them potential customers by restricting who can access their web sites. The very first thing I said to every class when I taught web development was "you're not designing a site for your client - you're designing it for your client's customers. If you unnecessarily restrict who can access it you're damaging your client's business by losing them potential customers". That seems to have been forgotten in the rush to the "bleeding edge". The developer is now clearly more important than the client or their customer.
All of this, but louder for the morons in the back. And by morons I mean marketing and l33t haxors.
I'm abandoning more and more websites these days because they are badly made.They have become tedious at best and unusable on average.
I now have to use BOTH NoScript and Ublock just to make the rest usable.
Deno uses the same module import system as regular browser Javascript so it is way easier to make code that runs on the server and client side. It also has a better security model, a better, std lib, a simpler distributable (one exe) and can run Typescript directly. That would be its main selling points.
Personally I think it highly questionable whether to use Javascript at all on the server side, but if I had a reason to write something from scratch I think I would be favourably disposed to Deno.
We all prefer greenfield projects. You get to learn from your prior mistakes and not have to deal with boring old legacy. What happens when eventually Rust/Java/C#/Python/Your Favourite get mature wasm compilers with language independent DOM frameworks? You won't be tied to JS or TS back and front end so will Dahl realise that he just prefers type safety after all and Deno is a mountain of compromise that will have grown up out of a greenfield and move on? Make a new acronym of Node and start afresh? I wish him well with Deno, or eventually Edno or Oden...
"They also believe that for many of today's developers, the browser is in effect the client operating system"
No, it really isn't. He's thinking of webdevs which are to developers as paper plane chuckers are to 747 pilots and the problems start to arise when they want to chuck their planes at 35K feet. Promoting some guy who's designed trivial GUI trinkets on a web page into developing 24/7 backend server code is a recipe for disaster especially with asynchronous event driven junk like node.js which is even worse than threading in which to debug obscure race conditions. They might not matter on a web page but they sure as hell matter when you're dealing with transaction based critical company or customer data which must not be corrupted.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
