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

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

1 Like

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

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

1 Like

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

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

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

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

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

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

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

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

Thank you so much for those links, I think I’m in love! I like VueJS but what this guy did with Svelte looks way better. I had never heard of it before, but I am set on trying it out in my next project!

1 Like

https://medium.com/better-programming/the-real-cost-of-ui-components-6d2da4aba205

By the author of Solid - The Deceptively Simple User Interface Library

3 Likes

Sorry but iPhones exist.

Yes, they do. Can you elaborate how exactly their existence is affected by or does affect the quoted statement? I have problems following you, as I neither do web development, nor have an iPhone.

2 Likes

Show me tutorial/proof of concept, how that shortcut to website on home screen on iPhone can use notifications. Or can execute in background. Or use any API like Bluetooth.

Everything you wrote about PWAs doesn’t work on an iPhone and PWAs are useless if you want to support iPhone.

I did not write anything about PWA…

2 Likes

Sorry, wrong user.

Anyways, he wrote that PWAs can use notifications API. On iPhone PWAs cannot.
He also wrote that PWAs “can use other APIs like installed apps”. On iPhone PWAs can use standard browser APIs - location, etc. On iPhone PWAs cannot access iOS APIs - no authentication (face id or touch id), no bluetooth, no payments api, nothing. PWAs also cannot do any background work, unlike installed apps.

It’s pretty common knowledge, yet there he is spewing bullshit about how PWAs are real applications, when on iPhones they are nothing but bookmark shortcuts on home screen.

But a few of those are web API’s though?

  • Notifications - web-notifications standard
  • Authentication - WebAuthn standard (which I think apple even helped create, and yes can use face id and/or touch id or whatever the device exposes)
  • Bluetooth - web-bluetooth standard
  • Payments - web-payments development spec, not finalized yet but already supported by a variety of browsers.
  • Background - Can sync data to keep it up to date, though actual runtime to perform processing is purposefully limited as that could be easily abused (even by native apps, most phones have things to prevent that now).

My phone supports all of these, if an iPhone doesn’t but you need it, then perhaps get a better phone?

But yeah, PWA’s are not ‘native’ applications, though they are still applications. I’m personally not a fan of them as they don’t feel or respond as well or as natively as a native app though.

1 Like

I’m unsure what this is asking? I’ve worked in various parts of the programming industry for 25 years, including teaching?

EDIT: I see post was edited with more, and it now appears obvious that you are attempting to troll, so not responding any further.

1 Like