81–90 of 100 posts
But, once you are writing code in TS, then transpiling that to JS, then running that in V8 on a server, you have taken a big step into the Rube Goldberg dimension.
and the great migration begins. but when you look at other backend ecosystems e.g php, ruby on rails they're still getting shit done. even though people might say those languages/frameworks might be slow or insecure. stability is what's lacking in the JS ecosystem. glad I do my backends in flask now
... As long as there is enough interest still in Node to maintain it. Hopefully, there is still interest in running the same language as browsers do, without additional dependencies.
Personally, I would prefer Clojurescript to TS, but not strongly enough to want to be tied to its fate.
Earlier quoted context omitted.
The big deal here is security by default as enforced by the runtime (deno) itself - there is afaik none other doing anything remotely as cool anywhere. It in effect makes it super safe to run code since you have to explicitly allow the various levels of system access. Also makes the system fundamentally unattractive to malware authors whereas installing modules via node.js is like leaving your front door open and tak…
> there is afaik none other doing anything remotely as cool anywhere Any operating system with "capabilities", "namespaces", "privileges", etc. That includes Linux, Windows and many others.
Earlier quoted context omitted.
This is puzzling to me because I had the opposite reaction: among other things, Deno solves an incredibly important problem with Node, which is the complicated configuration used with most projects. Deno can perform, out of the box, many of the things you'd need to configure Webpack + Typescript to do: SUBCOMMANDS: bundle Bundle module and dependencies into single file cache Cache the dependencies completions Generat…
None of those are very important. When node appeared, it was a 'huge thing' because you could run JS consistently on the server-side, with some kind of packaging scheme. Most of the things you listed aren't going to be useful to most, even when they are, they are small things that can be managed otherwise. Though admittedly, everyone will runt into at least one of those issues. For a large, complex deployment, there'…
1) You need a secure sandbox for running JavaScript (e.g. You run a SaaS and you want your users to be able to customize something). NodeJS has to be sandboxed at VM level like Python, even although JavaScript was designed for this very purpose.
2) You want a TypeScript first nodejs.
3) You want isomorphic JavaScript between the browser and the server, because node does its own thing (for historical reasons) and deno strives for compatibility where possible.
What it lacks is npm compatibility. That is the JavaScript community for better or worse and without being able to use those libraries it doesn't seem compelling to me.
The one big thing missing is an ORM. And making those things is notoriously difficult. Hopefully something will turn up
The idea that ORMs are a net-positive is definitely an open question. After 20+ years I'm certainly of the opinion they're not. I recently discovered Slonik (only for postgres, hope there is eventually a port for MySQL and others) and I'm a huge fan of the overall approach and the API. This blog post from the creator explains: https://medium.com/@gajus/stop-using-knex-js-and-earn-30-bf4...
I'm really curious about whether people think Deno will succeed. Node certainly has its warts, but I feel like with recent improvements in the JS language and Typescript that Deno doesn't really solve problems people have nowadays. I don't think the decoupling from NPM and the dependency management approach (or lack thereof) is really a thing that most developers want. NPM certainly had a bunch of "dumpster fires" fo…
Deno's extremely simple import semantics and built-in tooling could make it a great environment for a learner. They won't have to be exposed to package management, they can just click a URL in their source code and see the exact source code they just imported.
All the stuff that professional developers can do and might want to do for themselves (setting up testing frameworks, pinning transitive dependency versions) is kind of out of scope for educational use. Unless that education is specifically targeted at "how to do modern JS development within this specific ecosystem".
The ease of bringing TypeScript into your Deno programs may make it easier to start "graduating" to static typing as part of the curriculum, without being like "okay, that was Python! Next up: Java!"
[1]: Say what you want about JavaScript, I don't see that modern JS is significantly worse than Python for learning to program (having watched a couple of students go through Python courses). All languages have their warts.
I'm really curious about whether people think Deno will succeed. Node certainly has its warts, but I feel like with recent improvements in the JS language and Typescript that Deno doesn't really solve problems people have nowadays. I don't think the decoupling from NPM and the dependency management approach (or lack thereof) is really a thing that most developers want. NPM certainly had a bunch of "dumpster fires" fo…
The big deal here is security by default as enforced by the runtime (deno) itself - there is afaik none other doing anything remotely as cool anywhere. It in effect makes it super safe to run code since you have to explicitly allow the various levels of system access. Also makes the system fundamentally unattractive to malware authors whereas installing modules via node.js is like leaving your front door open and tak…
Earlier quoted context omitted.
None of those are very important. When node appeared, it was a 'huge thing' because you could run JS consistently on the server-side, with some kind of packaging scheme. Most of the things you listed aren't going to be useful to most, even when they are, they are small things that can be managed otherwise. Though admittedly, everyone will runt into at least one of those issues. For a large, complex deployment, there'…
There are at least three big obvious reasons. 1) You need a secure sandbox for running JavaScript (e.g. You run a SaaS and you want your users to be able to customize something). NodeJS has to be sandboxed at VM level like Python, even although JavaScript was designed for this very purpose. 2) You want a TypeScript first nodejs. 3) You want isomorphic JavaScript between the browser and the server, because node does i…
Or rather, they might be 'big' for a few teams in specific areas, but they are not 'big market opportunities' not even close.
The ability to go from Java+Spring OR Perl/PHP - and then have the choice to actually do JS on the server is a big deal - and that's why Node.js was a success.
The sandbox is nice but I don't see it being a big opportunity just yet. 'Running your own SaaS with untrusted code' is a developing area, and I'm not sure of Deno actually is a solution (how does one integrate with it). Also - Node.js does have some options there in the form of VM2. The real security hasn't been validated just yet either.
'TS first' - I think is just a toolchain and packaging optimization. We're all going to be running some kind of process for bundling and packing, it requires no effort to transpile in to JS at that point.
The isomorphism again, is a neat feature.
In other words, Deno has some cool new features in the context of 'the market/users space' for server side JS, whereas Node.js actually founded and created that entire market category.
Under normal circumstances, I wouldn't bet on any movement towards Deno, just because there are too many legacy Node.js already there, but since there seems to be a strong fanboy following, I don't doubt a lot of young devs push for it to be used because it's cool and shiny. All 'shiny new toys' have some benefits here and there, it's just a matter of contextualizing them into the incumbent landscape.
Earlier quoted context omitted.
I disagree. I've used many ORMs in my ~20 years, and I've architected and designed several hugely complex systems under non-trivial load. There are really two things I want to put out there: 1) My opinion is that about 90% of your standard, day-to-day queries work just fine in a good ORM. The developer _should_ know enough about the DB schema and SQL to handle the other 10%. (In our 10 y/o enterprise software, the on…
I skimmed the Eloquent docs[0] but I couldn't see anything that sets it apart from other ORMs. What makes it special? [0]: https://laravel.com/docs/7.x/eloquent
In particular, I think relations are great to work with in Eloquent.
I'm really curious about whether people think Deno will succeed. Node certainly has its warts, but I feel like with recent improvements in the JS language and Typescript that Deno doesn't really solve problems people have nowadays. I don't think the decoupling from NPM and the dependency management approach (or lack thereof) is really a thing that most developers want. NPM certainly had a bunch of "dumpster fires" fo…
This is puzzling to me because I had the opposite reaction: among other things, Deno solves an incredibly important problem with Node, which is the complicated configuration used with most projects. Deno can perform, out of the box, many of the things you'd need to configure Webpack + Typescript to do: SUBCOMMANDS: bundle Bundle module and dependencies into single file cache Cache the dependencies completions Generat…