Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Deno Company

deno.com

Post reply on HN
Print view View original

151–160 of 446 posts

Re: The Deno Company

#151

Post by joshmanders »

hinkley wrote: post #101
int_19h wrote: post #91

Earlier quoted context omitted.

Speaking for myself, I have already learned JavaScript - I just don't want to have to use it.

What I learned about myself working as a NodeJS developer: I’m okay writing JavaScript as long as I don’t have to spend all day every day writing it.

This is an interesting thing to think about.

I was primarily a PHP backend dev for 15 years who only used jQuery to toggle classes on click actions, but decided to try something new and switched to Node in 2015.

Node + ECMAScript 2015 just BLEW my mind and was so fun, that not only am I now primarily a Node dev, but I've excelled extensively in the frontend.

I've never enjoyed building websites or web apps as much as I have in the last 5 years.

Re: The Deno Company

#152

Post by dgellow »

threatofrain wrote: post #139
dgellow wrote: post #107

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.

You're talking about control of the hardware/filesystem/etc, I'm talking about control of the application itself.

Re: The Deno Company

#153

Post by sbarre »

Freknf wrote: post #137
xiaq wrote: post #47

Earlier quoted context omitted.

Sounds to me that they will build some sort of hosted service or maybe PaaS based on the Deno runtime (like AppEngine or AWS lambda), but yeah it's pretty vague.

In other words, capitalise on the decreasing quality of software engineers by offering services to them at a high price because they don't have the ability to make any of these services themselves.

This is a rather naive take I think..

There's a semi-joke that goes "all companies are software companies now" but there is a lot of truth to that..

It comes to down where a company wants to put its effort.

Do you want to own/operate/maintain all your infrastructure and services (and all the challenges that come with retaining scarce talent that is capable of that work), requiring you to substantially invest in an area that is not core to your business?

Or do you want to spend that money (and let's be real, less money too) to pay a trusted third party provider who will do a better job than you would anyways, because that's their area of expertise?

Then you can focus your (likely limited) resources on delivering value to your business instead.

Re: The Deno Company

#154

Post by ianwalter »

prussian wrote: post #77
beaconstudios wrote: post #33

Earlier quoted context omitted.

Node is only just now getting around to adding promise based APIs to the core. Any time you interact with the Node core APIs you have to drop back to using callbacks - that's at least one area where Node is behind the times.

util.promisify() seems to work for many of the node stuff I use a lot, like pipeline(), readFile(), etc. Perhaps require('xyz/promises') is a newer development.

Why util.promisify `readFile` when `fs` exports promises?

Re: The Deno Company

#155

Post by ivan888 »

40four wrote: post #128
celeritascelery wrote: post #85

> 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…

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

Re: The Deno Company

#156

Post by sublimefire »

tomxor wrote: post #106
sublimefire wrote: post #81

Deno makes sense in a variety of situations. The build pipelines of Typescript are excessively complicated and Deno hides that complication away (less dev effort). Furthermore Node has its own maintenance/risk issues in production systems (think permissions), and Deno reduces those with custom built runtimes. I cannot see it replacing Node though. Node has created a vast ecosystem that includes modules (npmjs), clien…

This probably either sounds nuts or over opinionated but I don't think the NPM ecosystem is as valuable as people think it is... stuff is deprecated continuously anyway - when you find a way to move away from 10k dependencies (because your shortsighted previous self decided to depend on a single package without looking closer), it's a damn relief. I hate how needlessly complicated the NPM ecosystem is, I would actual…

Your thoughts and experience resonate with me.

Although I would look for similar examples elsewhere to understand where it is all headed. And one of those could be the rise and adoption of the JVM. There are a bunch of old dependencies, multiple repositories (compared to just one popular npmjs), a couple of build tools (ant, maven, gradle) compared to npm, yarn, then multiple languages (invented for somewhat similar reasons as Typescript). One thing is sure that the dependencies stay somewhere for-almost-ever, and all else kind of evolves around it.

It seems that the main problem at the moment is the developer (me, you, everyone) who instead of writing 20 lines of code uses a dependency that has 10 other transient ones. You cannot fix it but rather challenge those situations at work and reduce the tech debt for good. Maybe there should be a build tool that throws errors depending on the amount of dependencies. Maybe there should be a frontend framework which will only need 10 dependencies for the helloworld instead of 1500; otherwise we kind of think that if a boilerplate template has 1500 deps then surely adding another 100 will not make much harm.

Re: The Deno Company

#157

Post by breck »

munro wrote: post #95

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…

There are a number of newer projects in this area. Arquero from Heer's Group (https://observablehq.com/collection/@uwdata/arquero), TensorFlowJs (https://github.com/tensorflow/tfjs), and (biased) CoreTable from OurWorldInData (https://github.com/owid/owid-grapher/tree/next/coreTable).

Re: The Deno Company

#158

Post by breck »

appleflaxen wrote: post #66

Deno is licensed as MIT. Awesome! But how will they prevent from being freeloaded? My sense is that GPL3 gets a ton of criticism on HN, but isn't it the perfect defense against freeloaders? * license the code for proprietary use in your stack * use GPL3 if you have a non-commercial use, and are willing to accept the requirement to open source your own code. I don't understand why this option isn't used more by open s…

The best IMO is to go public domain. SQLite is a great example: (https://sqlite.org/copyright.html).

Re: The Deno Company

#159

Post by murukesh_s »

oblio wrote: post #89
sublimefire wrote: post #81

Deno makes sense in a variety of situations. The build pipelines of Typescript are excessively complicated and Deno hides that complication away (less dev effort). Furthermore Node has its own maintenance/risk issues in production systems (think permissions), and Deno reduces those with custom built runtimes. I cannot see it replacing Node though. Node has created a vast ecosystem that includes modules (npmjs), clien…

I think raw (framework-less), modern (no J2EE, Spring) Java is most likely a much better language than raw, modern Javascript. Plus, aren't Deno libs compatible with Node libs?

Better language or not Java is reigning king in enterprise companies. We have built our platform on top of Node.js assuming it would gain popularity but Node.js is nowhere near production use in large enterprises. Somehow the enterprise adoption has been miniscule. JVM performance is top notch. Many features like distributed transactions, messaging support, official libraries for enterprise applications like SAP is severely lacking in Node.js and hindering its adoption in enterprises.

Re: The Deno Company

#160

Post by nrmitchi »

cphoover wrote: post #131
TechBro8615 wrote: post #76

Earlier quoted context omitted.

Ryan Dahl (author of the announcement post) is the creator of Node.js, so I think he's got a right to say these things! Also see "10 things I regret about Node" [0] [0] https://www.youtube.com/watch?v=M3BM9TB-8yA

Ryan Dahl left the leadership of the Node.js pretty early in its development. A lot of people can be considered "the creator" of Node.js to be fair.

While I'm not going to argue the history of if/when he left the project, my understanding is that it's fairly agreed upon that he is the creator of Node.js. If you google "node js creator", he's an embedded answer (not a search result).

The first line on Wikipedia in the nodejs history section is "Node.js was written initially by Ryan Dahl in 2009".

You can make whatever point you want, but maybe try to do it without rewriting history, or changing the agreed-upon definition of "creator".

Post reply on HN