Hacker News Reader

Comment by pjmlp | Hacker News Reader

Personally I don't buy into any "Compiles to JS" language for production code, other than for dabbling.

The JavaScript compatibility problems across browsers are already enough, for me to sell to customers yet another layer to debug that might not even be properly supported by the respective browser debugging tools.

View on HN

I look at compile-to-JS as a temporary solution until WebAssembly is the norm. No way that in 2016+ the best we have for web development (most common case of GUI development) is JS :)

Any commentary on "The Birth and Death of Javascript"?

https://www.destroyallsoftware.com/talks/the-birth-and-death...

As far as I can tell, Javascript the runtime is a juggernaut that there's no stopping. If a platform gets popular tooling fixes itself.

Personally, even though I also do have quite some webdev experience, I am wishing that mobile native development wins.

But on HN that is a sure way to be downvoted.

I'm personally hoping the future holds some way to blend the openness/interoperability of the web with the performance of native apps. Maybe React Native, maybe web assembly, etc.

I hope that pure mobile development doesn't win, because the mobile app ecosystems are way more controlled than desktops/servers, and if everything went Android/iOS, it would be a major loss for freedom.

It does not fix itself. It gets fixed through a lot of hard work by many people who shouldn't be hidden behind the curtain.

But you are right that if a platform is popular enough, it will usually attract people that will do this work.

Yes, the source-map support in browsers really needs to improve. NodeJS is another matter though as, in my experience, it maps seamlessly.

I think Coffeescript, TypeScript and Babel (ES6 and JSX) are completely different beasts to Elm though. I can look at the compiled output of these languages and debug that, I don't really need source maps (though they would be nice).

I guess the idea for Elm is, you won't need to debug as you won't get runtime errors.

Is transpiling really that different than running google closure on "native" js?

Another thing that we don't use.

Either you're stuck with ES4 (and worse, you can kiss goodbye to a large number of NPM modules which are ES6+) or you still need a transpiler and a system to package your scripts, handle polyfills, etc.

It's just difficult to do non-trivial JS development without only "raw Javascript" in 2016.

RequireJS, jQuery, JSF, ASP.NET, Spring are what we use.

I have to say you're missing a few years of awesomeness should you take the plunge.

Given that I go native, when given the option, I doubt I ever will.

We used to be RequireJS/jQuery based on the frontend. While this obviously depends on what kind of application you have, attempting to develop complex UI in jQuery is not an experience I'd describe as "pleasant", nor does it naturally lead to creating reusable components.

On the other hand, switching to React + Redux + webpack (and NPM) has changed development from "we can't do that" or "let's copy paste from some other component" to "I'll have something by tomorrow" and "I'll reuse the generic React widget I made last time". It's really a game-changer.

Also, ES6 >> ES4. Destructuring doesn't bring you what real pattern-matching does, but it's still a lot nicer than what ES4 gives.

Now try that in the context of 30+ enterprise developer projects, composed with multiple outsourcing/offshoring partners.

Companies that still want to target IE 8 or even the old Safari for Windows.

Actually, we manage to mostly support IE 8 through a combination of Babel and polyfills. You don't necessarily need to forgo modern goodness in order to support prehistoric browsers.

Reply on news.ycombinator.com