7 ms·

I hope that, at least, the new technology is better than the old one. But I have some objections: - why can't old libraries/frameworks/things evolve, instead o

I hope that, at least, the new technology is better than the old one. But I have some objections: - why can't old libraries/frameworks/things evolve, instead of forcing a breaking change? In many other languages evolution seems to preferred to revolution; in JS, evolution seems to be the norm. - Is that "better and smarter way of working" THAT MUCH BETTER AND SMARTER? When working JS, it seems that a complete overhaul of an application (or of an ecosystem) is required every very few years. Ultimately, software development should lead to business value; does the improvement in generated business value justify the costs associated with such a tech twirl?

andrewstuart 9y ago
>> Is that "better and smarter way of working" THAT MUCH BETTER AND SMARTER? Absolutely yes. ReactJS is an application architecture that is a complete rethink of how to structure client side applications, and it is an architecture that is being applied outside JS and the browser because it is so much better. The fundamental concept of one way data flow from parent to child through the application requires a start from scratch approach, and would be severely compromised were it to be implemented as an "additional" evolution of some existing application framework such as AngularJS. Yes - that much better and smarter. ES2015/ES7 are radically better languages that make hugely important changes to JavaScript. Yes - that much better and smarter. Transpilers make it possible to run ES2015/ES7 even on browsers that support only ES5 - that is amazing - yes - that much better and smarter. Build tools such as minifiers and packers and uglifiers perform magic to shrink and optimise code for a range of benefits including end users performance - Yes - that much better and smarter than sending a chunk of raw JS to the browser. In short, yes, JavaScript is experiencing a continuous wave of really major and significant improvements that justify ditching the previous generation entirely. I will say however that breaking changes give me the shits abut for the most part I am willing to endure them - I simply must assume that the changes are for the better because I don't have time to really understand every single change in every library that goes into my application - no JavaScript developer does - nor indeed does any Python developer try to understand every change to all the Python libs that they use.
- Peaker 9y ago
  If you're willing to use transpilers, why stick to JS at all, when you have a wealth of languages available? Scala, Purescript, Haskell, Elm, ...
  - _ar7 9y ago
    Because JavaScript 1. By far, has the largest ecosystem. 2. If you use a linter, a typechecker (TS or flow), and transpile your code (TS or babel or both), JavaScript is actually a pretty nice language to work in. Sure it's a chore to set up all the initial tooling, and learn the ins and outs. However, once you're past that, it's usually not worth it to switch.
    - Peaker 9y ago
      1. The ecosystem is available via bindings too (to most transpiled languages) 2. It's still far from the state of the art in PL design and missing: * Nice static typing with type inference * Nice guarantees about null access * Nice guarantees about interop between client and server * ...
    - unclebucknasty 9y ago
      >It's a chore to set up...and learn... >However, once you're past that, it's usually not worth it to switch. That is somewhat circular and can be said of virtually anything. That is, for every minute you invest in a tech, the degree to which it is worthwhile to switch to another tech diminishes. I'm speaking primarily about tech like frameworks that is aimed at making us more productive. The exception might be a truly revolutionary new tech that sharply boosts productivity, but also has a very low learning curve. However, that scenario seems particularly unicorn-ish where JS frameworks are concerned.
  - WorldMaker 9y ago
    The closer the transpiled language to JS the lower the impedance mismatch. Whatever language I write in, I may need to dive into debugging it as JS. Whatever language I write in, I likely have to use/adapt JS code samples from libraries and dependencies written in JS. More often than not that's a paper-cut; Haskell often has a huge impedance mismatch from x86 assembly but you can still debug it pretty well and FFI into assembly libraries with varying levels of ease based on library documentation. But especially when you are working with other developers and a mixture of skill levels, impedance mismatches are useful paper-cuts to try to minimize.
rimliu 9y ago
Some of that can be compared to trying to find innovative ways to eat the soup with a fork.
- dvfjsdhgfv 9y ago
  That's so true. There was an article on HN recently on how advanced desktop app development tools were many years ago; how quickly you could build a fully functional and quite advanced application. When you have that background, the current state of JS resembles C on DOS in the early nineties. With the exception that there are far, far more complications that could have been be abstracted so that developers can focus on developing the app and not the underlying stack.
  - aaron-lebo 9y ago
    Nostalgia is overrated. You can with a 10 line HTML file and linking a few CDNs make an interactive application that can reach 1 billion people with no install and no buffer overflows. That's magic. The 90s wish they could do that.
    - maxxxxx 9y ago
      I could write a CAD system in the 90s with 10 lines of C and linking a few libraries :)
      - maelkum 9y ago
        Well, given sufficiently good libraries everything can be written in 10 lines of C.
    - dvfjsdhgfv 9y ago
      It depends what you create. If it's business apps for your customers, they might not care about availability to 1 billion people, but will appreciate several other things (such as rapid modifications) that more often than not are not so trivial to implement in modern web apps.
  - 9y ago

