There are many, many companies competing with AWS on products that strictly speaking AWS also has. I mean Zoom has no right to exist because you can use Chime? There is always room for better UX, better support, different approach etc.
I find the idea that AWS will just eat the competition always a little silly as well. I've used AWS managed offerings that were far inferior to the alternatives.
And yet we've never seen anyone beat Amazon yet. Look at how much the PaaS area has churned over the last 10 years. Giants that stuck around like Docker are completely deflated and near worthless compared to their initial values and expectations. The smart ones like Heroku got out when the getting was good.
There are many, many companies competing with AWS on products that strictly speaking AWS also has. I mean Zoom has no right to exist because you can use Chime? There is always room for better UX, better support, different approach etc.
I find the idea that AWS will just eat the competition always a little silly as well. I've used AWS managed offerings that were far inferior to the alternatives.
So why were you using the AWS managed offering then instead of the alternative?
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…
yeah the dream of being able to share at the very least data types client and server side is pretty elusive. Most projects you could probably build twice before you could get client and server side sharing much code. Also just shocking me to me how averse the whole nodejs community is to shell commands like https://guides.rubyonrails.org/v4.2/command_line.html#custom... https://docs.djangoproject.com/en/3.1/howto/cus…
The NodeJS community isn't averse to shell commands as you described; far from it I'd say. But a main differentiating factor between the Node and Python community is that Node folks like to compose things from lower level functionality a bit more, and are much more into functional paradigms and patterns. It helps that in Node, everything has essentially consolidated to using Express and Connect-style middleware, so interop between frameworks and libraries is high, and it's easy to go from a lower level basic framework to one that has batteries included (to put it in Python analogies: going from NodeJS "Flask" to NodeJS "Django" is easy because in Node "Django" runs on top of "Flask" and has support for the same middleware pattern, so all "Flask" middleware works fine if you switch to "Django"). The higher level batteries included frameworks almost always ship with their own CLI and tooling that closely matches what you'd find in something like Django; take a look at Nest.js for an example of such a framework.
Looks like https://deno.com/deploy will be a managed service - the implication seems to be that the default option will be to use their CDN to run code with an option to DIY if you prefer.
How does this business model survive Amazon AWS making a blog post, "Here's a template to run your deno code on Lambda!"? They'll never beat AWS on costs in the long term. They can burn VC cash to stay afloat and try I guess.
I find the idea that AWS will just eat the competition always a little silly as well. I've used AWS managed offerings that were far inferior to the alternatives.
And yet we've never seen anyone beat Amazon yet. Look at how much the PaaS area has churned over the last 10 years. Giants that stuck around like Docker are completely deflated and near worthless compared to their initial values and expectations. The smart ones like Heroku got out when the getting was good.
> And yet we've never seen anyone beat Amazon yet.
That largely depends on your definitions of "beat" and "win". There are plenty of software infrastructure firms out there that Amazon has yet to smash into the ground.
Nature seems to think (and I agree) simply existing is winning.
No. Nothing has changed about Typescript support since 1.0. It is just as well supported as JS. We never removed support...
So Deno is still committing to TS runtime?
I feel like people are talking past each other here.
To me "TypeScript runtime" means running TypeScript in a mode that runs faster than JavaScript by actually using the type info to generate better machine code. It does not mean translating to JavaScript at runtime and running in V8.
For example at one time there was an experimental version of Chrome that had a Dart Runtime. A quick google finds this HN thread when they decided NOT to have a dart runtime
So can we get clear? Does Deno plan to execute TypeScript natively (not via V8 or via a heavily modified V8) or are the plans to continue compiling TypeScript to JavaScript internally and actually just run JavaScript
The 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 i…
Hard pass. There are globs of features and design changes that make it worth the switch immediately if your use context can allow for it. I've now done a handful of apps and libraries in it, and given the option, I'd never look back to node. I don't say that lately. Node's was the best. These new designs are more than marginally overcoming the shortcomings of node. The motivation for migration is strong, and if best proven through experimenting. If you are TS saavy, do yourself a favor and try it out.
> Extending web programming beyond the browser is not a novel idea. Indeed, we have done that with moderate success in our “Node.js” project. But over a decade later, 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.…
Right behind the giant understatement of calling Node a “modest success.”
> To provide a modern, productive programming system that adheres to browser APIs. In my opinion, the best part of node is (or was) that it didn't adhere to the browser APIs. That brought in some fresh air, and gave us buffers, native bindings, streams etc.
Web does have streams and buffers. Web assembly seems to fill in the gaps for native code but deno supports rust plugins which removes any sandbox guarantees so it's a trade off.