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

Deno Is Webby

blog.jim-nielsen.com

Post reply on HN
Print view View original

101–110 of 215 posts

Re: Deno Is Webby

#101

Post by irrational »

seanp2k2 wrote: post #77
gavinray wrote: post #69

Earlier quoted context omitted.

This has also unfortunately been my experience, even when working with developers that have several years of experience writing JS. There seems to be a big gap in knowledge when it comes to boundaries between the language specification, runtimes, and innate abilities. People consistently confused about why they can't use JSX without a build-step, not understanding that JSX isn't "real", why doesn't fetch() work in No…

speaking of next.js, it's always fun to watch web tech come full circle back to "maybe we should render this stuff before we send the bits, since servers and CDNs are real real good at sending bits real real fast, instead of making everyone render the same static stuff a billion times per day client-side". https://en.wikipedia.org/wiki/Movable_Type was generating static blogs back in 2001, and that's still a great id…

One of my tasks at work is to support a website that was built 20 years ago. We keep talking about updating it to modern web standards. It sounds like, if we wait a little longer, our 20 year old site will be using modern web development techniques already ;-)

Re: Deno Is Webby

#103

Post by seumars »

Deno is a joy to use server-side. Though as soon as it's used in conjunction with even something simple like minified code, you're forced back to node/npm.

Re: Deno Is Webby

#104

Post by nllsh »

russellbeattie wrote: post #16

I'm sorry but all those examples and Deno's documentation in general should be in JavaScript. I respect the devs right to choose which ever language they want, but Deno seems to want to be the standard bearer for the power of scripting and web standards [1]. If that's the case, then they are causing more harm than good by focusing exclusively on TypeScript, which isn't a language as much as a set of macros on top of…

Deno can handle plain JavaScript just fine. In what way is targeting TypeScript harmful? How do you differentiate between a project that can benefit from type safety and one that cannot? Why should Deno's documentation be in JavaScript?

What does is mean to "respect the devs right to choose which ever language they want"?

Re: Deno Is Webby

#105

Post by eyelidlessness »

aidos wrote: post #97
antifa wrote: post #94

Earlier quoted context omitted.

Why as a user should I have to endure a website with an intrusive user of alert? I don't care what happens to websites that use alert, I never want to see my browser get locked up because of lazy devs wanting to use alerts.

That only because the implementation is poor. It doesn’t have to be intrusive.

Sort of. This can obviously be non-blocking and redirected to whatever stdin-ish receiver you prefer:

  alert('whatever');
This cannot:

  const answer = confirm('A querstion?');
  const value = doSomethingWithUserInput(answer);
  return doSomethingWithValue(value);
The API depends on it blocking the main thread, and removing that expectation is effectively just as disruptive as removing the feature entirely: non-abusive usage would have no reason to call this function if not to block for user input. Introducing some magical suspension of the stack like async/await or generators would break assumptions about the entire concurrent execution model of the language (the inverse problem of “colored functions”, infectious async/await etc).

The best thing they can do without removing the API is provide an escape hatch, which most browsers already do when alert &co are called multiple times in quick succession.

Re: Deno Is Webby

#107

Post by nllsh »

seumars wrote: post #103

Deno is a joy to use server-side. Though as soon as it's used in conjunction with even something simple like minified code, you're forced back to node/npm.

How are you using Deno with minified code? Do you mean importing a minified script like https://cdn.jsdelivr.net/npm/react/cjs/react.production.min.... ?

Re: Deno Is Webby

#108

Post by tracker1 »

rr808 wrote: post #51

I love the idea of deno over Node. Is it getting traction though?

I've started using it for more shell scripting... since it's easier to run without worrying about `npm install` for dependencies.

Also using it where I'm not tied to Node by a specific dependency. There's some shimming surface towards getting Deno able to run node packages and vice-versa as well as ES-Module packaging of node repositories for use directly in the browser or deno, to more or less success.

Re: Deno Is Webby

#109

Post by asiachick »

dexwiz wrote: post #4

This is nice, until its not. I have spent a fair amount of time over the last several years trying to make node act like the browser, or vice versa. It's doubly confusing to juniors who don't understand the difference between a language and a runtime. alert() looks like a standard function and should be specified by the ECMAScript Language Specification. But its actually specified by the HTML standard, because its Wi…

Isn't that just basic programmer knowledge. Basic in as "you need to learn the difference between a language and the environment its in". I can run C# in Unity. The number of functions I can call is vastly different than running it outside Unity. I can run Lua in 100s of runtimes, all with different functions available. JavaScript can be used to script Adobe apps. The functions available are different than the browser.

This is just normal. Is it confusing for a new programmer? Maybe. Is it something they should learn to distinguish? Yes!

Re: Deno Is Webby

#110

Post by tracker1 »

jokethrowaway wrote: post #63

I agree on the premises, it's nice to have an open standard - in practice the API available on the web is usually a downgrade in developer experience. Think about the old node library request vs fetch, require vs import/import(). I hope deno has Buffers and I won't have to use atob / btoa.

IIRC Buffer in Node has been a wrapper around Uint8Array for a long while, which is in the box in both, and the browser.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Post reply on HN