Node.js Rival Deno Gets Seed Capital For Full-time Deno Engineers (infoworld.com) 74
"The creators of Deno have formed the Deno Company, a business venture around the JavaScript/TypeScript runtime and rival to Node.js," reports InfoWorld:
In a bulletin on March 29, Deno creator Ryan Dahl and Bert Belder, both of whom also led the development of Node.js, announced the formation of the company and said they had $4.9 million in seed capital, enough to pay for a staff of full-time engineers working to improve Deno...
Dahl and Belder said that, while they planned to pursue commercial applications of Demo, Deno itself would remain MIT-licensed, adding that for Deno to be maximally useful it must remain permissively free. "Our business will build on the open source project, not attempt to monetize it directly," they Deno authors said.
From their announcement: We find server-side JavaScript hopelessly fragmented, deeply tied to bad infrastructure, and irrevocably ruled by committees without the incentive to innovate. As the browser platform moves forward at a rapid pace, server-side JavaScript has stagnated. Deno is our attempt to breathe new life into this ecosystem...
Not every use-case of server-side JavaScript needs to access the file system; our infrastructure makes it possible to compile out unnecessary bindings. This allows us to create custom runtimes for different applications: Electron-style GUIs, Cloudflare Worker-style Serverless Functions, embedded scripting for databases, etc.
Dahl and Belder said that, while they planned to pursue commercial applications of Demo, Deno itself would remain MIT-licensed, adding that for Deno to be maximally useful it must remain permissively free. "Our business will build on the open source project, not attempt to monetize it directly," they Deno authors said.
From their announcement: We find server-side JavaScript hopelessly fragmented, deeply tied to bad infrastructure, and irrevocably ruled by committees without the incentive to innovate. As the browser platform moves forward at a rapid pace, server-side JavaScript has stagnated. Deno is our attempt to breathe new life into this ecosystem...
Not every use-case of server-side JavaScript needs to access the file system; our infrastructure makes it possible to compile out unnecessary bindings. This allows us to create custom runtimes for different applications: Electron-style GUIs, Cloudflare Worker-style Serverless Functions, embedded scripting for databases, etc.
Hopelessly fragmented? (Score:3, Insightful)
Obviously we need a new solution everyone can get behind! I'm sure 50% of you immediately thought of this:
https://xkcd.com/927/ [xkcd.com]
On a side note - what the heck is the business model that got them several million dollars in venture capital?
Re: (Score:2)
Re: (Score:2)
server side JavaScript (Score:4, Insightful)
Re: server side JavaScript (Score:2)
Re: server side JavaScript (Score:1)
Re:server side JavaScript (Score:5, Insightful)
Yeah they do. Having run a development team, I can venture a guess why: it's a burden maintaining team skills the lager the number of skills your project requires. And in a lot of projects, you have to include Javascript *somewhere*.
It's not so bad as it would sound though. Javascript was inspired by Scheme, and while it may not look much like Lisp it actually supports functional programming pretty well, and functional programming simplifies a lot of server-side problems.
Re:server side JavaScript (Score:4, Insightful)
No, it really isn't. What's a burden to your business is taking people who don't do server side programming and don't understand all of the complexities and having them write the backend for your business. It can be a stop gap on a small team, but you're going to lose out in the long run over just hiring someone who knows what they're doing. All you're doing is setting up your company to fail.
Re: (Score:2)
UI code is much different than backend (Score:2)
Yeah they do. Having run a development team, I can venture a guess why: it's a burden maintaining team skills the lager the number of skills your project requires. And in a lot of projects, you have to include Javascript *somewhere*.
If the language matters, you're doing it wrong. When you know what you're doing, you're wiring in existing libraries. Every business problem has been solved somewhere. Anyone who tells you how much they love a language is bad at their job...especially if they're comparing one typed language to another. I suppose broad categories, like is it typed? do you have to manage memory? (like C), but beyond those broad considerations, a good programmers spends all day wiring in libraries...rarely writing "pure" c
Re: (Score:2)
Yeah, I never saw the surprising elegance (well, when compared to Java everything short of brainfuck seems elegant.) But what am I supposed to get, cause I sure as hell don't get whatever it is. And I want to understand why people I think are smart like it. All languages have callbacks/events/map-reduce, and those seem to be the only differences I really noticed. (I'm sure I noticed more
Re: (Score:2)
Wow you say elegance but what you really mean is im lazy and prefer to type as little as possible even when my code becomes mush.
Re: (Score:2)
JavaScript is a surprisingly elegant language.
No, it isn't.
Elegance is not needed, reliability is! (Score:2)
No other trade wants FEWER tools.
Nonsense. No carpenter, for example, wants a zillion specialized screwdrivers for every damn thing. I say put #2 Philips heads on as much stuff as possible. Who wants 20T heads on some things, those weird square security bits on other things, flat heads on other things, etc.? It's preposterous.
So you're saying every carpenter carries around 1 screwdriver? Your explanation there shows me you've never actually done much with carpentry or wood. The square drive is actually quite superior to the Philips head. It gives more force and control and is far less likely to strip it. Kreg and Spax standardized to support that for good reason. The rest I've seen use square or torx. Philips heads slip out of the fastener if you don't use them in a very precise way. Philips and flat heads are very imprec
Re: (Score:1)
For starters: JavaScript is not untyped.
The rest of your post only makes marginally sense, most is wrong. However you could tell us why JavaScript is "a poor language" - perhaps it makes us laugh a bit.
Re: (Score:2)
Playing american lawyer are we ? Pretend this and that and avoid the big elephant that javascript code analysis is a disaster zone.
Re: (Score:2)
Does not change the fact that we have two orthogonal definitions about types: dynamic typed versus static typed, JavaScript is the former. And weakly typed versus strong typed, JavaScript tried to be the later, but with stupid type coercion rules they failed it. Then we have untyped ... like assembly and forth.
It helps to know the differences. Also outside of academic circles :P
Re: (Score:2)
Javascript is a shitty language because tools cant understand it properly, there i said it, javascript ides are basically text editors with a few extras like a built in debugger etc. Try and refactor a medium sized project and you will get failures later at runtime because the ide is basically doi
Re: (Score:2)
It does not care about types it only cares if functions are found on the object or prototype chain when its time to dispatch.
Yepp, as you would expect from a dynamic typed language, facepalm.
Actually javascript is not typed Wrong.
you will never get. class cast exception at runtime. As you would expect from a dynamic typed language, facepalm.
Try and refactor a medium sized project and you will get failures later at runtime because the ide is basically doing a text search/replace.
Then get a better IDE?
I'
Re: (Score:2)
You dont need to work with javascript to see why ides cant refactor, the problem is due to type information missing from the source.
>> Try and refactor a medium sized project and you will get failures later at runtime because the ide is basically doing a text search/replace. >Then get a better IDE? Like ?
I am, every single IDE has the same problem. This is very easy to verify pick any js IDE and check out their lack of refactoring options.
Re: (Score:2)
You dont need to work with javascript to see why ides cant refactor, the problem is due to type information missing from the source.
The type information is usually deducted with "type interference". So all IDEs I use, as Eclipse and IntelliJ variants, refactor JavaScript just fine.
Re: (Score:2)
Type inference does not work well the larger the scope. This is one primary reason why java limits the scope of var to just the method, because it becomes a disaster zone when the scope get larger.
> So all IDEs I use, as Eclipse and IntelliJ variants, refactor JavaScript just fine.
They are not refactoring they are search and replacing text. This is very easy to prove, go read cedric beust blog for an example and verify yourself
Re: (Score:2)
We have fine refactoring in Groovy.
And AFAIK that works in JavaScript, too.
As long as you have the whole code in your project, the tools can infer types just fine (since > 30 years, because that "refactoring" term was invented for CLOS and other lisp dialects - long ago).
Re: (Score:2)
What do you mean you think you know , you either do or dont ?
> As long as you have the whole code in your project, the tools can infer types just fine (since > 30 years, because that "refactoring" term was invented for CLOS and other lisp dialects - long ago).
Not discssing the origins. -> https://www.beust.com/weblog/d... [beust.com]
Re: (Score:2)
http://www.informatik.uni-brem... [uni-bremen.de]
I suggest to follow the references :P
Re: (Score:2)
Re: (Score:2)
THe language only matters when the attributes of the lang affect the tooling. Todays javascript tools especially in the areas of refactoring etc are a joke compared to statically typed languages like java.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You don't make any decisions based on any single factor, unless it is cost. And the structure and impact of costs depends on the kind of team you are running an the kind of organization it serves.
A development team is a fabulously expensive thing to run, and idle time burns money like crazy, so you need to keep everyone's utilization rate as high as possible. That may not be so hard in a large company running multiple large teams of developers, but in a small vertical market vendor has higher utilization
Re: (Score:2)
A development team is a fabulously expensive thing to run, and idle time burns money like crazy, so you need to keep everyone's utilization rate as high as possible.
Which is why one optimizes the skill sets. Again, it is bad management to hire people without the needed skills. If the manager knows there will be server side work, the manager better be hiring people who can do the server side work in an appropriate language. Javascript is not an appropriate language for server side work. The manager failed to hire appropriate skills for the development team and thinks that is an excuse to use a shitty solution. That means that manager is a shitty manager and should be f
Re: (Score:2)
You're making judgments in the abstract. It's one thing if you hire a team to do a specific project, but in a long standing team the "required skills" are a moving target.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Interesting)
I work in a largish web company that is mainly Perl-based for historic reasons. We got some new management that decided to start moving us to node.js, because we had trouble finding Perl devs nowadays. I objected that quantity does not mean quality and perhaps we should consider other options apart from node.js, but I am not management. Long story short, we hired some actually good node.js talent (some luck there), but our existing engineers who had quite some experience in Perl, soon discovered node.js was
Re: (Score:2)
It's not that bad. Javascript is the new perl in the shit-upon category. As always, people can write shit code in any language. At least with typescript it will definitely make things easier on the idea front so you don't spend an hour trying to figure out why your redner method isn't working.
Re: (Score:2)
Uncompiled langauges are terrible for maintenance (Score:5, Interesting)
Do people really do server side JavaScript, for the mother of god why?
If you've ever run a large team and think server-side JavaScript is the best choice, I'd be surprised. It think the issue is that people recommending it don't have a lot of experience running applications. When your team is small and super sharp, you can use any language you want. I call it the "minivan test." If you can fit your entire team in a minivan, then do whatever you want. This is especially true if your app is never going to make money or you assume you'll always have the same team maintaining it.
Once money is on the line, languages like Java and C+ shine. Python and JavaScript apps can be written quickly by smart people, but what happens 10 years down the road? You need every advantage you can to keep a legacy app running and compilation is a huge advantage once your app makes money and you need to do library updates. Most of the complaints around Java & C# being too "ceremonial" are not really faults of the languages, but business best practices and while some are excessive, features like sensible encapsulation really make sense once the application has switched hands 10x as the original author gets promoted and your team experiences turnover.
In my experience, node.js and python apps tend to be very idiosyncratic. Java, in contrast, is pretty bland. The best practices are so well documented that nearly all Java code looks alike. It's very uniform and easy to understand because everyone is following the same patterns, primarily. This is hugely advantageous when you have to read code written long ago by someone who left the company.
I have inherited node.js apps and they were a huge nightmare to maintain. The author utilized some libraries from Google in the app. A year after we started, they changed the method signatures for no clear reason...in Java, that's super easy...keep fixing things until the compiler is happy. In JavaScript, a basic error like calling a deleted method requires a unit test to catch...or your customers catch it. It turns out his unit tests weren't as good as the thought they were and it took us weeks to find all the method signature mismatches....weeks of QA, angry managers, and frustrating release cycles, unsure if your changes will cause regressions.
If you're relying on your team to write good Unit Tests, as you do with JavaScript, you're really screwed. Most developers write SHIT unit tests. I try to be an exception and I work really hard at it, but I'm never confident I have covered every scenario...and even if they write perfect unit tests, do they update them perfectly for each iteration? It's really hard to do for complex apps that make money. You need every tool in the toolbox to keep your application bug free and your company profitable.
All these war stories lead to the conclusion that if you think an uncompiled language is suitable for an app that is destined to make money, you really haven't been around the block for very long and certainly have never had to inherit applications from people who have left the company...which happens at all businesses. JavaScript is a TERRIBLE language. Even people who work with it all day will concede that. It was never designed to be a language for business processing and there are so many better choices. I hope this fad dies out sooner than later.
Re: Uncompiled langauges are terrible for maintena (Score:3)
If you're using a third party library, then it should be version locked in your package.json. This sounds more like a problem of not understanding the ecosystem.
Security and bug fixes kill your theory (Score:5, Insightful)
If you're using a third party library, then it should be version locked in your package.json. This sounds more like a problem of not understanding the ecosystem.
Incorrect. You are misunderstanding. The app didn't break itself. An automated system informed us the library had security issues and we needed to upgrade. This is par for the course for any language. You need to keep updating, typically to the latest version to get the bug and especially security fixes. So, no, node.js apps don't simultaneously break due to library upgrades. I was forced to upgrade a Google library to the latest version and what would have taken me a day in Java took several weeks...mostly because the original author quit, the test coverage wasn't very good, and the uncompiled nature of JavaScript made it easy to find things compilers will find by default.
I understand the ecosystem. I've written and maintained professional apps for a profitable company in both Java and node.js. It's not just me, the Java teams have the best record at meeting estimates and releasing on time, similarly for our C++ and Scala teams. The python and JavaScript teams have the most overruns...partially due to the type of personality that is drawn to uncompiled code (not very meticulous and typically very idiosyncratic) and the tools themselves not helping. If you knew Java really well and knew node.js really well, you'd concede that node.js for whatever benefits it brings, has a lot of fundamental issues you won't find in Java/C#/Go/Scala/etc.
Re:Security and bug fixes kill your theory (Score:4, Interesting)
Re: (Score:2)
The author utilized some libraries from Google in the app. A year after we started, they changed the method signatures for no clear reason...in Java, that's super easy...keep fixing things until the compiler is happy. In JavaScript, a basic error like calling a deleted method requires a unit test to catch
Clearly you had a versioning problem. That's hardly JavaScript's fault.
I try to be an exception and I work really hard at it, but I'm never confident I have covered every scenario.
But there's coverage measurements for that. Any decent environment allows you to calculate that, no need for guessing stuff.
Why not use a better tool to begin with? (Score:5, Insightful)
The author utilized some libraries from Google in the app. A year after we started, they changed the method signatures for no clear reason...in Java, that's super easy...keep fixing things until the compiler is happy. In JavaScript, a basic error like calling a deleted method requires a unit test to catch
Clearly you had a versioning problem. That's hardly JavaScript's fault.
I try to be an exception and I work really hard at it, but I'm never confident I have covered every scenario.
But there's coverage measurements for that. Any decent environment allows you to calculate that, no need for guessing stuff.
Versioning problem? I think you misunderstood. I intentionally upgraded because a 3rd party scanner detected security violations, so we needed to upgrade to the latest version. In general, most teams upgrade libs to the latest version periodically to ensure they get the most up to date fixes. There is not a versioning problem, that's just how business works for professional software engineers. You need to ensure your 3rd party libs are updated whenever a vulnerability is found.
Your more interesting point is code coverage. What you are saying is to combat a huge and fundamental disadvantage to JavaScript and every untyped language, we should engage in code coverage exercises. First of all, if you know your way around code coverage tools, you already know that line coverage is not logical coverage. You can have 100% code coverage and still have LOTS of bugs. There's no tool that can predict very bug imaginable. However, there are many bugs in untyped code that a unit test would never catch.
A simple example is a math problem. If you had a function to the percentage increase...you can have perfect unit test coverage in JavaScript, yet still have bugs where people can insert strings or objects into your function. A typed language would make this impossible.
But even putting code coverage aside, you're suggesting doing a whole extra exercise of code coverage to compensate for the flaws of an untyped language. Why not just use a typed on in the first place? It's more accurate and doesn't rely on the author writing good unit tests, which let's be honest, VERY FEW do. I have had probably 1000 coworkers in the last 15 years and met maybe a dozen that write good unit tests. Half of them don't even write them until being forced to and the even then they write useless ones.
No matter how many ways there are to make JavaScript suck less, having used it, I don't see any advantage it provides that other languages don't do better. 10 years ago, it had better support for non-blocking-IO, but that's typically a parlor trick with little business value (streaming JSON is useless when your DB or remote service calls are the real delay)....but in those 10 years, the other platforms have caught up. I don't see any positive to using JavaScript when you don't have to.
I hear some say "I only need to learn 1 language" but anyone who says that has never been a professional developer. UI code you write in JavaScript bears little resemblance to competent backend code. Similarly, Java code written in Swing or for android is nothing like server-side Java code....different paradigms, different libraries, different best practices...it's like all those awful garbage technologies that tried to rewrite SQL in Java, but only made things terrible. Smart teams pick the right tool for the right job, not try to retrofit their favorite tools to do things they were never designed to do and do poorly...like JavaScript on the backend or Java to replace SQL.
Software engineers are the only professionals I have seen who see a terrible tool for a problem and see that as a challenge. Carpenters don't look at a circular saw and say "hey...I wonder if I can turn this circular saw into a sander...they just carry a sander for sanding and a saw for cutting." They don't look at a hammer and say "hey...I wonder if I can turn this hammer into a screwdriver?"...they just learn how to use both and use the best tool for the job. Why don't developers do the same?
Re: (Score:2)
I tend to agree about Javascript, but can I delve more into unit tests. I never really grokked many use cases for them. If they are essential replacing compile-time type checking, I understand the value (although, as you point out, why bother with JS then.) Can you point me at some other issues unit tests may catch?
I do understand the value of writing some tests at a non-function level for, for example, how does the client handle attempts to update when the server is down. But that always seemed to be t
Re: (Score:2)
I feel that unit tests should cover boundary conditions and invariants. Simple map (transformation) functions aren't good candidates for unit testing, unless they have specific inputs that are dealt with in an exceptional way (such as triggering an error or returning a sentinel value).
Re: (Score:2)
JavaScript is a typed language!!
So not really sure what your problem is. Besides mixing up dynamic typed languages, like JavaScript and Python e.g, with static typed languages like Java, C++ and C# etc. with untyped languages like Assembly or some stone old BASIC variations.
If JavaScript does not work for you, you should find an alternative - aka - a solution.
Does it matter - untyped vs dynamically typed? (Score:2)
JavaScript is a typed language!!
So not really sure what your problem is. Besides mixing up dynamic typed languages, like JavaScript and Python e.g, with static typed languages like Java, C++ and C# etc. with untyped languages like Assembly or some stone old BASIC variations.
If JavaScript does not work for you, you should find an alternative - aka - a solution.
OK Dynamically typed if you want to get pedantic, but does that change anything? The bottom line is you lose a compiler checking the bounds of your inputs automatically, making large classes of errors easy to find.
Also, we agree. JavaScript does not work when money is on the line and you have to plan 5 years down the road when you move to another project, get promoted, deal with turnover and an evolving application, etc. I have alternatives, but I am not the sole decision maker in my company. I have h
Re: (Score:2)
The difference between the various type systems is important if you want a degree in computer science.
Lol: Resume driven development, nice term.
You illustrate my point perfectly! :) (Score:2)
Python and JavaScript apps can be written quickly by smart people, but what happens 10 years down the road?
In 10 years I'll be LONG fucking gone and I won't give a shit.
You are the perfect illustration of the problem. :) I wish you were rare, but I think you're the norm. I inherit your shit after you've left and am responsible for evolving your project to changing requirements after you leave.
:)
If you're not going to write documentation or unit tests, the least you can do is use a compiled language to make my life a lot easier!
Re: (Score:2)
Software is more of a hustle than a profession (Score:2)
Most Software engineers if you want to call them that today barely write tests at all. Go look at github, 9 out of 10 projects have basically no tests, then again its hardly a shock considering they cant even be bothered to write a one liner in the README to describe what the goals of the project are.
Most jobs I've had, while very lucrative, are more of a hustle...a quick rush to get something viable out the door than a profession that considers long-term consequences. IMO, everyone is at fault. The business folks never know what they want, just that they want it quick and they want it cheap. They're usually quite disappointed when you go through their requirements and ask follow up questions to fill in all the gaps. The managers rarely know what is going on in the project. Most just sit in meeting
Re: (Score:2)
Hustle or not thats irrelevant. Lets pretend it takes you a day to implement a feature or bugfix. The easiest way to verify said feature/bug fix is to write tests, notice i said easiest and most efficient. Aft
Re: (Score:2)
Re: (Score:2, Insightful)
Do people really do server side JavaScript
Yes. Just as people use other languages and other platforms server-side.
why?
Because it works, and in the hands of a good team, it works quite well.
Just as other languages and other platforms often do.
There are pros and cons, with all combinations. None of them fits everyone, due to differences in team composition, existing technical debt, major focus area of development, recruitment opportunities, chosen technical stack, goals, and a whole bunch of other factors.
Please do not just parrot what a bunch of know-it
Re: (Score:2)
Everything works in the hands of a good team. Agile or Waterfall. JS or C. A good team can make any of that work.
Re: (Score:2)
Because it works, and in the hands of a good team, it works quite well.
A good team can also nail jello to a wall. That doesn't mean nailing jello to a wall is a good idea.
Re: (Score:2)
Re: (Score:2)
First answer: why not?
Secondly: that is what they are best at. Not everyone wants to "retrain" to Java. And there is no real alternative anyway.
Third answer: the library/framework support.
Fourth: limited but working meta programming abilities.
JavaScript only has two drawbacks: awkward historical incorporation into browsers, and a buggy type coercion concept of primitive types.
Most of that is compensated by using languages, like TypeScript, that compile to JavaScript.
I was initially confused (Score:3)
Node.js Rival Deno Gets Seed Capital For Full-time Deno Engineers
I actually read that as "Demo" and was really confused. Can't wait for the inevitable Deno Demo. Anyone who really likes/hates it can have a Deno Demo Demonstration to cheer/protest it. I'll be there, wearing denim or maybe not, I dunno.
Prove it (Score:2)
Our business will build on the open source project, not attempt to monetize it directly.
Ok, then hand oversight over to a foundation like Apache (not Apache though), Mozilla, wikimedia, FSF, etc. even a brand new one.
Re: (Score:2)
"Our business will build on the open source project... until it achieves enough traction that we can depend on the pain of migrating away from it making it likely monetization will result in profits."
But Still Async Nazi's ?? (Score:2)
I think npm is a giant chaotic mess. However my main concern is, why they still be async Nazi's, demand everyone just learn to code async, even in places where sychronous processing is necessary or better, such as database operations in data process.
Also, are they going to continue down the path of trying to make JavaScript more like Java and other conventional OO languages? Still not getting why loose types and proto-type OO were chosen in the initial design of JavaScript? Not getting the theory of it.
Re: (Score:2)
There are some reasons (Score:2)
I think Deno is a big conceptual improvement on NodeJS in this regard because it's more like a headless browser. It uses the same import / module mechanism as
Re: (Score:2)
Probably the best reason I can think of for using JS on the server side is you can share code & state. e.g. if I had a complex model shared between the client and server then both sides can run the same code for it.
If you have a complex model that involves state sharing between client and server, you shouldn't be using stateless protocols.