5 ms·
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 pa
by mercurial 11y ago
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.
- pjmlp 11y agoRequireJS, jQuery, JSF, ASP.NET, Spring are what we use.
- cnp 11y agoI have to say you're missing a few years of awesomeness should you take the plunge.
- pjmlp 11y agoGiven that I go native, when given the option, I doubt I ever will.
- mercurial 11y agoWe 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.
- pjmlp 11y agoNow 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.
- mercurial 11y agoActually, 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.