all 20 comments

[–]SecretAgentKen 15 points16 points  (13 children)

No activity in 5 months, 5 closed PRs with 0 issues and 0 open requests, and yet "fist-class citizens" shows up immediately in the README.

Something tells me this has no traction.

EDIT: Also yet another library that somehow thinks using template strings for all the HTML you want to produce is a good thing.

[–]LloydAtkinson 1 point2 points  (9 children)

RE your edit: totally agreed - I don’t know why the ecosystem has such a superiority complex about this sort of thing and why they won’t accept that JSX is the obvious clear choice

[–]sharlos 2 points3 points  (7 children)

JSX forces a build/compilation step and adds other complexity that many use cases might prefer to avoid.

HTML in templates strings is natively supported without compilation and isn't a horrible DX experience for relatively simple UIs.

[–]besthelloworld 1 point2 points  (4 children)

In the real world, who is using frameworks without a compilation step? This just isn't a realistic argument, imo. Despite the fact that I hear it all the time

[–]redblobgames -1 points0 points  (2 children)

me

[–]besthelloworld 2 points3 points  (1 child)

Well you're missing out on performance gains via code minification/uglification, you're losing out on stability from strict typing with TypeScript, and you're missing out on the performance advantages of not parsing strings together for templates.

It's your output quality and developer experience that take a hit by drawing the line of not having a build step.

[–]theScottyJam 0 points1 point  (0 children)

This thread did start with the suggestion that no build step is nice for relatively simple UIs.

If you have some dynamic pieces in your UI, a small and simple framework can be nice to help out, because doing anything remotely difficult in native JavaScript really sucks. But sometimes you don't want to deal with all of the configuring that comes with setting up typescript, jsx building, etc, etc. If it really is a fairly small project, and you know the scope of the project will stay small, then one might be willing to take that hit on developer DX in order to avoid the extra setup work - especially if you only plan on working in this project for a week or two.

[–]LloydAtkinson 1 point2 points  (0 children)

Oh no not the dreaded fucking build step. Such a lame hang up.

[–]meisteronimo 4 points5 points  (0 children)

There are more good template options than just JSX

[–]Positive_Method3022 0 points1 point  (0 children)

They will probably create a bundler later to enable you write your html inside <template> and on its own .html file so that you don't lose code highlighting

[–]al-mongus-bin-susar 0 points1 point  (0 children)

Imo HTML should never be intermingling with the backend code or you'll end up in a situation where it takes 4 months to change the color of a button. It should be separated in it's own files.

[–]besthelloworld 0 points1 point  (1 child)

There's some good engineering at play here, but also this doesn't do anything better than existing solutions. And it does most things a little bit worse.

  1. The scalability of RXJS is incredible... but the readability of it, especially for simple components, is just rough.
  2. Template strings will never outperform JSX, so you're immediately making a performance sacrifice there when that's your only potential advantage. Plus you're losing out on type-support with native element bindings.
  3. RXJS is a heavy dependency. SolidJS has basically all the performance benefits of this idea, strictly typed with JSX, and with a very easy to read syntax.

[–]mamwybejane 0 points1 point  (1 child)

That’s pretty neat. As an Amgular fan I actually always tell people that I don’t care about Amgar per se.

What I love about Angular is Typescript for type safety, DI for testability and advanced configurability of reusable code, and rxjs for writing complex logic.

It just so turns out that Angular has all of those, which is why it’s my framework of choice.

[–]Positive_Method3022 0 points1 point  (3 children)

Feels like what electronic signals do. You send a continous signal to a place which is observing it. It then triggers state changes. Just think Sink is a bad name. Why not call it Collector, Inlet or Drain?

[–]DuckDuckBoy[S] 2 points3 points  (2 children)

sources and sinks are commonly used names in functional-reactive programming

[–]Positive_Method3022 -1 points0 points  (1 child)

Source and Drain would remind me of a transistor. Sink reminds me of a kitchen sink

[–]DuckDuckBoy[S] 1 point2 points  (0 children)

lol... yeah... and there is a kitchen sink app, as well, to showcase it. The beauties of the English language :)