DEV Community

Discussion on: 3 Common Misconceptions about JSX

Collapse
 
johnmunsch profile image
John Munsch

While those are probably good misconceptions to talk about, my complaints about JSX center more about what it forces you to do and how it impacts the code:

  1. JSX ties you to forever needing to run your code through some form of compile/transpile cycle. At this point in time, every browser supports ES6/7/8/etc. and supports Web Components. Thus the need for the build cycles we've had in the past has declined to the point where it's an antipattern rather than something we want to keep doing. But JSX isn't JavaScript so as long as you use it, you're always going to have to have that extra step in your development cycle even if you really don't need it.
    And it's not like React + JSX is a more performant solution than the alternatives to make up for it. In actuality, it's slower and more poorly supported. Web Components perform better on mobile browsers (they're not written in JS, they're written into the browser itself and much faster) and on the desktop too (see github.com/krausest/js-framework-b... and trim down the frameworks to something managable like lit-html, litelement, react, angular, and a few other of your favorites). You'll likely find that the lit based ones are the fastest, use the least memory, etc.).

  2. JSX is technically a templating language so it's not truly tied to React, but that's kind of like how React "isn't tied to JSX". Yeah, you can use React without using JSX. Do you know anybody doing that? No? I didn't think so. But is React in general doing things we actually need done anymore? React is giving us a component model. It's not one supported directly by the browser, it's one which doesn't make use of the Shadow DOM (you can add on CSS-in-JS solutions, but those are not the same), and including a new component is hardly as easy as including a JS file and just typing in the HTML.
    So why do we need it? Why include something that makes us have a build in our development cycle and is slower to boot? If you are actually doing server-side rendering, sure, I salute you for doing that and you've got something that is not well supported in Web Components today. Otherwise? Ask yourself why you're signing up for this.

Collapse
 
geocine profile image
Aivan Monceller • Edited

I actually agree with your points here that's why these things are not listed as misconceptions.

JSX ties you to forever needing to run your code through some form of compile/transpile cycle

You can actually say this about TypeScript as well and other toolings that actually require a build. I don't have a strong opinion about this. We can either innovate towards making tooling drop the requirement of builds altogether or we can just make it faster.

esbuild is 100x faster when compared to webpack and rollup

GitHub logo evanw / esbuild

An extremely fast JavaScript bundler and minifier

esbuild

This is a JavaScript bundler and minifier. It packages up JavaScript and TypeScript code for distribution on the web.

Why?

Why build another JavaScript build tool? The current build tools for the web are at least an order of magnitude slower than they should be. I'm hoping that this project serves as an "existence proof" that our JavaScript tooling can be much, much faster.

Benchmarks

The use case I have in mind is packaging a large codebase for production. This includes minifying the code, which reduces network transfer time, and producing source maps, which are important for debugging errors in production. Ideally the build tool should also build quickly without having to warm up a cache first.

I currently have two benchmarks that I'm using to measure esbuild performance. For these benchmarks, esbuild is at least 100x faster than the other JavaScript bundlers I tested:

Here are the details…

Personally, this is a demo project I created which showcases the use of web components, hooks, css-in-js, context, routing without any build step:

GitHub logo geocine / web-components-hooks-demo

web components hooks demo

Web Components + Hooks Demo

This demonstrates a basic shopping cart built using Web Components. It also has State Management, Routing, CSS-in-JS and does not need a build step.


Technologies used:

Usage

This demo runs without a build step.

Development

Just run on a webserver with index.html as a fallback page. I suggest using lite-server on root directory. The yarn start script uses lite-server.

yarn
yarn start

If you are serving this on a different host:port make sure to replace all instances of

http://localhost:3000

I am also not entirely naive about Web Components. I have created a compiler to enable you to create native custom elements using Typescript

GitHub logo geocine / custom-elements-ts

Create native custom elements using Typescript

custom-elements-ts

Coverage Status Build Status npm version License: MIT

Create native custom elements using Typescript without using any third party libraries.

npm install custom-elements-ts

Usage

import { CustomElement } from 'custom-elements-ts';
@CustomElement({
  tag: 'counter-element',
  templateUrl: 'counter-element.html',
  styleUrl: 'counter-element.scss'
})
export class CounterElement extends HTMLElement {
  // code as you would when creating a native HTMLElement
  // full source code is at demo/counter
}
<!--index.html-->
<counter-element></counter-element>
<script src="counter.umd.js"></script>

Decorators

