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...
For further actions, you may consider blocking this person and/or reporting abuse
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 😄
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.
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.
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.
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?
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.
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 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.
I’ve played around with F# but I haven’t properly tried the SAFE stack. That might be a good weekend project to try.
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.
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
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!
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.
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.
It does matter imo.
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?
"..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."
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.
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!
Do you/have you used Opal in the past? What is the biggest challenge you had using it over JavaScript?