4 ms·

So using your summary at which step did the engineer make the wrong choice?

ModernMech 7y ago
That'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 ago
None. 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 ago
Apparently, 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 ago
At 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 ago
    Well, 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

That'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 ago

None. 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 ago

Apparently, 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 ago

At 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 ago
  Well, 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