Aleph.js – Fullstack Framework in Deno | Hacker News Reader

Aleph.js – Fullstack Framework in Deno

github.com

87 pointsmodinfo49 comments

Am I missing something? Or is there no actual documentation for its current incarnation? Clicking the link and then following the link for documentation is an infinite loop.

The only thing I ask to Deno is to make typescript development as immediate as running python.

I'm exhausted by webpack and similar

It is. Deno runs TypeScript out of the box.

It strips type info and runs it as Javascript, though. There's no native typescript runtime, AFAIK (it doesn't enforce types at runtime, only at build time)

There is no such thing as a TypeScript runtime. TypeScript has always been a static typechecker

People say this all the time.

What does “enforced type system” mean to you? To my knowledge there is no language with a system that adds type checks (except in the case of checking a cast inside of a nominal type system).

Casts are such a tiny slice of code, and you can choose to not use them! It adds tedium, but none that would be missing in other languages.

You do realize deno is based on the V8 JavaScript Engine and there isn't such thing as a typescript runtime even by Microsoft the developers of typescript?

https://en.wikipedia.org/wiki/TypeScript

Deno used to run the type checker with the `run` command, but now you need to pass a flag to run the type checker.

And that’s a good decision. It lets you choose fast start times and run your type checker in your editor or a separate console, which is what I do in all of my Node applications.

Sounds like that could be resolved with a simple alias in your shell?

This is different from what the GP is asking about, though

Most languages intentionally avoid checking types at runtime except in specific situations where it's required (e.g. explicit typeof checks.) You do not want run time type checking on every variable access.

PHP has entered the chat.

You can always use one of the million different runtime type-checking libraries at IO boundaries.

Im not sure why are you down voted, because your statement isn’t wrong, I’m not sure of Deno internals, but what GP said is also true, AFAIK is similar to run your TS app with ts-node but without the need to add a dependency, so it means that you just execute `deno run index.ts` and it worke, I’m not 100% sure but I think is also works with tsx/jsx files.

While the comment is technically accurate, it's:

(a) worded as a contradiction to the parent comment but isn't (it just talks about something unrelated - runtime typechecks). Deno does run typescript code out of the box, typechecks aside.

(b) the technical accuracy isn't particularly significant/relevant since in practice Deno has a simple switch to check types on run (though I'm not sure why you would want to do that outside of a development environment: Typescript is a static tool & doesn't have any dynamic capabilities that would change results based on runtime environment).

> It strips type info and runs it as Javascript, though. There's no native typescript runtime, AFAIK (it doesn't enforce types at runtime, only at build time)

Java strips type info and runs it as JVM byte codes. There's no native Java runtime, AFAIK(it doesn't enforce types at runtime, only at build time).

What's the problem?

Just because something has been done before doesn't mean that it's a good thing.

I agree what you're saying, but they were talking about Python and TypeScript - it doesn't make sense to bring up type erasure in this context.

You probably don’t want that throughout your entire codebase. It’s a lot of overhead. Where you do want it (at API/user input/network etc boundaries), you can use something like Zod[1] or similar to define your type guards and then infer the static types from there.

1: https://github.com/colinhacks/zod

> There's no native typescript runtime.

A proposal was actually floated recently to grandfather in TypeScript-like annotations[1]. It would be ignored by the runtime and treated purely as a comment, and would be optional. This is what native runtime support for TypeScript would look like. Not sure if it will ever gain official support in the language though.

> it doesn't enforce types at runtime, only at build time

Runtime type "enforcement" is just your program breaking, for example "undefined is not a function". Well, I guess it isn't so simple, because JS does a lot of implicit type translation behind the scenes, like helpfully converting "123" to 123. It would be possible to "enforce" types at runtime by turning off that language feature in certain situations, but I don't think it will happen, for back-compat reasons.

[1] https://github.com/tc39/proposal-type-annotations

You can think of Webpack as a really powerful, fully-featured, plugin-oriented webserver (to serve your JS, assets, data etc) for Nodejs.

You can rebuild the whole thing in Deno or whatever but you'll probably end up with the same boilerplate if you want it to cover all the features Webpack has.

There is no way to do that because the v8 engine interprets and compiles JavaScript, not TypeScript. You can use esbuild, which is much faster than webpack. Deno uses swc, which is faster than webpack as well. You don't need to use deno to get that experience though.