andrewstuart 9y ago

>> Is that "better and smarter way of working" THAT MUCH BETTER AND SMARTER? Absolutely yes. ReactJS is an application architecture that is a complete rethink of how to structure client side applications, and it is an architecture that is being applied outside JS and the browser because it is so much better. The fundamental concept of one way data flow from parent to child through the application requires a start from scratch approach, and would be severely compromised were it to be implemented as an "additional" evolution of some existing application framework such as AngularJS. Yes - that much better and smarter. ES2015/ES7 are radically better languages that make hugely important changes to JavaScript. Yes - that much better and smarter. Transpilers make it possible to run ES2015/ES7 even on browsers that support only ES5 - that is amazing - yes - that much better and smarter. Build tools such as minifiers and packers and uglifiers perform magic to shrink and optimise code for a range of benefits including end users performance - Yes - that much better and smarter than sending a chunk of raw JS to the browser. In short, yes, JavaScript is experiencing a continuous wave of really major and significant improvements that justify ditching the previous generation entirely. I will say however that breaking changes give me the shits abut for the most part I am willing to endure them - I simply must assume that the changes are for the better because I don't have time to really understand every single change in every library that goes into my application - no JavaScript developer does - nor indeed does any Python developer try to understand every change to all the Python libs that they use.

Peaker 9y ago
If you're willing to use transpilers, why stick to JS at all, when you have a wealth of languages available? Scala, Purescript, Haskell, Elm, ...
- _ar7 9y ago
  Because JavaScript 1. By far, has the largest ecosystem. 2. If you use a linter, a typechecker (TS or flow), and transpile your code (TS or babel or both), JavaScript is actually a pretty nice language to work in. Sure it's a chore to set up all the initial tooling, and learn the ins and outs. However, once you're past that, it's usually not worth it to switch.
  - Peaker 9y ago
    1. The ecosystem is available via bindings too (to most transpiled languages) 2. It's still far from the state of the art in PL design and missing: * Nice static typing with type inference * Nice guarantees about null access * Nice guarantees about interop between client and server * ...
  - unclebucknasty 9y ago
    >It's a chore to set up...and learn... >However, once you're past that, it's usually not worth it to switch. That is somewhat circular and can be said of virtually anything. That is, for every minute you invest in a tech, the degree to which it is worthwhile to switch to another tech diminishes. I'm speaking primarily about tech like frameworks that is aimed at making us more productive. The exception might be a truly revolutionary new tech that sharply boosts productivity, but also has a very low learning curve. However, that scenario seems particularly unicorn-ish where JS frameworks are concerned.
- WorldMaker 9y ago
  The closer the transpiled language to JS the lower the impedance mismatch. Whatever language I write in, I may need to dive into debugging it as JS. Whatever language I write in, I likely have to use/adapt JS code samples from libraries and dependencies written in JS. More often than not that's a paper-cut; Haskell often has a huge impedance mismatch from x86 assembly but you can still debug it pretty well and FFI into assembly libraries with varying levels of ease based on library documentation. But especially when you are working with other developers and a mixture of skill levels, impedance mismatches are useful paper-cuts to try to minimize.

rimliu 9y ago

Some of that can be compared to trying to find innovative ways to eat the soup with a fork.

dvfjsdhgfv 9y ago
That's so true. There was an article on HN recently on how advanced desktop app development tools were many years ago; how quickly you could build a fully functional and quite advanced application. When you have that background, the current state of JS resembles C on DOS in the early nineties. With the exception that there are far, far more complications that could have been be abstracted so that developers can focus on developing the app and not the underlying stack.
- aaron-lebo 9y ago
  Nostalgia is overrated. You can with a 10 line HTML file and linking a few CDNs make an interactive application that can reach 1 billion people with no install and no buffer overflows. That's magic. The 90s wish they could do that.
  - maxxxxx 9y ago
    I could write a CAD system in the 90s with 10 lines of C and linking a few libraries :)
    - maelkum 9y ago
      Well, given sufficiently good libraries everything can be written in 10 lines of C.
  - dvfjsdhgfv 9y ago
    It depends what you create. If it's business apps for your customers, they might not care about availability to 1 billion people, but will appreciate several other things (such as rapid modifications) that more often than not are not so trivial to implement in modern web apps.
- 9y ago