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

General Prog (Archived)
, ,
81

I am not comparing javascript’s this to this in other languages (same for “class”). I only did that for the concepts of implementation inheritance & subtype polymorphism. I read Crockford’s critique (cannot find the text now, maybe it’s spoken out in “the good parts” https://vimeo.com/97419177) and agreed, mpj wrote https://gist.github.com/mpj/17d8d73275bca303e8d2 and there are lots of discussions like https://dev.to/ycmjason/is-this-in-javascript-bad--3bhc.

82

memory consumption

Crockford Classless is gorgeous, but there is one tradeoff: Performance [memory consumption]. Every object will be slightly more expensive than it’s prototypal equivalent. However, remember that premature optimization is the root of all evil.

Don’t pessimise prematurely

Similarly lots of JavaScript code creates anonymous functions unnecessarily. If the function doesn’t need access to anything inside the closure then a simple function definition inside the module scope will suffice. This has become even more prevalent with the introduction arrow functions (because they “look nicer” than fat functions).

Given that web components inherit from HTMLElement there is no getting away from needing to know the ins-and-outs of this in JavaScript or TypeScript. If you are going to interact with a browser API you need to deal with this sooner or later - pretending it doesn’t exist even the Crockford way will only get you so far.

Fat functions also have the benefit of being hoisted to the top - i.e. source order isn’t relevant. With arrow functions source order is relevant.

83

Does anyone know why the const arrow binding has become so common? In addition to what you mention:

function myFunction() {
  ...
}

Seems slightly cleaner than

const myFunction = () => {
  ...
};
84

Awesome! If you like TypeScript and JSX you’ll love it, it’s like a fusion of Angular + React. I think Stencil is a better solution than Polymer for web components.

Yes, but as long as you use ES6+ features you should transpile your code with Babel, so there’s nothing to worry about. Arrow functions have the advantage of implicit returns over fat functions too.

I think React.js popularized this pattern for declaring stateless components.

85

Shouldn’t the comparison be with LitElement?
Especially as Polymer’s design was likely influenced by the now deprecated v0 specs.

Reported (biased) comment by Polymer team lead Justin Fagnani:

LitElement is vanilla because it extends HTMLElement and you override the standard lifecycle methods like connectedCallback as necessary. StencilJS isn’t vanilla because the component class doesn’t extend HTMLElement and you don’t implement standard lifecycle callbacks, you implement compnentDidMount and such.

Babel is increasingly orienting itself via browserlist in order to minimize unnecessarily including polyfill which tends to penalize modern browsers. So more and more ES2015+ is actually being shipped to browsers as is, unless there is deliberate configuration to support downlevel browsers.

For more inclusive web solutions - interaction is an enhancement (Progressive Enhancement) - i.e. stay lean on the amount of JavaScript code to begin with, so that it doesn’t matter much if it is transpiled down to ES5 of lower.

1 Like
86

I like to compare Polymer as a whole, since you may sometimes want to use lit-html too.

Yes, but you can decide what you want to transpile. If you’re worried about hoisting, but you like to use arrow functions, just transpile your code with the @babel/plugin-transform-arrow-functions plugin.

Yesterday I’ve read a trend precisely about this (https://twitter.com/kyleshevlin/status/1116041620342730754), everybody complains about hoisting, but I wonder if someone has had real problems with it. I wouldn’t change my personal coding style because of problems that I’ve never faced.

87

The React contribution guidelines:

In particular, you should prefer named function declarations over const myFunction = () => ... arrows for top-level functions. However, you should use arrow functions where they provide a tangible improvement (such as preserving this context inside a component).

This seems to be also reflected in Dan Abramov’s more recent blog entries.

Aside: In I Don’t Hate Arrow Functions Kyle Simpson outlines why he published a new linting plugin to be able to more tightly lint arrow functions.

What I hate is suggesting they’re universally more readable, or that they’re objectively better in basically all cases.

From the Polymer Project landing page:

Polymer Library MAINTENANCE
Polymer Components MAINTENANCE

From the Polymer Library landing page:

Starting a new project? Try our next-gen products, headed for release in the coming months:

  • LitElement
  • PWA Starter Kit
  • Material Web Components

Polymer Library isn’t the whole, it’s the past. The impression I’m getting is that the team is embracing a leaner, much more modular approach.

I didn’t complain about it. I consider it a feature as it gives me more options on placement of the definition.

And in that tweet only one person complains about function hoisting while five others see it as a benefit.

88

I didn’t mean that the React.js team popularized or recommended that pattern, but a lot of the community resources and libraries use arrow functions; Reach UI, Material UI… Now with the hooks API, it seems like they are using less arrow functions.

My apologies, I wrote that message bad (not a native speaker as you may guess). What I wanted to say is that hoisting seems to be the main reason of why people use function instead of arrow functions, but how many of them had real problems related to hoisting by declaring arrow functions? It seems like a rule for non-reason. I mean, it’s totally fine, I don’t want to complain about other people’s code.

I agree with everything you said about Polymer, it changed a lot since version 2.

89

I use Phoenix to build out APIs and create-react-app build out clientside SPA’s.

React is the best, because you can easily bring in a Javascript engineer and he’ll get it. With Vue, you need a Vuejs person and you need to learn a bunch of Vue stuff. I’m not saying it’s a monumental effort, but it’s definitely more of a load than React.

We also use Mobx a lot for state management since I find the plumbing needed for Redux a bit much. It’s too much boilerplate, and you get what in return? Time-travel debugging and “state-in-state-out” functional paradigms? Eh, I get it - but I’m not buying it.

Here’s a simple example of how I use Mobx and React.

Here’s my store: https://github.com/sergiotapia/task-list-kata/blob/master/src/stores/Store.js

And here’s how I change stuff when I click on a Task for example: https://github.com/sergiotapia/task-list-kata/blob/master/src/components/Task/Task.js

Ezpz right? No fuss, no muss. Just rich in fiber, low-carb Javascript code. I like it simple.

90

Found an interesting read from 2016 pointing out react/elm/cyclejs differences

1 Like
91

For the last 2 months I’ve been prototyping my next app with elm, react, vue and “vanilla” javascript.

I really wish I listened to the people saying not to use elm. The initial promise of the language was too tempting to resist though, so I spent about 1 month creating the first version while learning the language at the same time. It is not a production ready language and if nothing changes it never will be.

The problems with elm started within the first minute. I opened the REPL and started playing and found an error with using “==” (an open issue for nearly a year now). I’ve hit compiler issues that got closed without a fix. It’s missing a huge chunk of expected web features/api with no updates about them. The documentation is severely lacking and littered with wrong or outdated information. What I experienced during that month was just sad. To finish it off it has the most unhealthy community of any language I’ve used so far. I’ve heard it jokingly referred to as a cult and honestly it’s not far off.

With the javascript options I had much better success. I’m normally a huge fan of vue for any frontend work but it had been a while since I looked at react or actually just used javascript without a framework so I made some more prototypes. With those three options I finished each in a few days with no issues at all and decided it’s probably fine to just stick with javascript/typescript for the frontend. I’m actually going the “vanilla” route because the framework apis are getting so bloated and convoluted that calling the right api at the right time is not much different than just dealing with DOM manipulation directly.

7 Likes
92

So you will prefer vanilla JavaScript. That’s great! Did you try ReasonML? I mean vanilla ReasonML without React?

1 Like
93

I have considered it and skimmed through the documentation and it does seem pretty nice. I initially looked at bucklescript-tea and ReasonReact as a replacement for elm because despite the bad experience, it introduced me to the ml style type system and I really liked it. The main reason why I haven’t yet though is that you fundamentally can’t escape JavaScript. I have the next week free so I intend to port my js prototype to reason to get a feel for the language and I’ll see where it goes from there.

3 Likes
94

TL;DR: Another data point in the “VDOM is underpowered” trend.

Rich Harris - Rethinking reactivity

Svelte 3 includes reactive declarations which ensure that values are recalculated whenever the inputs change - much like cells in a spreadsheet. Furthermore this reactivity isn’t realized via the use of a framework but through code generation by the Svelte compiler.

The resulting performance is sufficient for low power devices.

8 Likes
95

5 posts were split to a new topic: ReasonML/BuckleScript vs PureScript JS Interop

96

I’ve been playing with Svelte and Stencil these days and they work very well outputting a tiny and optimized bundle. While React.js and company are very popular and well-established, I’m starting to think about the Virtual DOM as an unnecessary evil, since we are paying a tax for using those kind of libraries.

Virtual DOM’s performance isn’t a problem (at least from a medium-size application perspective), however the truth is that we need to add new fancy tools to our workflow in order to speed up things on mobile devices. But desktop devices also suffer a lot when the application is huge, one example is the new Facebook, the engineers faced a lot of problems to get the new page working smoothly, it seems to be a SPA powered by React and Relay, here’s the video.

I don’t plan to abandon React, it’s a nice skill to have for getting job opportunities, but it’s also interesting to see how the Virtual DOM is hurting performance, also having to interact with the Virtual DOM is such a pain, e.g. using React along with another library to manipulate the DOM (like D3 for data visualization).

1 Like
97

React is going to be as tenacious as jQuery was, i.e. it isn’t going anywhere anytime soon.

One issue that I see is the React community’s “it’s just JavaScript” attitude - which doesn’t really encourage the acquisition of general browser-API-based skills and understanding how a browser (and the web) works (because the framework is supposed to abstract those details away).

Tom Dale proclaimed back in 2017 that Compilers are the New Frameworks (Disappearing Frameworks).

Ideally those compilers should use the browser platform as much a possible for performance reasons and there are opportunities to include WebAssembly modules for performance critical functionality not directly supported by the browser.

But in the end those compilers will fragment the frontend space just as much as the frameworks already have. Unlike for desktop applications, frontend compilers are going to have to be a lot more focused on the balancing act of DX vs. generated code volume vs. browser performance.

Keep Betting On JavaScript - Kyle Simpson

AssemblyScript - A TypeScript to WebAssembly compiler

2 Likes
98

I adopted React.js back in 2015 or so, because of the same statement; It’s just JavaScript. It turns out that’s kind of a problem because of styling, with CSS modules you may have class name collision problems, but at least everything loads smooth, however popular libraries for CSS-in-JS hurts your components render speed by a lot, and you’re limiting your components consumers to only use the same kind of libraries, no way to use CSS-in-JS on larger projects.

I think this may not be true, why? Ionic created Stencil precisely to avoid fragmenting the web and the work on its reusable components, you can use Angular, React, Vue… and render Stencil components within your application. I think being framework agnostic is beneficial in terms of creating a design system or a collection of reusable components.

It may not make sense learn both a framework and a compiler when you’re new to web development, but for those who already know a framework, should be beneficial to use a compiler for your custom elements and let’s say React to keep your data in sync.

Anyhow, web compilers will cover the “modern web requirements” for like the next 6 months or so, let’s see what happens when WebAssembly lands, even if it has good browser support, it really needs to get adopted by the community. Being a front end developer is both, exciting and exhausting, so much stuff to learn.

2 Likes
99

Too true. People are busy designing full-featured form-validation, click-detection, auto-complete libraries in React. They don’t stop to check modern browsers’ fantastic form management (FormData!), built-in native input widgets, and <datalist>. People jump straight to the conclusion that every little bit of their app state needs to be controlled by a central Redux store. It will inevitably be a big mess of JavaScript.

1 Like
100

Definitively Svelte.js is worth to take a closer look, at least if you plan to build JavaScript animations, the team is on fire!

https://twitter.com/Rich_Harris/status/1127930615033102337

1 Like