Elm vs Vue/React which one do you prefer to use with Phoenix, and why?

General Prog (Archived)
, ,
61

I’m really bad about keeping links around (or rather I keep too many around with too little context…). ^.^;

Let me see… I think redom was one of the ones I liked on a cursory look; it wasn’t my favorite that I have found so far (which of course is no doubt incomplete considering all the JS stuff out there), but it was good. CycleJS was a really good looking one as well. There was one that I can’t remember that was my favorite though, can’t recall the name and not finding it on google. Google’s Polymer is of course another though it comes with so much stuff that it is a bit heavier. Can’t recall the one that I really liked though (hmm, it used a single function to register a new data endpoint, to link data nodes together, to push updates to specific DOM elements, etc… etc… really simple, and tiny)…

There are a number of libraries for C++, OCaml, Rust, etc… that have similar updating features (though not DOM related, rather just more generic) as well.

1 Like
62

I tried to learn a front end framework after not doing front end for a year or so.

I did ember and angular 1 before this.

I did my research and chose vuejs. It seems better for me because I have tons of experience in javascript. Elm didn’t seem transferable in skillset and frontend dev move too quickly for my taste.

Currently just using jQuery and I’m so happy for it. Vuejs and frontend ecosystem move too fast for me and as a fullstack dev I can’t be a master of all unless I have no life and don’t want a family. If I were to stick to mastering vuejs I would force myself to learn typescript. It’s the direction the library is moving toward in version 3. I’ll come back when VueJS dev slow down. Also when webcomponent comes out and stabelize all these frontend web framework is going to change and it’ll make it a hell of a lot easier to do web dev (knock on wood).

63

You should try not using jQuery, just plain ol’ vanilla javascript. jQuery was a crutch for the times of IE8 and Netscape Navigator, it is entirely unnecessary for the modern web, and take a look at the performance difference as well, jQuery is significantly slow because of all the backwards compatible checks within it. For example, unpoly.js removed jQuery in exchange for normal javascript calls and it had a significant performance boost with a substantial reduction in packaged code. :slight_smile:

3 Likes
64

Currently using bootstrap 4 so I’m sticking with jquery until bootstrap 5 release and mature. Basically too lazy to invest time on front end for my side projects >___<.

65

Have a look at a (no-frills) lit-html with unistore combo (unlit.js)

lit-html (like hyperHTML before it) accepts JS tagged template literals as “HTML templates”. Once parsed (by the browser) it stores the resulting template element in a cache indexed by the template literal that created it. So the template literal is only ever parsed once and creating DOM elements from a template element is fast by design (at least that is how I understand it).

The video lit-html (Chrome Dev Summit 2017) goes into a bit more detail but to appreciate what is being conveyed some deeper than average understanding of a browser’s capability is necessary.

My informal (likely oversimplified and inaccurate) perception:

  • React uses the vDOM as a firewall between itself, written in “it’s just JavaScript”, and the browser.
  • lit-html uses every possible opportunity to use the browser for what it is good at.

The template element is part of the web component spec so of course there is LitElement which uses lit-html.

I remember coming across some rumours that Polymer 3.0 primarily exists as a migration target for the existing install base. If the Polymer team continues to exist it is likely to move lit-html/LitElement along provided there is any traction. The Polymer landing page is suggestive at any rate:

The libraries now seem much more modular than Polymer proper (or worse, Angular).
Polymer Blog

Sounds like hyperApp but that uses the vDOM approach (h function generates vDOM elements, app function registers everything).

Actually looking at round 8 seems domc is more likely …

Aside:

search - results | Marko benchmark:
Marko vs Preact vs React vs Vue vs Inferno

Seems the claim is that lit-html/LitElement should be in the neighbourhood of Marko:

  • B Marko (226 ops/sec)
  • A Inferno (210 ops/sec)
  • C React (172 ops/sec)
  • D Preact (169 ops/sec)
  • E Vue (155 ops/sec)

color-picker | Marko benchmark

4 Likes
66

Typescript is not a thing. If you’re skilled in Javacript, you know what you do when writing it. You already know your types and Typescript is just about type annotations. It only encourages you to think about your types and it’s pretty nice (if you don’t use the marvellous any everywhere).

Regarding Elm, I used it and abandoned it due to too much boilerplate and slow evolution and the restriction of 0.19 but it worths to test a toy project with it because it forces to think about your data flow. After using Elm, I understood perfectly what’s behind Redux (of course, its Elm-inspired!) and other data managing solution you can see in JS world. And you will never see tow-way-data-binding with the same eyes…

1 Like
67

No there was no vdom, you didn’t even need to touch or generate DOM if you didn’t need it, could use it as a pure data transformer pipeline. This has been bugging me since yesterday… ^.^;

68

You already know your types and Typescript is just about type annotations.

