141–150 of 446 posts
Trying to sell something based on FUD is always a bad sign.
> 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 think you'd be surprised how many modern applications are written in JavaScript or Python.
One of the more prominent ones is VSCode.
Earlier quoted context omitted.
"it must remain permissively free." ... until the VCs change their mind or AWS uses our code to make more money than we do.
I just don't understand this. This project uses distributed version control. This implies 2 things 1. It is impossible to delete every copy of this project. If the authors wanted to restrict access by taking the repo private, they can't. It will always be out there. 2. Every commit is licensed with MIT. So even if there is a licensing change, you have access to every commit licensed by MIT. You've lost nothing except…
Yes.
And if it isn't you need to switch.
If you are tied in in a way to proprietary tools or APIs then you have some major migration in front of you. If you don't you you might be able to use Node.
If you have a tight schedule already, or no development capacity for the migration, you will need to buy a license because you might not want to run your code on a plattform that no longer gets security updates and you no longer get support.
When this happend to me in the past, I've got some major bills for licenses b/c most of them are server based (or core based) and also count development, testing, staging and CI servers (>$100k/y).
"You only need to be concerned if you're heavily invested on their platform and it's not popular enough for community support and you need new features added. In this unlikely scenario, [...]"
s/unlikely/likely/g
I have no data but would assume this is the default ending, because most projects are not being forked (Mongo, ...) and create a successful community around a fork and most companies I work with are heavily invested in a plattform and do not adhere to the standard APIs and tools (e.g. I'd say 10% of my customers use AWS in a standard way, 90% are heavily invested in the plattform, same for GCP.) If you have other numbers and/or studies, I would be interested.
> 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…
The web is eating the world because it's the easiest way to ship an application. It has nothing to do with whether developers like to do it or not.
Deno are in overlapy
|
|
| /---
/--- -- | /- \---
/--- \-- | /- Best |
| Coders \|- coders \
/ passionate /-|\-- in |
| about - \- world \
\ democratization - |
| of -\ -
\ technology -/ -\ -/
|---\ -/ -\ -/
---- -\ -/
--
Earlier quoted context omitted.
With WebAssembly, now you don’t have to. You do need a JS shim to load the WebAssembly, but after that, pick your favorite source language that can target wasm.
For web programming, WebAssembly is still not enough. It solves the problem of how to run your non-web based code in a browser, but until it can interoperate with the DOM, JS will continue to be mandatory.
For example, see the wasm-bindgen and the generated web-APIs in web-sys: https://docs.rs/web-sys/0.3.49/web_sys/
A nice framework that takes advantage of this is yew: https://yew.rs/docs/en/
I know this sounds crazy on the surface level, but I really wish I could do data engineering and machine learning with TypeScript instead of Python. TypeScript's type system is so good, it makes refactoring large projects so easy. Python's typing module leaves a lot to be desired, and on top of that PyCharm doesn't properly support everything. Perhaps I should switch to VSCode--but I do like IntelliJ, and it works re…
Earlier quoted context omitted.
This is probably a stupid question, but is AGPL/commercial dual-licensing a viable option for something like this? Instead of relying on goodwill donations & maybe assigning 1-2 devs from major corporations, just explicitly charge them money if they refuse to ship source code to end-users.
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.
Earlier quoted context omitted.
Yeah, no kidding.. shots fired... As someone who uses Node but doesn't closely follow the steering/proposals side of things, I can't say I had this impression of that process.. Is Node really that bad compared to how JS/ES is innovated on in the browser?
That's very subjective As an outsider who likes to lurk, I have the impression both ECMA and Node committees are stuck in the "we're nice and therefore right" field. They made technological choices that broke the platform (eg. require vs import). It took ages of pain to innovate on things that matter (eg. promises, async) I wish Deno the best, but I'll just try to stay away from JS from now on (same as I've been avoi…
https://guides.rubyonrails.org/v4.2/command_line.html#custom... https://docs.djangoproject.com/en/3.1/howto/custom-managemen...
I guess though, the people in the Ruby / Django community are actually building projects and the node community are padding their resume with new npm packages.
I hope deno or dart can make the JS world better, but I suspect they will both end up just making it more fragmented. One thing I really like on flutter / dart is they do try to rate / otherwise rank / categorize support of their packages aside from stars https://pub.dev/packages?sort=popularity / downloads which are easy to manipulate. IMO deno should do this as well or let someone willing to takeover as the primary package manager https://deno.land/x/lodash@4.17.19
Nice to see! How do they plan to monetize? I either became blind or missed it somehow. The article does say how they DON'T plan on monetize: "Rest assured that Deno will remain MIT licensed. For Deno to grow and be maximally useful, it must remain permissively free. We don’t believe the “open core” business model is right for a programming platform like Deno." There are some hints though: "If you watch our conference…
This is probably a stupid question, but is AGPL/commercial dual-licensing a viable option for something like this? Instead of relying on goodwill donations & maybe assigning 1-2 devs from major corporations, just explicitly charge them money if they refuse to ship source code to end-users.
One of the funniest/best business models out there is SQlite (https://sqlite.org/copyright.html). They give it away to the public domain, but some lawyers wrongly claim that that is not enough, so they will "sell" you a warranty asserting it is all public domain.
Earlier quoted context omitted.
And because web app publishers have full control. If I have a web application, I can update it right now and it will be updated for ALL my users at the same time. No store policies bullshit, no need to somehow notify users that a new version has to be downloaded and installed, no fragmentation of your user base because half of your customers stay at an old version due to whatever reasons out of your reach.
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.
Web apps are also a hell of a lot easier to secure these days (as long as you trust / validate the platform’s security, which should be in the contract anyway). Which is also why a lot of “native” apps are pretty much web apps with some wrappers around platform-native hardware integration.