The melting pot of JavaScript (2017)

https://increment.com/development/the-melting-pot-of-javascript/

by lewisflude • 8 years ago

153 194 8 years ago

lewisjoe5• 8 years ago

I just wrote a proposal for my team today as to how the front-end tooling has changed recently and why we'd need to adopt them in our workflow.

https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c...

With confidential details masked, it's still a pretty good read for the rest of the Internet. Outlines why JS fatigue is not really bad but just improvements and what exactly is stopping us from adopting those improvements.

Resonates a lot with Dan's write-up. Excellent piece by Dan. A much needed one. I'd probably link this along in my proposal.

Note: We've built a pretty fat browser app with plain vanilla JS, strictly ES5 only, crude bash scripts for building a bundled js & all such ancient methods.

savanaly• 8 years ago

Note: We've built a pretty fat browser app with plain vanilla JS, strictly ES5 only, crude bash scripts for building a bundled js & all such ancient methods.

Jeez, man, I'm all for minimal tooling too. But ES6 is the lowest hanging fruit there is, I beg you to consider adding a transpile step to your build on your next project so you can use it!

lewisjoe5• 8 years ago

The problem though was Webpack was generating massive bundles (probably something to do with the polyfills needed for different browsers). We were able to achieve much smaller bundles by just sticking to ES5 features supported by the browsers we support.

Oh, and code splitting was out of the question. Most modules were attaching themselves to the global namespace (note: a large portion of the app was built even before requireJS was a thing). Which means code-splitting is a developer discipline category, not an automated one.

We have slowly started improving these things though. As I've mentioned in the document, the benefits are beginning to far outweigh the cost now, so yeah we'll move to ES6 soon.

tuesdayrain2• 8 years ago

Es5 only? Jeez that would be an immediate dealbreaker for me with any potential employers.

lewisjoe5• 8 years ago

Well, for those of us from the 2000s era of web dev ES5 wasn't such a deal breaker. It isn't very concise, but ES5 isn't so bad either.

ES5 to ES6 isn't what Java is to Python. It's more like what Python 2 is to Python 3.

perfunctory• 8 years ago

Really curious what is actually wrong with "crude bash scripts for building"?

I had experience with both types of projects - the ones with home made crude build tools (in Python, not bash), and the ones with modern javascript build pipelines. The first build never broke. The second build would break every couple of months for no obvious reason without us touching the project structure.

lewisjoe5• 8 years ago

There's nothing wrong with handwritten scripts. The lack of problems are exactly why the current dev workflow has scaled and I'm saying this as of 2019, which I find interesting!

The problem is opportunity cost. The rest of the tools in the market (Webpack, Rollup) are offering heavier benefits like automatic code splitting, dead code elimination and such things.

gedy2• 8 years ago

Maintenance. Because seems they are usually written/owned/optimized by some build brainiac that becomes a bottleneck or leaves at some point.

sam0x173• 8 years ago

At Blockvue we have also had a lot of success going back to basics with vanilla js. Doing a large SPA in vanilla js is actually a charm these days and the result is extremely lightweight and fast. The SPA concept is sort of new, but if you really commit to not doing any server side page generation the result is so easy to manage. This also allows us to focus on having a fast crystal-based API backend to power our SPA and other services. We use a script to minify and deploy directly to s3/cloudfront, and then use lambda and some microservices for API endpoints. The turning point for me on this issue was when I realized that Google has been indexing dynamic js content since 2012 (I had no idea).

mattmanser• 8 years ago

I'm still firmly of the opinion that nobody wants a SPA apart from the developers of that app.

I'd bet any of us could find a ton of weird and unintuitive things your app does, as well as it probably being slow to load, hard to use and brittle, in that you'll regularly put out an update that inexplicably breaks something for a day or two.

Add on top that massive extra expense of doing a pure SPA compared to the ease and simplicity of developing a mixed server/front side app, I have no idea why anyone sane ever signs off on a SPA.

And that's before we even get onto the vastly better tooling and development environments that server-side languages have.

DLA2• 8 years ago