With the years of experiences of coding in javascript I highly doubt I can ever for the life of me can claim that seeing how it implicitly type convert everything and it’s insane way of doing it.

But I’ll check it out if what you’re saying is true about it being not a thing.

69

Flow could be interesting.

https://medium.com/the-web-tub/comparing-flow-with-typescript-6a8ff7fd4cbb
https://medium.jonasbandi.net/here-is-why-you-might-not-want-to-use-typescript-part-1-alternatives-ec1248bb6dc?gi=e0077a4ec4fd

70

The State of JavaScript 2018: JavaScript Flavors

Ever since React + TypeScript has become a thing, Flow has been losing ground fast.

71

I stopped to read the first article when I saw " AngularJS , itself built in TypeScript , will naturally have native support for programming in TypeScript .". :sweat_smile:

To me TypeScript is a much better option than Flow:

  • 90% of TypeScript’s syntax is applicable to other languages, specifically C# and Java.
  • TypeScript has better integration with editors like VS Code or IDEs like WebStorm.
  • TypeScript has more support from the community and tons of learning material.
  • Flow checker is slow.
  • …

The only good thing about Flow is that you don’t have to learn a whole new language. However, you can migrate your project progressively with TypeScript, there’s no need to do it at once.

1 Like
72

And I see that as its biggest danger. As is pointed out in

https://medium.jonasbandi.net/here-is-why-you-might-not-want-to-use-typescript-50ab0d225bdd

TypeScript is not a replacement for ECMAScript competence. Apart from the type system being structural rather than nominal (at least they should be used to unsound behaviours).

Then there is the tag line:
TypeScript - JavaScript that scales and Strong Tools for large apps.

  • Something that is running in a browser should aim to stay small and concise - it shouldn’t aim to be “large scale”.
  • If you are running on a server there are a plethora of other more suitable runtimes and programming languages, why use JavaScript unless it’s for JS build tooling (likely reason - number of packages available on npm)?

TypeScript is a typed superset of JavaScript

Personally I don’t find that typical TypeScript reads anything like JavaScript - it seems much more C#-like, sweeping JavaScript’s Scheme-y parts under the rug (which then people dig up again).

Also TypeScript commits you to transpilation even for experimentation. These days Chrome supports a lot of the TC39 stage 3 proposals (and ES modules) so that you can push experiments in ESnext pretty far without any build tools (which are still needed for production builds).

<html lang="en">
  <head>
    <title>lit-html experiment</title>
    <style>
     body {
       font-family: sans-serif;
     }
    </style>
  </head>
  <body>
    <script type="module">
     import {html, render} from 'https://unpkg.com/lit-html?module'

     const inner = name => html`<span>${name}</span>`
     const outer = name => html`
       <style>
         p {
           color: green;
         }
         span {
           color: blue;
         }
       </style>
       <p>Hello ${name}</p>`

     render(outer(inner('World')), document.body)
    </script>
  </body>
</html>

Yes, I know that lit-html is written in TypeScript - it’s a Google thing.

There is a way to use TypeScript without messing up your JavaScript with @ts-check (usage described in Type Safe JavaScript with JSDoc). However JSDoc types are somewhat limited and most people find type annotations too verbose and cumbersome. Though in my opinion type annotations make sense with JavaScript as those don’t get in the way of just running the code “as is”.

Then there is the matter of a “false sense of security” brought on by TypeScript’s unsound structural type system. In Ideology Gary Bernhardt goes into how tests can’t replace type systems and that type systems don’t replace tests.

So TypeScript isn’t a replacement for ECMAScript - it should be viewed as an optional add-on. One should become throughly familiar with ECMAScript (and its pitfalls) before embarking on using TypeScript. In some circumstances TypeScript can make sense but it shouldn’t be assumed that its benefits will always outweigh its costs.

https://medium.com/javascript-scene/the-typescript-tax-132ff4cb175b

2 Likes
73

The screenshot from Stack Overflow is very misleading, since TypeScript is one of the most loved languages, and Angular the leading framework:

(I’m curious about the 2019 survey by the way, it should be posted soon)

So, you’re not limiting the pool of developers, there are a lot of jobs asking for Angular skills. Also Vue.js is being rewritten in TypeScript, and I won’t get surprised if Facebook drops Flow in flavor of TypeScript. Of course, TypeScript isn’t perfect, and it’s probably redundant for simple projects, but at least it gives you some kind of safety, safety that JavaScript as of now doesn’t provide.

People still worried about support for IE 8/9, don’t even mention stage 3 proposals or they will convince you to use jQuery! Jokes aside, I get your point, but transpilation should be a thing at least for the next few years, browser support is mandatory for some internal applications, enterprises doesn’t care if you’re the new cool kid in town writing modern code for modern software, first we need to forget IE and Edge.

1 Like
74

Wonderful article, https://medium.com/javascript-scene/the-typescript-tax-132ff4cb175b
For example