Decorator Target Parameters Description
@Prop() property - custom attribute/properties, reflects primitive properties to attributes
@Toggle() property - boolean attribute/properties, it is based on the presence of the attribute but also works with "true" and "false"
@Dispatch() property (event?) used to declare a CustomEvent which you could dispatch using the .emit method of its type DispatchEmitter. The event parameter is used to set the name of the

I think it is dangerous to be married against one side of the camp. Ionic is one of the companies I know that heavily promotes Web Components. They actually created a compiler which would help them build Web Components efficiently as compared to the "low level API" that custom elements provides. Hence, StencilJS was born.

Stencil combines the best concepts of the most popular frontend frameworks into a compile-time rather than run-time tool. It takes TypeScript, JSX, a tiny virtual DOM layer, efficient one-way data binding, an asynchronous rendering pipeline (similar to React Fiber), and lazy-loading out of the box, and generates 100% standards-based Web Components that run on both modern browsers and legacy browsers back to Internet Explorer 11.

GitHub logo ionic-team / stencil

A Web Component compiler for building fast, reusable UI components and Progressive Web Apps 💎 Built by the Ionic Framework team

npm Build & Test license

Stencil: A Compiler for Web Components and PWAs

npm init stencil

Stencil is a simple compiler for generating Web Components and progressive web apps (PWA). Stencil was built by the Ionic Framework team for its next generation of performant mobile and desktop Web Components.

Stencil combines the best concepts of the most popular frontend frameworks into a compile-time rather than run-time tool. It takes TypeScript, JSX, a tiny virtual DOM layer, efficient one-way data binding, an asynchronous rendering pipeline (similar to React Fiber), and lazy-loading out of the box, and generates 100% standards-based Web Components that run on both modern browsers and legacy browsers back to Internet Explorer 11.

Stencil components are just Web Components, so they work in any major framework or with no framework at all. In many cases, Stencil can be used as a drop in replacement for traditional frontend frameworks given the capabilities now available in…

Ionic first focused on Angular but later realized that they should allow the use of Ionic no matter your preferred framework. They actually never took the stance against any type of framework. I think that is the same stand that I will take. You should use a technology that works for you and brings value to your business. Just like Ionic Angular, there is now the React and Vue versions, Ionic Vue and Ionic React and soon more resources and guides are going to be available to work with them. This was made possible with Web Components and the best things they learned out of the other frameworks. To me using any framework is not really an all or nothing.

Collapse
 
johnmunsch profile image
John Munsch

I'll learn more about esbuild, I'm not familiar with it. You make an excellent point about looking at it from multiple standpoints though. There's the speed aspect of it, "If it were just fast enough not to impede my development cycle would I then care about whether there is a build step or not?"

And I think that for me the answer is, "Yes, kinda..." It's because I've done videos for commercial courses and for YouTube before as well as mentoring some at work and I think that we need to realize there are costs associated with build tools like webpack and Gulp beyond just speed. They become just another speed bump for people who want to develop but get to start with tooling instead. Alternatively they can simply adopt a "CLI" which rolls up a lot of stuff into a huge blob that you can hope never breaks and you never run off the edge of. There is really something to be said for simplicity sometimes.

However with that said, I've used custom elements with only Vanilla JS and then built the exact same components with LitElement (a small amount of additional code to handle templates, attributes, etc.) and I can say I greatly prefer the latter. Stencil, SkateJS, etc. are all just doing variations of that same thing. In fact I really like that variety and I like that JSX is one of those options because it will make a much easier transition for some developers in the future. So sometimes you can absolutely simplify and cut away too much.

Thread Thread
 
geocine profile image
Aivan Monceller • Edited

They become just another speed bump for people who want to develop but get to start with tooling instead.

I agree with this 100% , I haven't done any professional kind of teaching but I love helping others get into web development. This is really a pain, I miss the days where we can just add a script tag and that's it. I think by default libraries/framework must at least provide this option to reduce the technical barrier of learning introduced by build tools. I am glad that the JavaScript community is seeing this a legit problem to solve. Now we have things like ParcelJS and Snowpack. Still it would be a chore to explain why do we even need these, why do we even need to install NodeJS etc.

However with that said, I've used custom elements with only Vanilla JS and then built the exact same components with LitElement (a small amount of additional code to handle templates, attributes, etc.) and I can say I greatly prefer the latter.

I personally prefer DOM events as compared to React's Synthetic events. I think right now though, Web Components are good enough when you are developing the individual components of the application. But If you need to create an entire application with templating, state management, routing , definitely need some help from our other friends on top of the VanillaJS Web Components.