Dan Abramov wrote a brilliant post here, IMO. So much here. Unix Philosophy, yes please. Considering the cognitive load of tool options and configuration knobs, and the impact of the JS ecosystem for beginners. "A tool should work with (almost) no configuration." Amen. "Mind your output" from tools (errors must be helpful and sort the important from the unimportant); I've felt this pain and have abandoned tools at the start because of incomprehensible errors. Love the idea of toolboxes w/r/t dependencies. Read the post for the details. Great work Dan!

undersheet9• 8 years ago

cognitive load of tool options

First time I hear options are bad. Many options and competition lead to best products. There are enough posts and people who tell you what you should use.

Or just use npmtrends or npmcharts. 1 second later you know what is going on and what module you should pick.

Why are people criticizing something they have never used?

fwip• 8 years ago

Just to be clear - you don't think the author has ever used a tool with too many configuration options?

DLA2• 8 years ago

My point here on this one is simply that it's investing to think about this factor. For beginners (which I am not), too many options can be confusing. That said, setting reasonable defaults for detail options so things work well without needing to configure then to start is a nice way around this. Deep options exist and can be adjusted as needed but a solid default configuration is set out of the box. "There are enough posts and people who tell you what you should use." -- sure but what if opinions very widely? There's the cognitive load or put another way friction-to-first-use.

vinceguidry• 8 years ago

I welcome the slow transformation of Javascript into Ruby. Every single thing in there is already a thing in the Ruby ecosystem. Convention over configuration. The careful, but automatic dependency management. Principle of least surprise.

All things I didn't know how much I relied on until I moved to NodeJS and found them non-existent.

humbleMouse• 8 years ago

What you said could be true of Java or any other modern server languagae.

zach43• 8 years ago

I personally think that the JavaScript community is doing a great job with its tooling and approach. Compared to other language environments I’ve worked with (C, C++, Python), most common JS tools work in predictable, user-friendly ways...also they frequently have good documentation and “getting started” tutorials.

It is good to see that the community is open to introspecting and improving even further

simion3142• 8 years ago

also they frequently have good documentation and “getting started” tutorials.

I tried making a TypeScript react app around Christmas, I found a tutorial, the commands did not work, I do not remember the details but it was using some bundler and probably the tutorial was a bit old and packages updated in npm. I found a different tutorial, to use create_react_app,

I seen it uses npx(not sure when this tool appeared) it also used tons of dependencies, in the end I created my app from scratch using only the TS compiler package and the react client library, no extra tools, magic, 1 month old tutorials that are outdated already, no install latest tool of the month etc.

gedy2• 8 years ago

npx create-react-app my-ts-app --typescript takes about 30 seconds from command to running app.

Maybe the issue people have is there is no 'js-lang.org' with one tutorial site and getting started. It's a huge community, so of course random blog posts will be a mixed bag of quality.

mr_toad• 8 years ago

I found a tutorial, the commands did not work

That’s hardly unique to Javascript. Back before the internet even existed I’d seen out of date make files which did nothing but spit out linker errors due to API changes in libraries.

hrabago• 8 years ago

Ten years ago, JavaScript was my go to when I wanted to expose others to coding. It still is today, but now that comes with the caveat that the most popular libraries and framework require a significant amount of prior knowledge to understand and to start using.

I haven't done this exercise in a long while, but the last time I tried to start a project from the "most current and stable releases and recommendations", I ended up not being able to get anything running. In the end, I had several hundred megabytes of libraries downloaded, a complicated configuration, and a non-working application.

Today, there are toolsets to get you started with everything and produce a running application, but it's almost totally opaque. I'm afraid to use them because the first time something breaks, I don't know if I would be able to resolve the issue.

I would still rather have a decent understanding of how things connect.

SketchySeaBeast• 8 years ago

That was my biggest eyeopener when I started using React - the piece I know just the tippy top of the iceberg. While that's true with a lot of languages (it's not as though I know what's going on with the whole .NET stack) it seemed especially egregious. I had a site up and running quickly, but it pretty much entirely magic.

Do you teach JavaScript first just because of how fast it is to get it up and running (ie. "Just open your web browser")? If I remember correctly it was much more vexing than a lot of compiled / strongly typed languages as the errors in those languages came sooner. In JavaScript there have been times where it loads and runs, but nothing happens, and I had no idea why, which proved frustrating.

