Comment by nathan_f77 | Hacker News Reader

Comment by nathan_f77 | Hacker News Reader

Parent Full thread

The author talks about Immutable.js, but doesn't mention Records, which have been a real godsend in my application. I use Immutable.Record with types [1] (using Flow), and I feel very confident with this setup. You are forced to set default values for every key, and the code will crash if you try to set a key that hasn't been defined.

It's really great to have typed Records (often nested), and I expose the getters as regular properties so that I don't have to call "get()" all the time. I agree that it's not perfect, but it's miles ahead of anything I've worked with in the past (at least in terms of JavaScript.)

JSON schemas are awesome, and I like the idea of validating types at runtime on the front-end. I already have a JSON schema that defines my API (I use Swagger), so I could even go one step further and auto-generate my typed Records directly from the schema. I'll get immediate feedback about any type errors in my JS codebase as soon as I make changes to the API. I generate my Swagger API specification automatically from some RSpec tests (using rswag [2]), and I also run Flow during CI, so this would result in a broken build. I could also make this work with the data I'm inlining in the HTML to hydrate the Redux store.

Random aside: I also have a one set of data that just gets dumped into a jsonb database column, so the schema for this specific data is only being defined by the front-end code. In my backend I'm always careful to provide a default value, but it's not really critical data. Anyway, I just realized that I should be defining this jsonb column as an actual model, but instead of ActiveRecord, I could use ActiveModel and a plain Ruby class. That's a neat idea. It would give me a schema and validations on the backend, while still having the flexibility and performance of storing everything in a single json column.

[1] https://gist.github.com/glenjamin/75a96b45f4bb5c6ac221815d28...

[2] https://github.com/domaindrivendev/rswag

With Bucklescript/Reason you get typesafety, immutability, performance and small codesize:

>Now we compare the runtime performance:

   BuckleScript Immutable Map: 1186ms
   Facebook Immutable Map: 3415ms

We also compare code Size:

    BuckleScript (Prod mode): 899 Bytes
    Facebook Immutable: 55.3K Bytes

source:

https://github.com/BuckleScript/bucklescript/wiki/Why-buckle...

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.

Does BuckleScript do any runtime type checking? If not, you have the same problem the moment you call out into any pure JS library - your type annotations say what you expect, but JS code can merrily give you something else.

I have to admit, as much as I enjoy working with TypeScript— this same problem is always on my mind. I find myself continually writing the same tests for type safety that I would in JS. I have to remind myself that, yes the types are safe while writing, but still not quite at runtime. It can lead to pretty fundamental flaws if you’re not careful.

That just means the type annotations are incorrect, and how would runtime type checking solve that?

It wouldn't solve that, but it would prevent the code from running with data that is incorrect according to type annotations. Think of it as a runtime assert that is automatically generated from the compile-time type annotation.

(Unfortunately, the JS runtime object model does not allow for such runtime type checks to be performed with reasonable performance.)

I’m still amazed by how much faster transpiling from Reason is compared to TypeScript or JavaScript is via Babel.

OCaml as a language is so close to a sweet spot between performance and ergonomics in my experience. I'm not sure if the Bucklescript compiler is generally running on Node or natively, but that could also be a big variable at play here.

Afaik it's native. The `bs-platform` node package contains native binaries.

Thank Bucklescript.

regarding records specifically:

https://medium.com/@javierwchavarri/performance-of-records-i...

Probably the reason is that reasonable Flow types for Records aren't in the mainline 3.0 release, and 4.0 (with good static typing support) has been in RC hell for about a year and a half.

Records is also how elm deals with JSON serialization IIRC.

Reply on news.ycombinator.com