Hacker News Reader

Comment by incadenza | Hacker News Reader

This all sounds great but I cringe a bit at yet another layer of abstraction in an already insane JS tooling ecosystem.

It seems like half of the time you’re just using the escape hatch to plain JS to stitch all of this stuff together, no?

Try elm. The elm abstraction is probably the only one where you literally will never ever touch javascript or raw html.

It is the least leaky abstraction I have ever encountered, which is amazing given the fact that it is also blazingly faster than every other framework from React to Vue. Elm is a way higher level abstraction then jsx or Vue yet you don't need to understand the lower level details to produce more efficient applications.

The most leaky abstraction I have ever encountered is probably SQL. Optimizing SQL involves understanding what it compiles into; Elm there is no such understanding required.

This is the opposite of my experience with Elm. Tried it for a while. Getting the time or a random number takes a tutorial to learn how to do because those things aren't purely functional.

Then I wanted a fast lookup table, turns out all dictionary lookups in Elm are nlogn because it's backed by an immutable tree structure.

So, I disagree with you and went back to JavaScript.

Although I disagree with you, I never stated one was better then the other. All I said was that elm was the least leaky abstraction I've ever encountered. Your frustration with IO proves my point. There is a practical logic around why it was done that way, but the practicality won't be apparent until you create a huge 10 million LOC monolithic SPA with elm and compare it to the same type of app written in javascript.

> All I said was that elm was the least leaky abstraction I've ever encountered. Your frustration with IO proves my point.

Doesn't that prove my point, that there's an impedance mismatch of Elm trying to present a purely-functional world on top of a very side-effect-full environment of the browser+DOM etc.?

> but the practicality won't be apparent until you create a huge 10 million LOC monolithic SPA with elm

It sounds like you're arguing that for apps smaller than "absurdly large", plain JavaScript can be better.

Calling bs on anyone having anything approaching 10 million LOC in Elm. You're just making things up.

Edit: for reference, the Linux kernel has about 20 million LOC (according to Wikipedia), so you're talking about half a Linux kernel written in Elm. Absurd.

>Doesn't that prove my point, that there's an impedance mismatch of Elm trying to present a purely-functional world on top of a very side-effect-full environment of the browser+DOM etc.?

Your reply doesn't even address my point. That's all I'm saying. All I said is that I disagree with you.

>It sounds like you're arguing that for apps smaller than "absurdly large", plain JavaScript can be better.

>Calling bs on anyone having anything approaching 10 million LOC in Elm. You're just making things up.

>Edit: for reference, the Linux kernel has about 20 million LOC (according to Wikipedia), so you're talking about half a Linux kernel written in Elm. Absurd.

Don't ever call what I say absurd or BS that's plain offensive and against the principles here on HN. If you want me to continue replying to you, I'll need an apology otherwise I will ignore you.

The comparison is quite unfair. Elm manages a system of 1k nodes accessed by one user while sql manages a system of 1m records accessed by 1k users (i am counting browsers) soo... yeah, leaky. You never ever have to optimize anything in sql when you have tables with 1k rows. It’s the scale of things that forces you to optimize.

elm is a high level abstraction that's faster then simpler lower level abstractions like jsx or vue. That's why it's a really good abstraction.

SQL is a leaky abstraction not because of scale. Scale is a requirement and the chosen abstraction for scale is actually not the wisest choice. SQL is an expression based language used to execute algorithms like binary search that are inherently imperative. Thus it is a bad abstraction and the scale of the requirements magnifies this. The need for the EXPLAIN ANALYZE key words exemplifies this flaw. A good abstraction for databases would be a language that explicitly declares the algorithm used for the query. This would make users able to explicitly optimize the query without needing to cross the barriers of abstraction. Like googles V8 implementation of javascript, ubiquity and tons of resources invested into creating an incredibly efficient implementation of an interpreter have made SQL and javascript the best choice for their respective fields even though they wouldn't have been the best design choice if people were given the choice to start over.

Rust is a better design then C++ but again ubiquity, early adoption and random forces have made languages with questionable design choices the dominant paradigm.

I like elm but:

- JS Interop is harder in elm.

- Inferno and some others are a lot faster than elm.

The JS interop is basically a leak in the abstraction. It in itself is a flaw and I'm claiming that elm is such a good abstraction that you don't need to access or touch the holes in the abstraction.

Never heard of inferno... I'll check it out.

Reply on news.ycombinator.com