And a lot more percentages and diagrams to support Eric Elliot’s story. Aren’t these made up? I get mistrusty reading this. No surprise others call this a snakeoil salesman.
Now I have to add something positive. :wink: Javascript compared to typescript compared to reasonML:
https://medium.com/@johnhaley81/why-reasonml-part-1-8a975bbcf5f7

75

I’m trying an intro to react, Tutorial: Tic-Tac-Toe – React etc. I see “class”, “extends” and “this” used in one of the first code snippets (and am a bit disappointed ;-):

Here Kyle Simpson discusses ES6 classes etc. :

https://github.com/getify/You-Dont-Know-JS/blob/master/this%20%26%20object%20prototypes/apA.md

76

The awkwardness of classes in React is the reason behind the new React Hooks API. Check it out :wink:

1 Like
77

While I respect Kyle Simpson a lot, my general mantra is that personal opinions about certain things shouldn’t be taken as a rule. Even if he’s a professional developer, sometimes is good to have your own voice and make your personal choices based in your preferences, e.g. Kyle Simpson doesn’t like arrow functions, but I personally only declare a function with function when I need to use this, arrow functions provides a cleaner approach to my taste.

You can use React Hooks, which is a newer addition that provides a very concise way of writing your components if you don’t like classes. However, if you’re new to the library, it’s good to have a good understanding of how classes works in React, as the vast majority of legacy projects uses classes and people doesn’t want to rewrite all of the components with this modern API.

Not trying to add more contenders to the topic, but I’d like to highlight Stencil.js. It’s used to create modern web components with a clean syntax and a minimal API, I immediately fell in love with it, it also provides a pretty good developer experience. I’m building my own design system with it.

1 Like
78

I’m not much interested in opininions, and I did not post Kyle’s link to share them. I have been programming OO for many years in another languages where impementation inheritance and subtype polymorphism was (ab)used a lot. And I read criticism by Douglas Crockford concerning this and ES6 classes before. Simpson’s criticism is interesting I find. But thanks for the react hooks link! I’ll take a look at stencil.js.

1 Like
79

I have to read this over again also: https://dev.to/ben/why-the-react-community-is-missing-the-point-about-web-components-1ic3

1 Like
80

I suspect the precise numbers and and graphs are made up - in my experience or estimation would have been more genuine. I’ve noticed a tendency in presentations for these “made up” graphs to show up more and more - i.e. there is no hard data to back up the curve but it’s used a hypothesis visualization device - some presenters are up front about it I made this up - this is what I would expect the graph would look like (expectations often being false), others no so much.

Eric Elliot can be a bit of a blowhard - but as with everybody use your own judgement. It’s largely about exposing oneself to various points of view and after due consideration adopting or dismissing them based on their actual merits.

I still think that

Sean Grove - Finding joy in programming - Øredev 2017

is one of the more interesting ReasonML videos. It’s worth watching just for the warning against the allure of short “time-to-initial-success”.

I see “class”, “extends” and “this” used in one of the first code snippets (and am a bit disappointed ;-):

Hooks were only introduced in 16.8 (2019-Feb-06) but make it possible to use function components a lot more (to the point that some parts of the documentation have been updated to show class components as the secondary option). The tradeoff is that you are relying on the magic useState et al which couples them just as tightly as setState to React. However a lot of the tutorials haven’t been updated yet to predominantly use function components.

A React class component isn’t a class in the OO sense as its instance isn’t responsible for it’s own state - that is managed by the React runtime. Facebook’s documentation identifies React as a library:

A JavaScript library for building user interfaces

In my use of the term that is false.

  • my code calls library code
  • a framework calls my code

Once you get to ReactDOM.render your code is no longer in charge - React is. So given that most of the code you write is in fact called by React, React behaves like a framework.

The confusion at large seems to stem from the fact that people are imprecise with their use of the term “framework”

  • Angular and Vue are application frameworks
  • React is a view framework

So all of them are frameworks however they do not cover the same range of capabilities which can make comparing them difficult.

To get a better understanding of what your code is exactly responsible for inside React, I recommend React Components, Elements, and Instances.

Finally the JavaScript this has nothing to do with this in Java and the like. It’s the function context and it happens to be used to emulate class instances and methods.

  • this.method() seems annoying and verbose from a Java perspective but it’s simply accessing a function that is attached to the context that was passed to the current function.
  • By default functions do not have a context bound to it. However when a function is called via object.method() (method being a property on the object holding a reference to the function) then object is passed as the function context this.
  • Given that functions are often used for event callbacks it is often necessary to “fix” the function context to the function rather than it being passed by the caller.
this.methodEventListener = this.methodEventListener.bind(this)

i.e. the function reference stored at this.methodEventListener is replaced with a bound version of that function. This idiom is quite common in React and any JavaScript code dealing with event listeners.

Some React background:

3 Likes