DEV Community

loading...

Are you really using JavaScript?

Seth Corker
My main focus is JavaScript specialising in frontend UI with React. I like to explore different frameworks and technologies in my spare time. Learning languages (programming and real life) is a blast.
・1 min read

I write a lot of JavaScript but very few lines of code make it to the end user unchanged. The code I write is statically type checked with flow. It’s transpiled into compatible ES2015 syntax by Babel. React components are transformed from JSX into JS.

Paddling a duct tape raft
Modern JS tooling can feel like paddling a makeshift raft, carefully patched together but gets the job done

I’m not alone, many developers rely on a lot of tooling to ensure the JS we write is readable and concise while the output is compatible and resilient.

With TypeScript, JSX and Babel, is it still JavaScript - would it matter what language you used if the output was JS?

Discussion (20)

Collapse
bradtaniguchi profile image
Brad

Its an interesting question no doubt, but I think the best answer is it shouldn't matter

Beyond the situation were the end user doesn't allow JS (gasp) the end user doesn't care what we used originally.

It could be TS, CoffeeScript, JS, JSX, Vue, Angular, React, etc. As long as the web page does what they want they are happy. That does matter. Make it faster, more stable, more reliable, and more consistent, and the end user will be happy.

Don't get caught up with the tools if it blurs the actual goal 😄

Collapse
darthknoppix profile image
Seth Corker Author

All great points! There are many different technologies we use to build the web and I think WebAssembly will bring even more languages to the web.

From the end user’s perspective, the web page is displayed and their experience is good and the developers experience may be improved.

Do you think it could have a negative impact on how developer accessible JS is?

I remember my fascination with JS in the beginning was because you could see the source (like HTML and CSS) and play around with it.

Collapse
bradtaniguchi profile image
Brad

Do you think it could have a negative impact on how developer accessible JS is?

If you mean do I think "using 'high-level' JavaScript tools(TS, Babel, JSX etc), has a negative impact on end user experience"

I'd say yes in terms of performance, but no for other things like consistency. So overall it depends.

The more JS we shove down to the end-user, the slower it will be to load the page. It might not matter as much as it did back at the start of the web, but it does matter. This trade off might be ok, if the target audience has a decent internet connect, utilizes modern browsers, and the code utilizes what it can to improve user experience, (PWA features for example) then the overall gain of utilizing client-side code will be worth it in the end.

In a perfect world you have a tiny SPA, that can expand based upon the user's needs, while staying as slim as possible, all while providing an excellent, smooth, accessible end-user experience. I'm not saying this is easy, or practical for all cases. But it is the goal, and should stay the goal.

Don't use Babel/JSX if it doesn't give the end user consistency. Don't write vanillaJS if it means your code ends up a mess. Don't write JS just because you want to write JS. Some situations just don't need an SPA app with all the bells and whistles.

Collapse
deciduously profile image
Ben Lovy • Edited

You can write all kinds of things instead of JavaScript:

Whether or not you should and when is a pretty complicated matter, but many of the above choices do introduce clear benefits like type safety and property-checking at the language level or powerful new paradigms like Clojure's transnational memory system or Idris's dependent types, even when what's executed at the end is plain old ES5 JavaScript. Not all projects fit this bill, but many do.

To me, using TypeScript/ESnext+ JS is a very similar thing to using a different programming language entirely - introducing a more helpful environment for the programmer without compromising on the interface with the platform.

Collapse
darthknoppix profile image
Seth Corker Author

Great list, there are some languages I didn’t know could compile to JS, I’ll have to try them out!

Have you used any of these in the past (sounds like you’ve used Clojure) and what were challenges involved with using another language instead of JS?

Collapse
deciduously profile image
Ben Lovy

I've used Clojure, Elm, PureScript, and OCaml from this list, and have Smalltalk on my "to-try" list.

The issues with using each choice are largely unique to that choice, but what you sacrifice by leaving vanilla JS is the ecosystem and support. You severely limit the resources available for troubleshooting, and I often ended up needing to adapt a resource I found to solve a problem in a different language. If the time you spend doing that sort of work is greater than the time saved by using a superior tool, the whole thing isn't worth it anymore.

I'd say for side projects these make a lot of sense, but it'd be a hard sell for a CTO.

Thread Thread
darthknoppix profile image
Seth Corker Author

Great insight, looks like you’ve experimented a lot. The ecosystem is a big plus for JS right now.

I guess it always comes down to:

I'd say for side projects these make a lot of sense, but it'd be a hard sell for a CTO.

Thread Thread
deciduously profile image
Ben Lovy

I actually forgot to mention one of the more robust solutions - I think Fable for F# as part of the SAFE stack may be a viable contender, along with ClojureScript, for an enterprise-grade solution. Those two stand out to me as the most generally useful options, here's hoping that maturity continues to increase.

Thread Thread
darthknoppix profile image
Seth Corker Author

I’ve played around with F# but I haven’t properly tried the SAFE stack. That might be a good weekend project to try.

Thread Thread
deciduously profile image
Ben Lovy • Edited

I haven't spent a ton of time with it either, but the demo "dojo" project they have set up is really well done and shows you all the moving parts. I'm impressed with the polish of pretty much all the F# resources I've come across.

Collapse
sneakycrow profile image
Zachary E. Sohovich

My thinking on it is that JS is just becoming a tooling system. Which is fine. You don't see people programming in machine language anymore. They work in systems language that compile down to machine language.

JS is just, in my eyes, following suit of other langs.

Although, recently, I did work on a PHP site that used a single JS file with no tooling or "addons", and that felt super weird! Haha

Collapse
darthknoppix profile image
Seth Corker Author

A great point!

It’s interesting that there now exists a spectrum between plain JS, heavy tooling and completely different languages.

I can imagine it’s jarring using plain JS again!

Collapse
almadireddy profile image
Al Madireddy

This is an interesting conversation to have, never looked at it that way before really.

Maybe we have so much abstraction away from what ends up reaching the user because of how easy it is to feel "unsafe" writing javascript?

The biggest thing I'm thinking of whenever I'm using these tools is that at least there are fallbacks to deal with older browsers and other contingencies that I would otherwise have to worry about doing correctly.

Collapse
darthknoppix profile image
Seth Corker Author

Abstraction is definitely part of it, making JS more ergonomic for developers.

I’m also very invested in tooling for dealing with things like polyfills for older browsers and CSS vendor specific prefixes.

Collapse
codelitically_incorrect profile image
codelitically_incorrect

It does matter imo.

Collapse
darthknoppix profile image
Seth Corker Author • Edited

I have used some source to source compilers in the past to write JS but they come with their own set of challenges. I’m interested in where developers make the switch from plain JS to tooling and even to other languages.

Why do you think it’s better to stick with JS with tooling over alternatives?

Collapse
codelitically_incorrect profile image
codelitically_incorrect

"..free from anything of a different, inferior, or contaminating kind; free from extraneous matter: pure gold; pure water. unmodified by an admixture; simple or homogeneous."

Thread Thread
darthknoppix profile image
Seth Corker Author

Okay, I take your quote to mean that writing plain JS is optimal because it is free from unnecessary indirection, abstraction and additional build steps. You’re writing JS because that’s what the browser expects and there is less distance between source and output.

Collapse
jacobherrington profile image
Jacob Herrington (he/him)

This is a really interesting question. I think this has motivated some projects like Opal.

Now, I'm not sure it's the best idea, but it is interesting!

Collapse
darthknoppix profile image
Seth Corker Author

Do you/have you used Opal in the past? What is the biggest challenge you had using it over JavaScript?