kibwen• 8 years ago

JavaScript is still what I use to introduce programming to new people, because for people who haven't done their dues learning how to use a command-line, the hardest part of getting started with programming is getting your computer set up to do it at all. And since everyone already has a browser, getting started with coding only requires showing them how to open the developer console.

undersheet9• 8 years ago

I disagree. Assume you are an average coder, you should have a clue of basic JS:

1 week to learn JS latest language features

1 week to grok node, npm and the power of the JS object

1 week for React, basic stuff not redux

1 more week to dabble around

4 weeks and you should be able to be productive JS with its most important flavors. Tell me any other ecosystem where you are that fast.

_hardwaregeek7• 8 years ago

Very nice points here. I've always been struck at how the JavaScript community never really adopted the Rails ideas of convention over configuration and optimizing for developer happiness. While it's easy to roll one's eyes at the marketing lingo, these principles do truly make Rails a charm to use. Right now, even setting up the most simple Webpack-Babel-Node config requires writing a whole lot of config and set up for very little gain.

lewisjoe5• 8 years ago

Rails (or Python or Java) doesn't really fit into the problem set that JS has to go through. Most softwares written in those tech stay in the server with no need of transpiling, no need of code splitting when built, no need to be sent over the wire, etc.

While I agree the package management in JS could have been better, most other too-much-config problem is just because of the variety of problems and the variety of potential solutions.

_hardwaregeek7• 8 years ago

I'm not so sure about that. While there are a lot of complicated situations for JS dev, there's also a lot of similar patterns. I'm not saying we need to ignore the various complexities involved in JS dev, but we should make the general patterns easier to solve. Yes, of course transpilation can have all these different edge cases. But we should be able to have some preset modes that can do 90% of the work automatically. Like it baffles the mind that I still need to tell webpack that JSX files should be loaded by babel.

And anyways, there's the entire backend JS ecosystem, which is extremely behind Rails in developer ergonomics. I can spin up a REST API in Rails in half the time it takes to connect Node to a database.

undersheet9• 8 years ago

In JS there is a lot of convention but on a micro level. The times of monolithic Rails apps which have strict conventions are over and it's good: Too much magic and strict conventions often forced devs into patterns which didn't match the use case. Even experienced Rails devs tried to solve every problem the same way.

You also confusing matters. You need Webpack, Babel etc for the frontend not the backend. And even in the frontend it got abstracted away by things like creat-react-app. So you shouldn't them see them too often.

_hardwaregeek7• 8 years ago

First, Webpack and Babel are totally used for backend. If you look at a lot of Node libraries, they use ES6 modules in their [docs](https://github.com/graphql/graphql-js). While you could use mjs for this, it's still experimental.

I do think create-react-app is a good innovation in the JS world. However, I've never found a good equivalent on the back end. Setting up even the most basic CRUD REST API requires a whole lot of typing for very little reward.

As for convention, I think JS could do with more of it. I find that when I talk about adding more convention, people take it quite literally as "we need to reinvent Rails in JS". That's not at all what I mean. Convention can be something as simple as Rack, which is a consistent, useful interface between servers. Convention does not and is not tied to monoliths or MVC or any other aspect of Rails.

matchbok• 8 years ago

Simply not true. Rails continues to be the choice for many companies who don't base tech choices on what the latest bandwagon is.

JS is mess.

tuesdayrain2• 8 years ago

Gatsby is pretty much a superior version of ruby on rails in my experience. I don't remember the last time I had to touch webpack.

soneca2• 8 years ago

Ember is exactly that. I love it and use it on my day job and on my side-project. But overall it doesn't have much adoption and no perspective to grow anymore.

_hardwaregeek7• 8 years ago

I've wanted to use Ember, but I've never bothered to sit down and learn it. What ever happened to Glimmer? I remember it being hyped up as a crazy fast virtual DOM, but I haven't heard anything recently.

h1d• 8 years ago

Rails is so much into its own world I hate it. Glad JS is developing in different ways. Try parcel bundled, it's zero config yet it doesn't invent its own world to freak newcomers.

w4tson• 8 years ago

Is it unfair to say that some of these problems are caused by a lack of awareness (or an unwillingness) to learn from other communities (like, Ruby, Java etc) that have solved these some of these problems already?

oaiey3• 8 years ago

No. And that is also why JS is successful. Newbies with little oversight create new tools. Of thousands of them, one or two become popular because of non-functional reasons (right blog post, right fit, easy use, ..).

Welcome to the mess :)

