[HN Gopher] Deno 1.35: A fast and convenient way to build web se...
___________________________________________________________________
Deno 1.35: A fast and convenient way to build web servers
Author : mikece
Score : 175 points
Date : 2023-07-05 13:06 UTC (9 hours ago)
(HTM) web link (deno.com)
(TXT) w3m dump (deno.com)
| tharos47 wrote:
| Just in case someone at deno is monitoring HN comments there is a
| typo in the third link resulting in a 404 :
| https://deno.com/manualruntime/web_platform_apis should probably
| be https://deno.com/manual/runtime/web_platform_apis
| vbezhenar wrote:
| Can someone enlighten me about one thing.
|
| I kind of like deno when it came to its package management. I
| hate npm and I liked that deno tried to disrupt ecosystem.
|
| Now when deno bent over and accepted npm reality, is it possible
| that few years later they'll just switch over to it entirely and
| abandon their old ways of packaging?
|
| I understand that it's easier to sell deno to developers when
| they can import npm package. And deno wants to make money, so
| taking a hard stance is a bad financial option in the short term.
|
| Still I'd love to take a bet on deno. But if deno is just another
| npm... Well, setting up node + typescript + eslint + prettier
| sucks, but not so much.
| rs_rs_rs_rs_rs wrote:
| Anyone knows if something similar to `deno compile` is planned
| for node in the future?
| okhuman wrote:
| Nodejs support for "single executable applications" is getting
| there - this issue below is preventing wider adoption at the
| moment:
|
| "The single executable application feature currently only
| supports running a single embedded script using the CommonJS
| module system."
|
| https://nodejs.org/api/single-executable-applications.html
|
| Should be an awesome game changer for node.js when the feature
| gets rounded out.
|
| Also check out vercel's `pkg`:
| https://github.com/vercel/pkg/issues/1291
| ushakov wrote:
| I'm wondering how you implement Deno.serve on Deno Deploy?
|
| With CF Workers and Lambda you have to export a function
| mmastrac wrote:
| The same code works in both places - the deploy architecture
| seamlessly integrates Deno.serve with the deploy architecture
| that lives in front so it "just works".
| lemper wrote:
| good thing I am not in position of power to choose the stack in
| my company. if I were, I don't think I'd pick deno over plain old
| docker container somewhere in someone else's computer. on docker,
| at the very least I know how to move my project somewhere else in
| case the data center is on fire.
| qbasic_forever wrote:
| Why wouldn't that be the case with deno too? Just move the deno
| executable, that's all you need to run it (and your code
| obviously) You can even just build and use a deno-based docker
| image like node or any other language image.
| triyambakam wrote:
| Deno and Docker are orthogonal
| benatkin wrote:
| It's referring to the permissions system which sort of
| resembles container isolation. Only a bit, though. Something
| that resembles it a lot more is WebAssembly. There's a plugin
| system that has been shared by its creators around here a
| couple times: https://github.com/extism/extism
| galaxyLogic wrote:
| Can Deno output WebAssembly?
| ushakov wrote:
| JIT is not possible in WASM. So, the answer is no
| AtNightWeCode wrote:
| Like over a year ago Deno raised $21M in investments and this is
| the current state...
| okhuman wrote:
| A general hypothesis I have is that the Deno team is just
| taking on too much to make the investment work in terms of,
| well everything really: version compatibility to reduce
| breaking 3rd party libs, one-by-one certification of npm module
| compatibility, deno core module re-writes, a hosting company,
| maintaining developer tooling/ecosystem - to name a few.
| datadeft wrote:
| I am not sure if either fast or convenient applies here. Maybe I
| have different definitions.
| kamranjon wrote:
| I think they mention fast because the built-in Deno webserver
| is now faster than node:http. I've been following Deno for a
| while, and even deployed a service with it, and it's awesome
| that it has finally surpassed node performance.
|
| I think if you've used Deno before convenient definitely fits,
| you can build quite a bit without needing external libraries,
| typescript by default, you kinda just start working on your
| problem - just a much cleaner version of what node could have
| been in my experience.
| porsager wrote:
| Just use uWebSockets.js[1] in node, and you'll leave Deno in
| the dust again. (uws is also what's under the hood in bun)
|
| https://github.com/uNetworking/uWebSockets.js
| mmastrac wrote:
| The fastwebsockets library one of our team developed gives
| uWebSockets a run for its money under a lot of
| circumstances (though we trade performance improvements and
| the top spot back and forth).
|
| We're constantly working on improving the performance of
| Deno from top to bottom and it's a marathon.
|
| We don't want to be fastest at the expense of security or
| maintainability and the results from the last couple of
| months have been pretty awesome.
|
| I can't necessarily speak for priorities at any point in
| time, but I can say that performance is very important and
| literally what I'm working on most of the time.
| andrewstuart wrote:
| I tried to switch my nodejs project to deno and discovered it
| "just doesn't work that way".
|
| Deno is not a drop in replacement for nodejs, which is a pity.
| mkeedlinger wrote:
| I don't think so. I don't want another nodejs. If I'm getting
| the same tradeoffs as nodejs, why not just use that?
|
| I like Deno specifically because of how different it is from
| node.
| bartlomieju wrote:
| Bartek from the Deno team here. Sorry to hear that - we made
| great progress in making Deno drop-in replacement this year,
| but we certainly are not yet there 100%.
|
| I'd love to hear what problems did you hit and look into
| solving them.
| andrewstuart wrote:
| I don't recall but it felt like a distant goal at best.
|
| Is there a written guide for how to convert a nodejs project
| to Deno?
|
| I'd really prefer to be using deno instead of node. If it was
| a seamless experience I would definitely drop nodejs.
| bartlomieju wrote:
| A couple months back we added an ability for Deno to run
| projects authored for Node.js directly.
|
| Eg. if you have a Vite app (or any other app really) with
| "package.json" and some "scripts" defined there, just try
| running "deno task <script_name>". Deno will automatically
| pick up "package.json" and try its best to run the that
| script.
|
| It's not fully done, but in our testing we got a lot of
| non-trivial projects running that way. If something doesn't
| work in your case, I would greatly appreciate a bug report
| to help us fix this.
|
| As for the written guide - there's not a single one at the
| moment - it's something we'll be looking into in the coming
| months.
| andrewstuart wrote:
| I'll wait till there's a written guide then follow it.
| danpalmer wrote:
| The thing I don't quite get yet about Deno (and maybe some other
| similar things), is that do so much that they need to be perfect
| to be worth using.
|
| Deno is effectively a language and runtime, webserver, package
| ecosystem, and arguably infrastructure and database. When
| choosing the technology to use for something that feels like a
| lot of eggs to put in one basket. Sure there are benefits to
| bundling like this, but the downside is that you're more exposed
| to bits of that bundle being insufficient.
|
| Maybe this criticism doesn't play out in practice, but Deno and
| some other things trying to re-invent Javascript again, seem to
| be trying to do too much at once, and are risking ending up too
| far away from the original ecosystem to be able to return. Now
| maybe the only way to re-invent JS in a convincing way is to do
| these wholesale rewrites making big divergences, but then again,
| perhaps that just indicates that JS is not the foundation that it
| needs to be for some kinds of development.
|
| Note, I've said JS as a grouping of the JS/TS ecosystem and
| existing packages. I don't think TS changes things that much as
| it's still the same ecosystem of tooling for the most part.
| user6723 wrote:
| Deno was created by the guy who created NodeJS, so it might be
| good for JS projects.
| brundolf wrote:
| > a language and runtime, webserver, package ecosystem, and
| arguably infrastructure and database
|
| Some gentle pushbacks:
|
| Runtime and webserver yes (though not web _framework_ ),
| language sorta, though Node is already just as much all of
| these things
|
| Package ecosystem also sorta. Any Deno module that doesn't use
| the Deno APIs is isomorphically runnable in the browser and
| most other JS contexts. This is actually more true than with
| Node, because idiomatic Node code uses CommonJS imports which
| are incompatible with the browser without transpilation
|
| Infrastructure I don't think is really true; obviously there's
| Deno Deploy, but I don't use that for any of my Deno projects.
| If anything, the fact that it's so self-contained makes it more
| flexible to different kinds of infrastructure. All you need
| installed is the runtime, and then you run a single command and
| you're off to the races (with dependencies downloaded
| automatically as needed)
|
| I think it strikes a great balance between batteries-included
| and compatibility. It's become my favorite default way to write
| a CLI or a web server
| steve_adams_86 wrote:
| I had similar hang ups about deno but my experience aligns
| with what you're saying. I hit far fewer snags than I thought
| I would (none I suppose), and the tooling off the shelf was
| excellent. I was off and running within 30m or so.
|
| I got a little confused about importing packages properly but
| it might be down to how my IDE handles stuff and not really
| deno-specific.
|
| I also love it for CLI work. I was using Go pretty much
| exclusively for years, but I've used Deno twice for real work
| and a bit for experimentation. Go offers some features I
| prefer, but Deno offers TypeScript which -- for better or
| worse -- is where I think best in code. I like to maintain it
| more, which means a lot for something I have to deal with
| next year.
| j1elo wrote:
| Wait, Node or Deno for CLI tools? I was reading this and
| thinking "Go would make a much better tool for that job",
| so after seeing that you have actually used it in the past,
| I cannot but ask about some more info or comments your
| might have about it.
|
| A language that is designed from the ground up to compile
| into standalone binaries seems so much more apt for CLI
| tools... Deno/Node, on the other side of the spectrum,
| requires a whole environment and runtime, which seems like
| a hassle. I know of vercel/pkg but that's not a first-class
| citizen of the ecosystem and has its shortcomings.
| brundolf wrote:
| The other commenter mentioned `deno compile`, but also,
| if you're in a situation where you can assume everyone
| has the deno runtime installed (maybe it's a personal
| script, or it's org-internal or something) then you don't
| really even need to do that, because the runtime is the
| only piece of environment you need. The dependency
| management is self-contained and the runtime is
| backwards-compatible; scripts should generally "just
| work"
| j1elo wrote:
| I was assuming a more general case where concerns like
| distribution of the tool are something to think about. Of
| course if it's just a personal thing, it doesn't matter
| much, I just wasn't counting on such a small use case.
| steve_adams_86 wrote:
| You're not wrong -- Go is awesome at this, and on paper
| it's generally a better tool for the job. I had to write
| a CLI tool that did a ton of concurrent fetching and
| processing with interactive retries, pausing, and other
| nasty UX stuff that would have been misery in TypeScript
| compared to Go, but I had it working well inside of a
| week. I don't think the same would be true of something
| I'd make with Deno, or at least not with the same
| performance.
|
| Yet I can model solutions better in TypeScript, I work
| faster _most_ of the time, I find the people I work with
| tend to understand complex TypeScript projects far more
| readily than complex Go projects, and some tooling
| (certainly not all) can be nicer in TypeScript land.
| There are definitely trade-offs. There are some go-to
| packages I love to use and fit my habits extremely well
| in that ecosystem though, so that 's a welcome benefit
| for me personally.
|
| If I had to build something very fast, reliable, more
| readily portable, and well-suited to Go's strengths, I
| wouldn't hesitate to use it. For something smaller or far
| nicer to model with TypeScript's type system, or with a
| team that isn't up to speed with Go, I'll seriously
| consider Deno without feeling like it's a major
| compromise.
| JimDabell wrote:
| You can run `deno compile` to build a standalone binary.
|
| https://deno.land/manual/tools/compiler
| j1elo wrote:
| Very interesting, I just learned that Deno has direct
| support for doing this! Very useful, indeed. Thanks for
| mentioning it.
|
| Have you used it, to know what is the baseline size of
| the file it generates? e.g. the size of a "hello-world"
| command, which would be basically 99.9% composed of the
| runtime and core libraries.
| acdibble wrote:
| It'll bundle the entire V8 engine. You can expect
| probably close to 80mb for a hello world app.
| JimDabell wrote:
| I'm not sure about the size of a Hello World but a very
| small command-line tool I wrote is about 90MB, where the
| only substantial dependency is commander.js from NPM. I
| expect the vast majority of that is a constant size added
| to all binaries.
| jitl wrote:
| The status quo comes from tools that do just one thing or that
| compose a lot of other tools. And I don't think too many people
| are excited about the status quo.
|
| Deno's pitch to me is to take everything that makes Golang work
| so well, and apply it to JS/Typescript. I can't switch yet but
| I sure would like to!
| IshKebab wrote:
| Decades of experience has taught us that when you _don 't_
| integrate the language, runtime, packaging and infrastructure
| properly you get a total mess, like Python or C++.
| G4BB3R wrote:
| They are doing too much at once, but I think it's possible,
| since they are a company, and last year raised $21M.
|
| https://deno.com/blog/series-a
| sondr3 wrote:
| I like Deno for many of the same reasons I like Rust and Go,
| the tooling comes bundled with the runtime. No fussing about
| with ESLint/prettier/tsconfig/bundling and all that jazz, Deno
| includes it all. The dependency story was a little rough for a
| while but with import maps now it's really quite nice. With the
| npm ecosystem integrations it's starting to be a very nice
| developer experience.
| danpalmer wrote:
| I guess this is part of my criticism. It's nice to have all
| that stuff bundled, but it's banking a lot on the decisions
| being the right ones for your project. When it's just the
| language, linter, formatter, that might be fine. Adding the
| package manager is often ok as well, but even Rust/Cargo
| aren't fully coupled. But then adding a package ecosystem
| (that isn't fully compatible), a server, infrastructure,
| database.... it's a lot of decisions that all need to be good
| enough.
| ravenstine wrote:
| No one's forcing anyone to use those things, though. I
| think the benefit of having those wrapped into Deno is that
| they'll presumably be performance optimized, but it's just
| as easy to use JS instead of TS, use ESLint instead of
| `deno lint`, Prettier instead of `deno fmt`, or whatever.
| Those are kind of evergreen toolchain concepts that I think
| benefit from being standard to Deno, even if their
| implementations are minimalistic.
| pjmlp wrote:
| I think similarly, note my usual comments about guest
| languages.
|
| Typescript gets the pass, because it basically a JavaScript
| linter, with an easier way to get modern JavaScript features,
| without wrestling with babel and friends.
|
| Projects dictate language toolchains, not the other way around,
| and so far I haven't seen any project or product SDK placing
| Deno on the tooling requirements.
| skybrian wrote:
| Maybe this doesn't count, but Deno Deploy dictates Deno. I'm
| finding it pretty nice so far.
|
| It will be more compelling when the FoundationDB-based KV
| store is finished. At that point there will be enough to
| write full web apps without any external API's, so I can use
| it to build the simple hobby websites that I used to use
| AppEngine for. (For now I'm trying it out using Neon for
| Postgres.)
|
| It's still for developers rather than nontechnical users, but
| this may be simple enough to deal with that it does some of
| what Sandstorm promised to do for things like blogging. Or
| maybe a personal Fediverse server?
|
| It would be nice to have a second source for Deno-based
| hosting, but in a pinch I could put Deno and my apps in a
| Docker container and run it anywhere, though probably not for
| free.
| ravenstine wrote:
| I use Deno for all my personal projects. It's not perfect, but
| the fact that it's so much closer to working in a browser
| environment really helps a lot in terms of mental modeling.
| Lately, I've had no reason to revert to using Node given the
| current level of support for NPM packages.
| vbezhenar wrote:
| Also there's one feature that deno could make possible given
| their tight integration:
|
| Allow JSON.parse to use typescript types.
|
| So I can parse JSON with supplied type and engine would validate
| JSON against that type. Simple as that.
|
| Also might be useful for JSON.serialize to have an output control
| (because TypeScript could be abused and actual value might differ
| from its type).
|
| This simple feature would bring tremendous value to application
| stability IMO.
| emadda wrote:
| I have been using zod to create validation functions. The
| validation functions give the TS compiler hints about the types
| that are output after validation.
|
| I think you either:
|
| (1) start with the runtime code and derive the types (what TS
| does by default).
|
| or (2) start with the types and derive the runtime code (like
| "macros" in some languages).
|
| Does anyone have any suggestions for the best way to do this in
| a Node runtime?
| joshstrange wrote:
| I'm not using Deno yet (I'm about as bleeding edge I want to be
| with my serverless services built on TS) but I love these updates
| and look forward to the day that I feel like I can start to use
| it.
| benatkin wrote:
| I used to think the sandboxing feature was going to be a really
| big deal but I don't any more. I think WASM is eating their lunch
| in sandboxing. I'm keeping a close eye on Fermyon and Dapr.
| pjmlp wrote:
| WASM is just application servers being talked by those that
| didn't lived through Java and .NET application servers.
|
| Now served with tons of YAML configuration files instead of
| XML, and being told to configure our own Kubernetes
| infrastructure on top of it.
| qbasic_forever wrote:
| Deno runs WASM code just fine and IMHO will probably be the
| pre-eminent way to use server side WASM (because you likely
| also need some JS/TS bootstrapping or glue code too for setting
| up a basic API or other endpoints):
| https://deno.land/manual@v1.10.0/getting_started/webassembly
| benatkin wrote:
| If you're writing your server side code in JavaScript, yeah.
| I don't think it will be pre-eminent. I think it could be
| popular but much less popular than Node.
|
| There are server side WASM runtimes for other languages,
| though. Including ones that let you write endpoints entirely
| with WASM (and its languages like Rust and Go*), like Fermyon
| and Dapr.
|
| * https://github.com/appcypher/awesome-wasm-langs
| jamal-kumar wrote:
| With all the hype around server-side webasm I decided recently
| I'd try to implement a project in this. Cool but just in case
| anyone else figures the same just keep in mind that webasm is
| still 32-bit and as such if you need more than 4GB ram in
| whatever you're doing, well, that's your ceiling for now until
| they figure that out come next year or so.
|
| The Deno ecosystem itself needs some work for sure. I think alot
| of other comments already said everything better regarding that
| but it's still nice to know that we have something to write
| typescript in that doesn't just target nodejs.
| bilekas wrote:
| The axios redis And pupeteer support added is actually really
| important and only mentioned as a side note really. Super cool
| work going in.
|
| I'm new to the deno world but will be testing it out this week.
|
| I'm curious though the decision not to have a dedicated package
| manager on the first place? Maybe someone knows the reasons for
| this?
| lloydatkinson wrote:
| What do you need axios for compared to fetch?
| bilekas wrote:
| Nothing that I can think of but that's not the point, the
| transition is easier without having to rewrite in deno native
| as i understand.
| chromakode wrote:
| I trialed Deno for an HTTP+WS side project [1] and have been
| loving it. The simplicity of having Typescript built-in, the nice
| async APIs, and the sandbox permission system all make it a great
| choice for green field projects. I don't mind the url-based
| dependency system as much as I thought I would; with the language
| server DX it's easy enough to maintain.
|
| Deno feels like Node from 10 years ago, in both good and bad
| ways: every Deno native community library I've pulled in (redis,
| S3) has had significant bugs. Fixing them has been fun but
| distracting. Looking under the covers, I've found the code to be
| really clean as a result of Deno's abstractions. The improving
| npm support helps to make mature libraries accessible, but the
| Deno native libs also have a bright future.
|
| [1] https://github.com/chromakode/coalesce/tree/main/project-
| ser...
| dunham wrote:
| I tried deno a while ago (over a year) and could not find a way
| to get deno and typescript to accept the same files. They
| disagreed about filename extensions in import statements, and I
| couldn't find a format that was accepted by both.
| chromakode wrote:
| The repo I linked to has an example of shared files between
| Deno and Vite. I'm using import maps to have a consistent
| `@shared/types` module between both (as well as consistent
| names for the requisite imports)
| AgentME wrote:
| Are you trying to use Typescript separately from Deno instead
| of Deno's builtin support for Typescript? Are you using
| VSCode without the Deno extension? I think you're
| overcomplicating something if you're running into this issue.
| JediPig wrote:
| I feel that using words like "fast" and "convenient" with deno
| TS/ node JS, is an utter lie. Have you seen the horrible mess of
| web development caused by JS platform taking over backend and mb
| of js files just to write a text to a DOM element?
|
| Finally Douglas Crawford is admitting what we all said more than
| a decade ago. Its time to move on from javascript and learn from
| our mistakes, USING TS from MS, is not learning from our
| mistakes. Using Node & Deno is not learning, its patching a
| horrible played out solution to the next generation.
|
| what to use now? who knows, but enough of the code bloat. Enough
| of OOP that has horrible.
|
| for a web request to take more than 10 ms with the modern cpu is
| utterly full of bloat. Has anyone seen the one where typing in
| chrome's search box, causes 1000 std::string allocations?
|
| Yes its that bad. Let it die and MOV on, =fromBloatHell
| glutamate wrote:
| What is your problem? If you don't like JavaScript don't use
| it. I think it's a great language that allows me to do
| lightweight OOP and FP programming. Since you don't like it
| just use another language.
| JimDabell wrote:
| > Since you don't like it just use another language.
|
| Which other languages work comparably well in the browser,
| with similar functionality but without large runtime /
| standard library downloads?
| patmorgan23 wrote:
| JavaScript is not a good language. It was in the right place
| at the right time (the browser in the early 90/00s) The way
| it does dynamic typing is insane, error handling is hot
| garbage, and the GC nature of it means you can get
| unavoidable stop the world latency while the GC runs.
|
| You can certainly do a lot with JavaScript and there's a
| massive echo system around it. But that doesn't mean it's
| _good_.
| cdelsolar wrote:
| ok what's the alternative
| msie wrote:
| You can use any other language on the server side. What would
| be good is if wasm had full access to the DOM instead of
| through some JS layer. Or maybe a new browser is created that
| did away with JS altogether. It's always been my dream.
| AtNightWeCode wrote:
| Cloudflare workers if you want JS/TS.
| jweir wrote:
| There is no _the_ alternative.
|
| But there are alternatives. I would reach for Go. I'm not
| great at it but good enough that I know I can code up a
| server. And I know it will be be stable and simple to deploy
| - upload the binary and run it via systemd.
| msie wrote:
| Yes! I was inspired by levelsio's use of PHP but I don't
| want to use PHP. I was once enamoured by Python but it
| still hasn't fixed it's dependency management problems. Go
| occupies a nice place with the simplicity of Python but
| with static typing and better tooling.
| skybrian wrote:
| JavaScript isn't going to perform as well as C++ or Rust, or at
| least not consistently, but V8 does pretty well for a scripting
| language. It has definitely passed "good enough" and for many
| people, that's good enough. There are websites are written in
| Python, after all.
|
| You can drop into WASM to get more speed without performance
| cliffs, or for Deno itself, they use Rust.
| msie wrote:
| If only Google had the courage to put Dart into Chrome...
| Cyberdog wrote:
| So we would have even more web sites that only work in
| Chrome?
|
| Your username is "msie." Do you remember what Microsoft
| Internet Explorer 6 did to the web?
| msie wrote:
| Yes I do but there's no innovation without someone taking
| that first step. It was from IE that we got XmlHttpRequest.
| IshKebab wrote:
| Dart 1 was not very good though, so we'd have been stuck with
| that.
| msie wrote:
| What's to stop them from updating the language? I mean we
| are not stuck with JS version 1 either.
| IshKebab wrote:
| We can only make backwards compatible changes to
| Javascript; Google has made several backwards
| incompatible changes to Dart.
| white_dragon88 wrote:
| But things move faster now and are more likely to be
| immortalised in client software
| frou_dh wrote:
| IIRC the language design took a significantly different
| direction after the original leadership got fed up and
| left.
|
| So if someone likes the current version of Dart then
| rejection by the browser might be inherent in how it came
| to be.
| suby wrote:
| The browser reinforces javascript ecosystem dominance. We are
| not going to deprecate javascript in the browser because that
| would break the world. The way forward is improving wasm, and
| improvements there are coming, but even so the performance is
| roughly comparable to javascript in all of the benchmarks I've
| seen.
|
| Even if we get to a place where wasm performs much better than
| javascript, javascript will remain dominant due to the fact
| that it's the default. It is what it is, we're stuck with it
| short of something like AI changing everything.
| IshKebab wrote:
| Have you actually used Deno? Typescript/Deno is a whole
| different beast to NPM/JavaScript.
|
| Yes there are still areas of JavaScript that suck, e.g. the
| whole prototype system, and the standard library (how they
| managed to fuck up String.replaceAll() is anyone's guess), but
| the overall package is actually pretty good!
|
| Way better than Python for example (though that isn't saying
| much).
| [deleted]
| colordrops wrote:
| Are these really JS problems or problems with so many layers of
| abstraction? I don't really see any specific critic of JS here,
| just a lot of vague concerns.
| dmix wrote:
| > Have you seen the horrible mess of web development caused by
| JS platform taking over backend and mb of js files just to
| write a text to a DOM element?
|
| Deno is one of the pioneering projects (via
| https://fresh.deno.dev/) pushing SSR to the maximum so we _don
| 't_ need MBs to render DOM elements... unless you know, you
| want any sort of interactivity which every single client-facing
| SaaS app ends up needing (for which hydrated 'islands' are used
| only when necessary).
|
| Unless you remove the need for desktop-style interactivity on
| the internet JS is never going away. _Maybe_ WASM will help
| here (w / even worse Web standards), but I could reverse your
| same critique and point at all the horror-show UIs backend devs
| have built using backend-style code.
|
| I don't personally use JS server-side but I get why people do
| and it's not the language/runtimes making apps slow. Backend JS
| adoption is heavily informed by the dominance of JS on the
| client side, ease of hiring, and an effort to keep data
| structures DRY.
|
| > Enough of OOP that has horrible.
|
| OOP is not a requirement in JS and I rarely see it being used
| heavily these days. Nothing like Java or some awful Ruby
| projects I've seen.
| pjmlp wrote:
| Pionering as in, rediscovering how we used to serve pages 20
| years ago?
| dmix wrote:
| 20yrs ago we had desktop-style interactivity on the
| internet?
|
| Everyone acts like there was no reason why people started
| adding Javascript to webpages. Whole swaths of the entire
| developer community just fell into because they were dumb.
|
| If static pages alone could accomplish what people wanted
| from the internet they would have figured it out a decade+
| ago. Now the industry is shifting to delivering the same
| level of functionality with the bare minimum of JS on-page.
| Yet people act like it's all the same.
|
| Probably because they've never actually used any of these
| modern high-performance desktop-tier web apps like
| https://linear.app
| JimDabell wrote:
| > 20yrs ago we had desktop-style interactivity on the
| internet?
|
| Yes. I believe desktop.com was launched in the late 90s,
| so well over 20 years ago.
|
| https://web.archive.org/web/20021217213351/https://www.in
| ter...
|
| > Now the industry is shifting to delivering the same
| level of functionality with the bare minimum of JS on-
| page. Yet people act like it's all the same.
|
| It mostly is. Best practice was never to _avoid_
| JavaScript, that was just a caricature repeated by bad
| JavaScript developers. Best practice was to start with a
| solid foundation that worked for everybody and add on the
| interactivity as an optional extra. All the best
| JavaScript developers of the time were writing stuff that
| was client-side interactive but was still primarily
| server-driven.
| dmix wrote:
| The innovation here is not about just being picky about
| where you add JS. That was always an option. It's about
| frontend teams having the tools to build their views in a
| single cohesive place, in a single structure, without
| having to make a tradeoff between SSR and client-side
| rendering. It is automatic and part of the frameworks.
|
| This is very important. Take rails for example, modern
| projects have `/app/views` for ERB templates and
| `/app/javascript` for the React/Vue views. It's natural
| for frontend teams to push more and more stuff into
| `/app/javascript` instead of the static `/app/views`.
| Because the JS frontend is where the highend-CSS
| tooling/clean reusable component libraries/high quality
| UI testing libraries/etc/etc live.
|
| Sure you could be extremely careful and divide the two.
| But in practice it's much harder than it sounds. You're
| basically running two different frontends.
|
| Having the components that compose the views simply be a
| single SSR (y/n) checkbox is far better AND even when
| it's not SSR it still renders static in the UI instantly,
| then hydrates in the background. So no vDOM loading time.
| We've never had anything like that before for high-
| functionality JS views.
|
| And it goes beyond that too. Linear has made tons of
| innovation in how data is synced with the UIs + offline
| support. see:
|
| https://replicache.dev/ <- static HTML offers none of
| this sort of fully offline cached data performance +
| realtime syncing UIs
| colordrops wrote:
| I agree with everything you are saying in this thread,
| but https://linear.app is one of the slowest websites
| I've ever encountered. Animation fade-ins before you get
| to the content, and something heavy is happening which
| causes scrolling to be at most 3fps.
| spiralpolitik wrote:
| Deno is great. I put together a website using Lume super quickly
| and it was a refreshing change from using Node etc.
|
| Some annoyances, mostly around the Deno Deploy side of things,
| but otherwise I'm a huge fan.
| new_user_final wrote:
| http benchmark are mostly useless. Most of the benchmark re-uses
| connections. You will get around 14k requests/second if you close
| the connection for each request.
| mmastrac wrote:
| As part of my first couple of months of work at Deno, I wrote the
| new Deno.serve implementation that's being stabilized here. It's
| based on a thread-local slab that is wired into Hyper 1.0 (which
| is an amazing Rust webserver and nearing release).
|
| This gave us solid support for HTTP/2 in Deno itself -- you can
| start a full webserver on a TLS socket and start talking fully-
| compliant HTTP/2 in just a couple of lines.
|
| It's an interesting challenge to get this to cooperate with V8 in
| a performance way and we're continuing to work on it while
| keeping the code as maintainable as possible. The implementation
| will continue to evolve as we design better and faster interfaces
| between Rust and V8. The cool thing is that this is all going
| into open-source projects, either in Deno itself, rusty_v8 or V8
| itself.
|
| Happy to answer any questions.
| plopz wrote:
| Does it have HTTP/3 features like WebTransport?
| mmastrac wrote:
| Not yet, but we are keeping our eyes on HTTP/3. There are a
| few good options for us to integrate it, but we want to make
| sure we do it right (and meanwhile figure out the right way
| to expose HTTP/2 features that aren't available yet).
| white_dragon88 wrote:
| Sounds like sales speak, nodejs isn't even there yet.
| steveklabnik wrote:
| There are like three different http/3 implementations in
| Rust, used in real ways. Even if they don't want to write
| their own, there's a lot of choice out there.
| mholt wrote:
| That's awesome, any automatic HTTPS (ideally by default)?
| mmastrac wrote:
| Yep. As long as you give Deno.serve a certificate and private
| key and you get modern TLS, HTTP1 and HTTP2.
| mholt wrote:
| Oh, sorry, to clarify, I meant: HTTPS that works
| automatically. By starting the server, it's starting HTTPS
| by default. It gets or generates a certificate for you and
| renews it, etc.
| mmastrac wrote:
| In this case, not in the built-in Deno.serve case.
| Certificate management is definitely a challenge,
| especially for local development.
| skybrian wrote:
| Does streaming work? Server-sent events?
| KRAKRISMOTT wrote:
| Everyone's interested in SSE again thanks to serverless and
| Open AI's API
| kreetx wrote:
| Open AI's API is using SSE to stream results?
| mmastrac wrote:
| Both of these definitely work. I'm on my phone right now so
| finding references is a challenge, but you can stream either
| of these ways (or use WebSockets) using Deno.serve.
| galaxyLogic wrote:
| So how do I get the SSL certificate in there, does it come with
| it?
| tomxor wrote:
| I found this:
|
| https://deno.land/manual@v1.35.0/runtime/http_server_apis#ht.
| ..
| mmastrac wrote:
| I would personally use letsencrypt and then pass the cert/key
| into the Deno.serve call, though I am curious now if there is
| a more integrated solution and I'm going to dig into it a
| bit.
| vbezhenar wrote:
| Use Caddy.
| Aerbil313 wrote:
| Yes, I too am too lazy to learn nginx, certbot or whatever
| those things are as well.
___________________________________________________________________
(page generated 2023-07-05 23:02 UTC)