If you want hot-deployed distributed Java VM HTTP app. server + JSON database you can use my open-source alternative: http://host.binarytask.com
It uses comet-stream instead of WebSockets.
But it's fully "joint" parallel on all cores.
The Deno Company
191–200 of 446 posts
Re: The Deno Company
#192The issue with Deno, personally, is that it feels like it doesn’t deviate enough from NodeJS to even make it worth taking the time to learn/migrate projects over to it. From what I recall, the only really new and nice features are:
a) sandboxed by default
b) no need for a node_modules folder since you can directly import from a URL
And is that really worth dumping loads of money into developing further? I just find it hard to believe people are going to bother with Deno any time soon - we’ve gone too far down the NodeJS road.
Re: The Deno Company
#193Earlier quoted context omitted.
Respectfully, your comment is way off topic, and nothing to do with discussing The Deno Company, and what it means for the Deno ecosystem. Not to mention, this is a very worn out, tired complaint that's been talked about ad nauseam. Reading angry swipes at web developers is not very interesting. Ok, you're not a web developer. So you stick to what pays the bills, why would you learn Node or Typescript? Same for web d…
I think you took the wrong tone from the parent comment; it sounds like this person was genuinely interested in sparking a real conversation about how people feel about the environment that they spend time in, and whether that could have dramatically shifted based on what they decided to or had to learn
Others said they didn't get the same tone as I did, so maybe I'm off there. I'm willing to reconsider.
I'll just give my opinion on the final sentence which I guess is the conversation we should be on.
"And the thing is, I don’t know if I just learned web dev if I would love this new approach to software that is eating the world and I would “get it”. Or if it just exists because JavaScript developers don’t want to learn something new."
I think the answer to this is a resounding "No, if you're not a web developer you will not 'just get it'".
I don't think one approach or the other is 'better', but it just depends on what your background is and how you got into programming, and that's fine.
These tools are meant for web developers. We are talking about the next iteration of NodeJS here. It's the whole point is that it merges web programming with systems programming. So if you're not a web developer, there really is no good reason to jump over unless you are just curious.
From the blog post: "The Deno company hopes to enable the millions of web programmers out there to maximally leverage their craft in other domains."
Re: The Deno Company
#194> Many are more familiar with the Chrome DevTools console than they are with a Unix command-line prompt. More familiar with WebSockets than BSD sockets, MDN than man pages. Bash and Zsh scripts calling into native code will never go away. But JavaScript and TypeScript scripts calling into WebAssembly code will be increasingly common. Many developers, we think, prefer web-first abstraction layers. Every time I read so…
I replaced recently an unreadable bash-script through a small maintainable JS program. It's doing the same thing as the bash script and accepting the same parameters but does not require a black belt in regexp and going through hundreds linux/unix command man pages to understand what it does. I think you'd be surprised how many modern applications are written in JavaScript or Python. One of the more prominent ones is…
There's that famous Knuth exchange with another programmer where Knuth develops a super-complex data structure and algorithm to solve a problem, and the other programmer responds "that's cool, but I can do that in a single command line by piping three Unix commands".
There is a case to be made for programmers being at least familiar with Unix utilities and shell scripting so that they can unlock the superpowers described in that anecdote.
However, I largely agree with your sentiment - I pretty much do all of my scripting in JavaScript and Python and would not be particularly happy to have to deal with a large bash script.
Re: The Deno Company
#195Earlier quoted context omitted.
Many companies would just never touch an AGPL package, and while there are other languages out there with commercial licenses (e.g. Delphi), those are not nearly as mainstream as the open & freely available ones. Deno is competing against Node.js, which is MIT-licensed. Deno is arguably better, but it would have to be _so much better_ to get people to even give it a second look if it was commercial.
Unfortunately Deno gave up on their most unique differentiator, the TS [runtime].
We most certainly did not, TypeScript is and continues to be a primary concern for us and we plan on continuing to support it as a first-class citizen of the ecosystem
Re: The Deno Company
#196Happy to see Deno get some financial backing! I've been building my new multiplayer games website [1] with Deno over the last 4 months and apart from some minor growing pains, it's been a joy to use. The lack of unnecessary package management, and the TypeScript-by-default approach makes Web dev much nicer. We're also using TypeScript on the client-side, relying on VSCode for error reporting. We use sucrase to strip…
Is the VSCode support good? I tried using Deno with WebStorm a few months ago and it wasn't a great experience.
Re: The Deno Company
#197Earlier quoted context omitted.
But you don’t get full control, and that’s why people go native. Because platforms rightly distrust web apps. This will likely be true for a long time as security becomes a bigger deal everyday.
Most "modern" platforms distrust native apps too. (Android, iOS and increasingly macOS, Windows and even Linux) This is one of the main reason that I often prefer web apps. (my preference obviously depends on the use case) I would much rather run a random company's messaging/video chat/whatever app inside my browser with strong sandboxing. Because browsers have truly accepted that applications should be considered ma…
This. I cannot stress how important is this for modern app development. Just like Deno doesn't trust any script that is passed to it, no user should trust an app just cause it's installed directly in the system (and I can't believe I lived with that mindset as well). The developers should grow cautious of any tool and library they install, and the user should inspect more often what kind of access is it giving to anything they browse on the web, cause at least there they can block it.
Re: The Deno Company
#198Earlier quoted context omitted.
Yeah, with the use of "it feels" this time I was literally trying to express the feeling of "oh no, another big divergence in js" like it felt at the time (even if it was indeed ad "ideological split" as you say, I remember clearly at the time a lot of blog posts about how it meant that in the long run we COULD have different ways of doing things / calling apis / build frameworks / etc... )
Fair enough.. I agree that we'll have to see where this goes, and hopefully a technical effort doesn't get overshadowed by an ideological one.. Because you know this blog post and announcement will draw some strong reactions from entrenched interests.
You cannot always cleanly differentiate these two. You could argue that "Node vs io.js" was an "ideological" split because they wanted different governance, but one big reason they wanted different governance is to make different technical choices (for example, track upstream V8 more closely), so you could also claim this was a "technical" split too.
Re: The Deno Company
#199Earlier quoted context omitted.
Respectfully, your comment is way off topic, and nothing to do with discussing The Deno Company, and what it means for the Deno ecosystem. Not to mention, this is a very worn out, tired complaint that's been talked about ad nauseam. Reading angry swipes at web developers is not very interesting. Ok, you're not a web developer. So you stick to what pays the bills, why would you learn Node or Typescript? Same for web d…
> Respectfully, your comment is way off topic, and nothing to do with discussing The Deno Company, My take from reading the blog post was that the Deno Company's entire thesis is that the developer community will increasingly be moving away from these older abstractions and towards web-based abstractions, and Deno is positioning itself to fuel that migration. GP's comment addresses this directly; it seems rather on-t…
Fair enough. But I don't see it as the community will be moving away from older approaches. The old ways will always be there. I see it as this is a on-ramp for web developers to get into systems programming.
The reality is there is a huge wave of new developers in the last decade who entered into programming through web. I guess the OP sees this a 'threat' to his way of doing things somehow, but I don't think it's a threat at all. Normal to feel that way though.
These tools are meant for web developers, and if you are not one that's okay. There is probably no good reason to make the jump unless you are just curious or bored.
Last sentence of the blog post: "The Deno company hopes to enable the millions of web programmers out there to maximally leverage their craft in other domains."
Re: The Deno Company
#200> Many are more familiar with the Chrome DevTools console than they are with a Unix command-line prompt. More familiar with WebSockets than BSD sockets, MDN than man pages. Bash and Zsh scripts calling into native code will never go away. But JavaScript and TypeScript scripts calling into WebAssembly code will be increasingly common. Many developers, we think, prefer web-first abstraction layers. Every time I read so…
It is time to post this again. The Birth & Death of JavaScript ( 2014 )
https://www.destroyallsoftware.com/talks/the-birth-and-death...