jskaggz• 8 years ago

Tech pop-culture... Navigating these technology growth explosions is like searching for solid reference architecture in a booming shantytown. Some parts of these settlements eventually get things like running water, working sewage, urban planning.

spricket15• 8 years ago

I really like the kind of sanity that TypeScript brings to JS, super well designed and usually a pleasure to work with. That said, I've worked in many languages and I can't see any reason you would willing write your backend in JS or TypeScript.

Java, C#, Rails, and to some extent Python are much saner choices. The massive churn of the JS ecosystem bleeds through to the backend, hard.

JS could use a little more of the cruft and process that makes Java and C# especially so "uninteresting".

Java especially is kind of a joy to work in if you ignore the cruft. Everything is generally well documented, the libraries are mostly very solid, code is almost always backwards compatible, there isn't a zillion ways to do everything, frameworks tend to live for a decade or so.

And it's faster than JS, and uses way less memory, and mostly solved dependency hell and bloat over a decade ago.

Java feels like it was designed, not grown. Everything follows similar convention so it's easy to pick up new libraries. The advantages are many. The drawbacks are few as long as you use things like Lombok and code generation liberally. By the way; code generation using agents, annotation processors, and bytecode manipulation is pretty much standard and a godsend for doing interesting things (and getting around the cruft) .

In java, I can write code on the fly at runtime, or even during compile time using standard tools. Js barely even supports reflection. This is a huge underrated shortcoming of js if you're doing anything complicated

pwaivers• 8 years ago

Since JavaScript is a prototype language, doesn't reflection come in automatically?

MarsAscendant2• 8 years ago

Not for most coders, unfortunately.

spricket15• 8 years ago

Bad/non-existent annotation support prevents you attaching metadata to objects without adding garbage to their structures. Makes reflection a lot less useful

undersheet9• 8 years ago

Java, C#, Rails, and to some extent Python are much saner choices.

Python not as scalable, Rails is stagnating, the ecosystem doesn't evolve anymore/dying, doesn't play well with SPAs, C# weak to none ecosystem outside of Windows and devs earn a fraction, Java verbose and dev productivity subpar (there was a reason people came up with Scala), Java devs also suffer lower salaries

spricket15• 8 years ago

I agree about critiques for most of those languages but not java.

If you reach out to the Java ecosystem you can find libraries, frameworks, and language extensions that make it relatively easy to code in. For example, with Lombok you don't have to write any getters and setters, or catch checked exceptions. Java 11 also makes good improvements to lamdas making method chaining a lot nicer. The Java I write at work is barely more verbose than the TypeScript, maybe 15% more code to do the same thing.

Java devs also get paid really well honestly, pretty sure it's better than the pay for JS and Python actually.

optimuspaul• 8 years ago

Python not as scalable

Not scalable in what way? Every aspect of scalable that I can think of is in no way limited by choosing python as your language.

cmwoodall• 8 years ago

"Rails... ...doesn't play well with SPAs"

