3 ms·
So... let me get this straight. You are making a website. You do need to load some changing data into it, so just a static site will not cut it. But we want to
by MadWombat 7y ago
So... let me get this straight. You are making a website. You do need to load some changing data into it, so just a static site will not cut it. But we want to keep things simple. All we really need are a few AJAX calls and some DOM updates. And just like the author mentioned we don't want to write old clunky JS, we want to write beautiful ES6 code. So we install babel for ES6. And we install jQuery to do our AJAX and DOM stuff. Turns out that if we want to make AJAX calls to our API server, we cannot just load the file in the browser, it expects a server. We look briefly at installing nginx or apache and it seems like a lot of trouble. But we do discover webpack dev server. That's perfect. So we install webpack and configure the dev server. Since we are doing it, we might as well make it run babel for us. And while at it, we might as well do the bundling. Especially, since we would like to use a couple of other NPM modules. Nothing major, just convenience things. And since we are using the dev server anyway, we add hot-reload support. And a minifier, so we can have a minified production build.
So now we are using HTML, CSS, jQuery, babel, webpack, webpack dev server, webpack hot reload plugin, webpack plugins to load resources and a minifier. But hey, keep it simple, right?
- root_axis 7y agoSo using your summary at which step did the engineer make the wrong choice?
- ModernMech 7y agoThat's the point. At no time did the engineer building the application make a poor choice. He/she made the logical rational choice to get the job done. It's the same thing for the tools developers. They each made their respective tools to solve a real concrete problem and succeeded. The problem is that everyone seems to be making incremental improvements and engineering choices that locally make sense, but when you zoom out and look at the whole picture things look absurd. We're incrementally improving ourselves to a local maximum that seems to be an uncomfortable place to be. There may be a better path that will lead to a better maximum, but we can't see it from where we are.
- MadWombat 7y agoNone. That's the point. Web development is not simple. You don't have to always use the very latest super framework, but even the minimal setup for developing a modern website has quite a few moving pieces. If you remove any component from the list above, your development experience will become harder.
- kenny87 7y agoApparently, when they decided developing for the web was a good idea. The bigger problem is that computing is insanely complex in the modern age. Developing for the web is on the cutting edge of that computing power. We're delivering full, non-native applications to computers people are carrying around in their pockets. And because they expect their applications to run like "real" desktop applications the UI of those "web apps" require a seamless experience. So web apps are real applications that require the same complexity in tooling as any another C++ desktop applications. Web developers are real developers. It would insane to create such complex tooling if we did not need to use it to build for those insane web browsers. Blame Sir Timothy John Berners-Lee for our current predicate, not us.
- hootbootscoot 7y agoAt the point that they chose to use all this kit and write "beautiful ES6". Write ES5, use a few polyfill functions, include the already minified mithril/vue/react js IF you actually are going to need dynamic DOM elements. An XHR sweetener is included in mithril at least, but if not, it's only a few lines easily memorized, as you will do them constantly, it's also a good candidate for that library you should have made for all your projects by now, with that "byId()" and "byClass" shorteners etc... just an XHR you can pass a callback, url, and method to... var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function(){ if(this.readyState == 4 && this.status == 200) { //do stuff to your dom, JSON.parse(return stuff) etc. } } xhr.open("POST", "/some route/" + whatever, true); xhr.send(); FormData(); would add 2 more lines to the above... I see no point in all this front-end toolchain stuff trying to maintain an illusion that ES6 runs in most browsers. Invariably maintaining false abstractions will not promote deeper understandings of the rather essential and basic "request response" cycle of HTTP. It's not even pretty. Classes in JS? Gimme a break. Show me the ugly truth and K.I.S.S. because life is short and we have better things to do in life...
- root_axis 7y ago> At the point that they chose to use all this kit and write "beautiful ES6" So are you saying that most projects that use JS should avoid the use of ES6?
- hootbootscoot 7y agoWell, either that or polyfill. Transpiling to JS may be a product of other motives (Typescript, Svelte, Elm etc.) While Ruby is pretty and all, I don't find that I'm enjoying the lie that is ES6, and don't even get me started on classes in JS, etc. Bottom line, JS isn't my favorite language, but I'm not dying reading/writing ES5, (nor does ES6 look lovely when I know that it's lying to me) and the advantages outweigh the disadvantages... I'm questioning a lot of the group-think decisions. State management? What is "a variable"? Many times the cure is worse than the disease...
- 7y ago
- robertoandred 7y agoWhat’s the issue with having a development environment?