Use esbuild to transpile and bundle your typescript. It's 10-100x times faster. The only issue is that esbuild only removes the type-only part of typescript, and doesn't do the type-checking part.

Is it related in any way to Fresh?

https://news.ycombinator.com/item?id=31720110

They are different projects, Aleph is more or less the Next.js for Deno.

Also AFAIK Fresh uses a different architecture, where it can compile your app as micro frontends or island architecture if you like, you can check out Astro[0] to understand better this architecture.

[0] https://astro.build

This looks great! Checked out some of the example apps and the code looks really clean compared to other frameworks I've recently used, and I love the elegance of the

   export const $VERB ...

structure of the server route files.

Should at least have some documentation to read before sharing. There's no info about what this does/how to use it on the repo or the site.

What is "fullstack framework" supposed to mean? "It can do everything"?

It just means "I handle front and back end" and it's all typescript.

Probably can do both the server and client side.

Yes, but what it does mean? What are the actual capabilities? There are no docs.

I couldn’t find docs either I reckon this has been posted here a bit too early

this framework with 4.2k github stars appears not to have any docs at all (i went to alephjs.org and it just redirects to the github repo). am i missing something?

They removed the docs for the older version of the framework which was used by many people (hence the stars).

New web framework, why?

Why not? Is it a problem?

I wish every developer I had to work with had written their own framework at least once in their lifetime. It teaches you a lot.

Why?

Because most if not all frameworks run on Node.js, while Aleph seems to aim to be the Next.js for Deno.

> WE ARE CURRENTLY REWRITING THIS FRAMEWORK, MANY THINGS ARE STILL SUBJECT TO CHANGE AT ANY TIME.

Noticing a pattern here with deno projects.

Well deno is about five years old. That is to be expected, isn't it ?

The timing feel similar to rust to me. It needed almost a decade to have real production ready project. Mozilla was an exception as they built it.

Maybe I'm spoiled, which I'm willing to consider being true. However, one could assume that projects at this stage would use versioning, pinning, and documenting the changes to the api, which obviate the need for these types of disclaimers. All caps disclaimers like this could discourage those who are otherwise capable from giving it a shot.

Im not saying this is deno's fault, maybe it is and maybe it isn't, I'm only saying I'm noticing that rather than documenting through breaking changes people would prefer to make prominent disclaimers that are essentially buyer beware

I'm currently developing an "experimental" piece of software, i.e. I am not even sure some features I want to add are possible, meaning I had to rewrite it a couple of times (and won't be the last). Having strict versioning, pinning, and documenting everything before it reaches a semi-stable state would discourage me from developing it altogether.

I agree with the approach they are taking, keep the disclaimer, put it out there, get some visibility to find early adopters and contributors and stabilize it. A year from now people will have forgotten about this thread and will see it a new and stable framework.

I think if you look at Angular as an example, the Aleph team is doing it right. Angular didn't just make breaking changes when they went 2.0, they basically abandoned everything about 1.x and released something completely new. There were definitely people who had just learned Angular 1 that found out their time was poorly spent.

That doesn’t sound right to me.

Rust 1.0 released in 2015. Facebook had a source control server in production in 2018. Does that count as “real”?

Deno 1.0 is roughly two years old. It's also apples to oranges. Deno is a JS runtime plus a std library. Aleph is still an experimental web framework. If you want to make a more apt comparison look at the web framework/library stuff in Rust that has frontend affordances/capabilities, which has a similarly immature v0.X feel to it.

How many years before a language is mature enough that it's not to be expected? I'm thinking 5 years is starting to push it, but others may have other opinions.

on edit: when saying push it I mean sort of still reasonable, but maybe a bit troubling? 7 years would definitely feel like too much to me. I wonder if there are any studies.

Deno 1.0 is actually only 2 years and not 5 years.

Ok, but obviously when I say 5 years I mean from the start of development of the language not from when it is given 1.0 status. Is it your contention that the count to 5 years should start from when language creators say it is at 1.0 - if so I think 5 years is way over the line for when people should be saying they are rewriting projects written in it from the bottom up periodically.

Start of development could be a "hello world" commit, so I would say any critical judgements should always be from the 1.0 release. Far too much churn before then anyways. Rust changed a truckload.

Reply on news.ycombinator.com