Huh? Rails ships with built-in, no-config webpack support (https://github.com/rails/webpacker#installation) as well as install tasks for the most-popular front-end solutions (https://github.com/rails/webpacker#integrations)

orangeeater2• 8 years ago

Js barely even supports reflection. This is a huge underrated shortcoming of js if you're doing anything complicated

Can you explain what Java offers with regard to reflection that JS doesn't?

My feeling is that reflection is almost moot in JS since you can inspect/mutate objects at runtime however you like. But maybe I'm missing the point of reflection.

There is a Reflect object with a bunch of static methods on it in ES6. It mostly just replicates functonality that already exists in the language, and my suspicion is that it's mainly there so it can be extended at a later date without breaking backwards compatiblity.

spricket15• 8 years ago

Java uses reflection and annotations to support all kinds of language extensions. Js has a lot of nasty issues with the "prototype chain" and annotation support is still experimental. For example, in java, scanning your classes and their annotations to generate code for them at compile time is a standardized feature.

Maybe I'm just complaining that JS is too dynamic, but being able to generate code at compile time with reflection and know it will generally work (type checked) is nice.

orf3• 8 years ago

Can you explain what Java offers with regard to reflection that JS doesn't?

Among hundreds of other things, getting the return type of a method and getting the input parameter names (+ types) in a way that doesn't revolve around literally parsing the functions toString() representation.

Oh, and typeof checking that isn't disgustingly broken.

snek• 8 years ago

Just to be clear, Reflect exists to be direct interface to JS's Module Object Protocol (MOP). Every "primitive" operation you can perform on an object in js, (such as adding a property or getting the value of a property), is exposed via Reflect.

chii• 8 years ago

There's no easy way to inspect the runtime in js to find all functions or all classes that can be loaded/called.

There's no way to hook into the loading of modules in a standard way - you have to know how the modules are compiled and required.

hombre_fatal2• 8 years ago

One example would be a url router for a web server that turns the url variables into the handler's expected argument type and ignores requests that do not.

    router.get('/users/:id', (id: UUID) => ...)
    router.get('/products/:id', (id: Int) => ...)

est• 8 years ago

Can you explain what Java offers with regard to reflection that JS doesn't?

One thing comes to mind, how to twinkle stuff inside closures?

bryanrasmussen3• 8 years ago

JS or anything that compiles well to JS has a backend advantage that can be hard to beat for an early stage startup and that is reducing the amount of context switching you have to do in changing between languages (especially if your code is isomorphic).

At least, that is how I find it, my productivity shoots up when I don't have to be moving between two imperative languages that most likely share a lot of their syntactical DNA with C but each have their own fun little differences.

spricket15• 8 years ago

I find it's not an issue as long as you're using a decent "object shipping" layer like gRPC. Really greases up the transition point between different languages.

I guess you could hire less proficient engineers which is a sell for startups, but I don't think it's worth the downsides of the current js ecosystem

danenania• 8 years ago

This advantage is further multiplied with TypeScript, since you can easily share types between backend and frontend. Working with a single set of types that enforce contracts (and supply IDE autocompletion) across the entire stack is amazing. It provides a huge productivity boost and eliminates a whole class of extremely common bugs.

pjmlp3• 8 years ago

Other than form validation, I never wrote the same code for both sides.

And that is only when not using JSF, Spring, Forms, MVC, Liferay, Sitecore, which generate the JavaScript validators automatically from type annotations anyway.

For my projects, the Web layer is only the View part of MVC.

me551ah3• 8 years ago

You never really learn javascript, you learn frameworks. I was a js developer about 7-8 years ago and dabbled with jQuery , dojo and the likes and then moved over to backend and mobile development. I tried getting back into javascript again and realized that I just could not get in and start coding. There are a lot more frameworks now that I have to learn to get started and I'm sure that a few years down the line, these will become obsolete too.

spricket15• 8 years ago

Highly recommend TypeScript. It brings so much method to the madness. Build tools are another clusterfuck but at least with TS you have a decently structured language with "standard" ways of doing things

z3t4• 8 years ago

Highly recommend vanilla JavaScript. With vanilla JavaScript you do not need any build tools. Instead of buying many different kitchen cutting and slicing tools - learn to use a knife.

tracker15• 8 years ago

I can't speak for anyone else... but I learned javascript and even liked it for most of the reasons outlined before the Good Parts book came out.

Since ES6 it's even better.

2trill2spill5• 8 years ago

While I agree with you, I just started a new project and we need a decent amount of backend work done, and I wanted to do that in Golang, Java, or Rust, but no one else on the team knows Golang, Java or Rust, just Javascript and Typescript so it made sense to go with a language the team was good with. So far I'm liking typescript on the backend, especially because we use it on the frontend. Also my coworkers can give me much better code reviews because they all know the language. But we will see going forward, still very much a green field project.

winter_blue• 8 years ago

Seriously, not knowing the language shouldn't be a factor in choosing a language.

Just choose the best programming language, and everyone can learn it; and they'll be happy and grateful in the long run that they chose to learn this new language, rather than use whatever they were familiar with.

Moreover, Java is such a simple and an easy language to pick up. If the cruft is too much to deal with, go with Kotlin. An experienced developer could learn either language (Java or Kotlin) easily over a single weekend.

johnwyles3• 8 years ago

My $0.02 but that is NOT a reason to use JS on the backend. That is an argument to cross-train or hire someone. It's like saying "We only had an expert on building houses made with straw so we chose straw." Because they know the language doesn't mean for one moment that that will make a good background there are so many concepts, services, paradigms and best practices that the language is probably the least of importance other than it should be something solid, robust, and battle tested which I would argue against with most JS backends although some are fairly well understood.

tracker15• 8 years ago

I find that beyond this, not having a cognitive disconnect in working on the frontend/backend is really nice. And depending on your data tier(s), can even go there (Mongo, Plv8, etc).

Compared to when I'd have to use ActionScript, JavaScript, VBScript, VB6, T-SQL daily... that was sometimes painful... then adding C# and VB.Net to the mix was ugly having to switch from one area of code to another.

_hardwaregeek7• 8 years ago

I will say that isomorphic [1] JS apps are really fun to write because with well abstracted APIs, the back end and front end don't feel like a discrete API and a discrete front end, but one entity that communicates via asynchronous function calls. For instance, working with firebase functions just feels like working with a local async function. But that's really a minor benefit to the fair criticisms you give.

[1] Whoever came up with isomorphic really liked their fancy math terms. Personally I'd have chosen automorphic, as it's all contained inside JS.

austincheney• 8 years ago

The problem I have with Java is that its a tremendous amount of code to do tiny things. There is a cognitive load that comes from reading. The more code you have to read to perform the equivalent action the more tired you get and the more opportunity you have for errors.

There is something precious to being able to do more with substantially less code, which is why I avoid OOP all together. You can't do that in Java.

sonnyblarney5• 8 years ago

Sympathies to your valid concerns ...

Though Java was 'designed', it was not 'designed' to be an http/web server.

JS, particularly Node.js has really adapted itself to that well.

And one small but massive difference: JSON is how data is passed and it fits seamlessly into Javascript, and doing JSON in Java is an ugly, ugly thing.

As soon as you compare not JS/Java, but Java/Tomcat vs. JS/NodeJS - then you get a different comparison.

I quite like using Typescript on Node.js over Java - development speed is faster, and this is a really important thing.

adrianN4• 8 years ago

JSON is how some data is passed today. It's certainly not the best way and might go out of style just like XML did a while ago.

spricket15• 8 years ago

I actually like gRPC better than JSON these days so it saves me from that pain, code just gets generated for you.

But yeah json is much nicer in JS generally

Traubenfuchs2• 8 years ago

doing JSON in Java is an ugly, ugly thing

Why do you think so? Jackson and Gson work very well. Serialising and deserialising from/to POJO/JSON is trivial with them.

me551ah3• 8 years ago

MarsAscendant2• 8 years ago

Interesting. I stopped touching frameworks on my second year in. It's the same problem I have with trying to develop within the constraints of someone else's work: I find it confusing and anxiety-inducing.

I'd rather write my own stuff, unless I'm woefully unequipped to to begin with. (Cryptography, authentification, credit card handling...) I feel like I'd learned quite a bit of JavaScript, specifically – especially with the help of someone like Angus Croll [https://javascriptweblog.wordpress.com/].

I'm not that clever a JS developer – or a programmer, for that matter – so his `compose()` and `curry()` sound magical to me.

ausjke• 8 years ago

I never got the idea of nodejs or javascript for backend, tried it a few times and eventually returned to python and java. It's much easier for python/java to add event-loop and/or restful framework than making javascript looks like python/java one day as far as backend goes.

In 2019 I still have 0 interest in javascript/TS for backend, the thousands of modules under node_modules alone is enough for me, and not all real world product need async/promise/callback/SPA, javascript is over-heated too much, not fun at all.

undersheet9• 8 years ago

JS is not your daddy's JS anymore.

hombre_fatal2• 8 years ago

You don't get to just add an event loop and start writing async code in Python or Java. It opens up its own can of worms now that you're straddling the sync and async worlds. Compare working with Netty (async) to Jetty (sync). It's certainly not trivial.

That Javascript is async-everything is one of its best and often overlooked features in these comparisons.

I think this snippet encapsulates a lot of why Javascript is actually very pleasant on the server:

    const results = await Promise.map(urls, (url) => process(url), { concurrency: 8 })
        .then((results) => postprocess(results))

beatgammit• 8 years ago

I don't think it is overlooked. JavaScript doesn't scale, both in terms of code complexity (callback hell) and across cores, and the "gold standard" these days is microservices, which has a ton of issues.

If you want to look at bolt-on async working, check out C# or Rust. They've basically taken JavaScript's new async/await and added threading (at least Rust has, not sure about C#). You can write an async app and have it run in a thread pool without much fuss.

I don't know what the story is for Java, but seeing as C# is effectively the same thing, it's not hard to imagine adding async being easier than adding threads or performance to JavaScript.

c-smile3• 8 years ago

JavaScript was designed to be a glue language - to connect output of one native function with input of other native function. And do all of this in UI event handlers.

And it was almost perfect (modulo hoisting, semicolon omission) for that.

The trouble has started when Web, as a platform, has failed to provide safe alternative to JS aimed for extendable way of delivering and running high-performant code on the client.

Ideally we should have something like <script type="binary/bytecode"> with something close to JavaVM and HTML DOM exposed to it. At least 15 years ago. So we would have a lot of compilers, static compilation and code analysis.

Instead we have tons of weirdest possible solutions: Web "threads" with code that need to be downloaded and compiled before running, that ugly WebAsm, transpilers-of-something-into-JS. C++ code "transpiled" into JS, in whose nightmare that bright idea was born?

Yet we have crowds of talented people wasting time of writing about how to really HACK the platform that was not meant to be used this way.

Create bunch of problems to ourselves just to overcome them heroically. Far from being productive.

pitaj3• 8 years ago

something close to JavaVM and HTML DOM exposed to it
ugly WebAsm

WASM isn't fully functional as a standalone alternative to JS in the browser, yet, but you can essentially use it that way with things like wasm-bindgen in the Rust ecosystem. And it performs essentially what you're describing, being a VM running bytecode in a sandbox.

c-smile3• 8 years ago

but you can essentially use it that way

"Essentially" is a nice word. You can use it for example as JavaScript is a programming language, essentially, yeah.

W3C DOM was defined initially in terms of Java interfaces.

Where we would be now if we were allowed to run Java bytecodes in browser directly from the very beginning?

Today we might discuss -strip-dead-code option in your favorite compiler of XYZ language. Instead of fighting with would-be-linker npm.

throwaway4272• 8 years ago

Let's say you'd like to write front-end code in a language that hides as much of the problems with JS as possible, preferably one that comes with a standard library, has elegant (or at least ergonomic) JS to <lang> interop and bridging, simplifies async code, and has a simple, integrated toolchain for targeting JS (all these amongst other things), what would you suggest? Basically what's the best language to write Javascript in : )

Dart? Elm? Clojurescript? Objective-J?

scns• 8 years ago

ReasonML

throwaway4272• 8 years ago

Oh I forgot about Reason. Does it have a standard library that obviates the need for pulling in things like lodash, etc?

mc13• 8 years ago

save

raxxorrax• 8 years ago

Unpopular opinion time: I understand why people prefer TypeScript/CoffeeScript but for me personally it just destroys the incentive of a scripting language and I am a fan of keeping deployment as simple as possible and to me transpiling is equivalent to compiling. Packaging is bad as it is.

True, maybe everything is different in large scale applications but I hate it if I find something interesting implemented in TypeScript and in 95% of cases I will just move on.

Javascript is not a beauty and any superset just seems like a facelift. The result looks like old and used car tires.

disclaimer: I am no web dev but somehow come in contact with JS frequently.

The melting pot of JavaScript (2017)

Related Stories