8 ms·
It can be a pain getting the build system up and running but once you're writing typed JavaScript code with modern features like async/wait and ES6 modules alon
by seanwilson 9y ago
It can be a pain getting the build system up and running but once you're writing typed JavaScript code with modern features like async/wait and ES6 modules along with live + hot reloading, it's impossible to go back. It's really trendy to complain about JavaScript changing too fast right now but the last few years have brought some great changes to JavaScript.
- ng12 9y agoAgreed. I think the perception comes from lots of people who are using heavy frameworks for simple, mostly-static webpages. Yes, they add complexity to my life, but the experience of working with React/We pack/Typescript is unparalleled -- especially considering what I was working with only five years ago.
- seanwilson 9y agoYup. Converting old promise based code to using async/await and fixing all the places that give "variable could be undefined" type errors is so satisfying. Recently I did a huge refactor of some TypeScript code without running the app and just being guided by the type checker errors for several hours and it worked almost first time. We pack = Webpack?
- zoul 9y agoBut didn’t we say the same thing about JS almost every year in the past? Only for the status quo to be obsoleted in a few months? Is the breakneck change curve slowing down finally?
- lolive 9y agoBeing a java-ist, I could not consider to learn JS without a proper type system, and a proper IDE (with autocompletion, static analysis & refactoring facilities). TypeScript & VSCode/IntelliJ save my day now. More advanced programming paradigms (a la Haskell) are nowadays almost doable in the JS ecosystem. So yes, I would consider that JS has matured as a platform. I still have no clue about frontend web frameworks yet.
- aphextron 9y ago>It's really trendy to complain about JavaScript changing too fast right now but the last few years have brought some great changes to JavaScript. I'd say they've made JS development bearable, but great is really stretching it. We still don't have a type system, static analysis, multi-threading, first-class IDE support, or any of a myriad of other features that are standard in any modern programming language in 2017. I'm hopeful that projects like Blazor[0] and other efforts being made toward bringing real languages to the web via native WASM will put JS to rest once and for all. https://github.com/SteveSanderson/Blazor https://github.com/SteveSanderson/Blazor [0]
- ko27 9y ago> type system, static analysis, first-class IDE support Agree, but we have TypeScript, also static analysis is done for ES6 module dependency > multi-threading This is wrong. JS has service workers, and sharred array buffers.
- aphextron 9y ago>This is wrong. JS has service workers, and sharred array buffers. Service Workers are not really threads as the runtime environment is still single threaded no matter what, you just have the ability to spawn a new process. On top of that browser support is sketchy at best, with no planned support for Safari or IE.
- lauritzsh 9y agoIt is currently in development for Safari https://webkit.org/status/#specification-service-workers https://webkit.org/status/#specification-service-workers
- JimDabell 9y ago> On top of that browser support is sketchy at best, with no planned support for Safari or IE. Apple is currently working on implementing it in Safari: https://webkit.org/status/#specification-service-workers https://webkit.org/status/#specification-service-workers It's misleading to say that there's no planned support for Internet Explorer – Edge superseded Internet Explorer so all new development is going into Edge, not Internet Explorer. Service Worker support for Edge is under development: https://developer.microsoft.com/en-us/microsoft-edge/platform/status/serviceworker/ https://developer.microsoft.com/en-us/microsoft-edge/platfor...
- dolphone 9y agoNo one is complaining because its trendy. Rather, good JavaScript developers already know the core language plus jQuery and a framework or two. We can build websites without the extra stuff. We are tired of spending our time and energy learning technologies that are horizontal to what we have already mastered. We enjoy writing JavaScript and find it suspect when anyone complains about the language. When we hear about frameworks and build tools we think http://m.imgur.com/gallery/2dykF3D http://m.imgur.com/gallery/2dykF3D
- SquareWheel 9y agoI stick mostly to JS + jQuery, but I see nothing wrong with using additional tools when the situation calls for it. If you're going to be writing a lot of CSS, then using SASS might save you some time and improve readability. If you're writing a webapp, then a SPA or React app might be the best course. And if it's image heavy, then a tool to automatically compress images would likely make sense. If this is too complicated to manage, then other tools like task runners or Webpack can help automate the process. Node packaging can be used to sync settings across all project owners. Taken on their own, it seems like a lot of complexity. But if you're only adding tools when you need them, it's really not that bad. I wrote my last site in Jekyll + SASS. No Webpack, no gulp, no React. I just didn't need them, so I avoided the complication. I'm glad they're there if I decide I want them, though.
- nol13 9y agoBut the core language really is that much nicer to program in when you can freely use object destructuring, spread operators, and some of the newer built-ins, etc.
- mattacular 9y agoI still just use ES5 JS, jQuery for around 2/3rd of the frontend code I write. The remaining third is a split between simpler, more mature but decidedly unsexy frameworks like Backbone, Underscore, Handlebars and newer trendy babelifed React and Vue. Both are fine. I enjoy both still. Some people would consider it a bad thing that eg. Backbone hasnt had a major version in years but it is still perfectly capable for many use cases and it performs well. Of course you have to have more experience and knowledge with JS and frontend development in general to get these results I think.
- edem 9y agoA language without a proper stdlib and with programmers who have no idea what the O notation is about has no place in any serious programmer's "to learn" list.
- deleted 9y ago[deleted]
- oelmekki 9y agoAka "javascript is not a real language", I thought we were done with that since almost a decade :) Maybe you should consider that just because a language doesn't work like what you're used to, it doesn't mean it's a bad language. Because saying nowadays that javascript is not worth learning sounds pretty absurd. Sure, you can live without it. But that's probably the most useful language to know as a "second language", for all its various applications and because when you want to add scripting in your tool, you know javascript is a solid choice for its penetration rate.
- wruza 9y agoAbstracting from js, rates and popularity of the only available solution are not an argument. It is like asking 'but who else?' in a dictatorship country. Pretty absurd, right. You folks are so blind that don't even understand how this straightforward non-blocking code works in decent languages: sql = client.read() res = remote_db.query(sql) client.write(res), still writing tons of boilerplates and spaghetti instead. We drown in happy ignorants, and they can't stop doing this to us, because they're happy with penetration rates, not technologies. The fact that the big web scripting monopoly influences other scripting and embedding markets is self-explanatory. As for 'second' language, I'm pretty sure I'm not happy to do main work with a 'second' language, because it is second only after top 3-5 that I use on daily basis.
- deleted 9y ago[deleted]
- rimliu 9y agoWhen language does not even have proper integer type I kind of have my doubts about it.
- oelmekki 9y agoAnd even there it's not the pain it has been, if you write react app, thanks to create_react_app. It basically brings all of that out of the box, without any configuration needed, just like `rails new my_app_name` creates a ready to use app. Actually, I've seen several times people reporting using it for non react projects, just because of that ease of setup. Of course, you may still want to tweak configuration, and then you have to "eject", which means that all configuration files are dumped in your directory for you to edit, and you basically don't use create_react_app anymore. You now have to get webpack and babel configuration right to make your changes, but you have a solid basis. Nowadays, I try to never eject, and see create_react_app as a lib providing everything I need. It sometimes prevents me to try new staged js features, but on the other hand I often have new features on update that I didn't bother enough about to eject in previous version. Such wrappers around build system are probably the way to go. I would love to see something like create_react_app but allowing to provide buildpacks, so we can find in the wild the perfect configuration for our taste.
- gggdvnkhmbgjvbn 9y agoI like create react app a lot but i wish there was an easy way to add a second page. I tried doing this recently and found it was actually easier to implement react router with code splitting to avoid loading my main page's huge js file.
- oelmekki 9y agoI always do that, actually. I see what is provided in the App.js file as just a placeholder, meant to be replaced. Since you have webpack, you can import files from all over the place, deciding how to organize your project. It works just fine without ejecting :)
- acemarke 9y agoI think the issue the parent is referring to is that CRA's Webpack configs only define a single "entry point", for your index.js, where each entry point becomes a separate bundle in and of itself. Having multiple entry points, like an "app page" and an "admin page", would require editing the Webpack config, which CRA deliberately keeps abstracted and hidden away until you eject. If you really want to be able to modify the Webpack config for a CRA app, you have a couple other options besides ejecting: - Create your own custom fork of the react-scripts ( https://github.com/facebookincubator/create-react-app/tree/master/packages/react-scripts https://github.com/facebookincubator/create-react-app/tree/m... ) package that CRA uses - Use the react-app-rewired (https://github.com/timarney/react-app-rewired https://github.com/timarney/react-app-rewired) tool , which lets you override parts of the build config within your project.
- alayek 9y agoEven better. You don't even need to set up a build system for async/await, ES6 modules (coming in Chrome 61) these days. Most modern browsers support a great portion of ES6+ specifications by default. Live / Hot reloading might take some setup though. One thing I am yet to see implemented, is tail-recursion. It's in the spec, but I am yet to find an environment that implements it. Please correct me if I'm wrong.
- mattacular 9y agoSafari 10 and the current iOS version support tail recursion (and 99% of the ES6 spec)
- rimliu 9y agoGoing back where? Would I go back from JS to Ruby. Without even thinking. Would I go back from JS to Swift? Without the shadow of the doubt. Would I go from JS to Perl? Probably not. But I am sure plenty others would. My quantum mechanics professor told us that "you cannot understand QM, but you can get used to it". Something along these lines applies to JS as well though I am not sure what word should replace "understand".
- _pmf_ 9y ago> It can be a pain getting the build system up and running but once you're writing typed JavaScript code with modern features Of course, once you're writing typed JavaScript, you're no longer writing JavaScript.
- polymeris 9y ago> it's impossible to go back. I too, am learning JS in 2017, and I can't wait to go back (to cljs). Or away, to anything else. I had done some basic stuff before, but for the last days I have been writing some code for a larger SPA. Just as an example, today I needed to do the simple task of iterating over a dictionary. I expected it to go roughly like this: dictionary.forEach(this.someMethod); Instead, this is apparently what passes for sane in JS world, in 2017: for (var key in dictionary) { if (dictionary.hasOwnProperty(key) { this.someMethod(key, dictionary[key]); } }
- rattray 9y agoThere are other options, closer to what you're looking for. Try Object.entries(dict).forEach(fn) Or _.entries(dict).forEach(fn)