23 comments

[ 622 ms ] story [ 235 ms ] thread
I love the idea of having everything in one language; dealing with just one thing instead of HTML, CSS, and JavaScript.

But isn't that why everyone moved over to React, Angular, and Vue? It's nice that this is in WASM but honestly, I think I prefer React components written in TypeScript, and you can probably get that compiling to WASM with AssemblyScript.

My two cents: this is a super neat hobby project! Probably won't ever make it to production anywhere though.

No, JSX in AssemblyScript with the same dev experience is very far away.

AssemblyScript is awesome, but right now it's more similar to C (with TS syntax) - it's not a TypeScript runtime on Wasm, it's a lowlevel language that looks nearly the same, that hopes to integrate Wasm GC etc when it comes (not yet).

Static TypeScript is much closer to regular TypeScript. But it doesn’t support JSX either (and I while it might make sense with a custom pragma it certainly wouldn’t make sense with React as a default).
That's ultimately why I couldn't move forward in it. My brain just kept thinking typescript and it was hard to manage the cognitive dissonance of it being identical syntax but with invisible limitations I wasn't used to.
The optional parentheses makes the syntax quite ambiguous.

    fibonacci it - 1 + fibonacci it - 2
I'm only hoping to understand what we have here because I already know what Fibonacci is.
This really just seems to be ML-style syntax - which is not ambiguous at all, it's just different from C-like languages (functions applied one argument at a time, with function application (empty space) having the biggest precendece)
In this case (and if it were interpreted as Haskell syntax), the above term would be wrong.
Is it one of these?

  fibonacci (it) - 1 + fibonacci (it) - 2
  fibonacci (it - 1) + fibonacci (it - 2)
  fibonacci (it - 1 + fibonacci (it - 2))
On any sane ML-style language, it would be this:

    (fibonacci it) - 1 + (fibonacci it) - 2
But I guess it isn't the case here, because that code doesn't make sense.
The actual example in the readme is unambiguous:

   fibonacci(number - 1) + fibonacci it - 2
My thoughts -- why does everyone have to come up with some new, _novel_ way of writing html?

Looks like all the examples of wasp are just declarative objects and/or html, so not sure what wasp can do just from looking at those.

Especially when it doesn't seem to bring anything over haml and pug.
The most concise and precise way to write a language is generally in the language itself too.
Doesn't really apply to HTML.

Using indentation instead of XML-like opening and closing tags is way more concise, and encodes exactly the same information.

It's shorter, I don't know about concise though I suppose that's a subjective point anyways. While it's generally exactly the same there are some corner cases involving formatting rather than structure tags where it's not always 1:1.
(comment deleted)
Thinking the same thing too. I find it a lot easier to read an HTML markup that a Wasp equivalent. Perhaps it's because I'm not a bard core dev, but reading all those {} is visually straining.
For me it's about the fact that html was designed for documents with minimal interactivity, and while it's possible to represent a highly interactive application in html, it poses several significant headaches for developers.

I don't know the right solution, but it's clear that what we have right now doesn't suit our needs and make web development far costlier than it otherwise could be.

I'm not sure how wasp and angle interact. It looks like angle uses wasp, so is angle the important thing here? Or is wasp a standalone thing?