Hacker News Reader

Comment by alanfranzoni | Hacker News Reader

To me, it is incredible that the frameworks matter THAT much in the JS world. Once you know about Javascript, the web, and browsers... any good dev should be able to pickup such part of the tech stack (frameworks, libraries, ecc) quite quickly.

In other environments (e.g. Python, Java) nobody expects you to know everything about the specific libraries used in a company; once you know the language and a bit about the technologies (e.g. work on Linux, on a webapp or a desktop app), you're good, you'll pickup the details while working.

Forcing a technology change because it's not the "latest and greatest big, shiny thing"... I find this is a slightly disturbing trend in frontend development.

View on HN

It's a myth that developers follow trends because they're cool.

The reason one picks up a new JavaScript technology is because it is a better and smarter way of working.

Wave after wave of innovation is bringing better and smarter ways of doing things.

There seems to be some sort of vague idea that JavaScript programmers are following new libraries and frameworks like there is a Solid Gold Hit Parade of JavaScript and they all jump onto the number #1, and next month there is a new #1 so everybody changes to that simply because it is the new #1. That would be stupid.

I use ReactJS because it is a great way to program and gives and application an excellent and functional structure. I use ES2015 and ES7 because they make JavaScript very much more powerful than ES5. If something radically better comes along then damn right I'll switch to it if I can, because "better" means smarter, easier, faster, more powerful - some combination of those to a greater or lesser extent.

The JavaScript community desperately needs a fresh wave of innovation - but this wave must be about simplification - ideally the almost complete removal of all the pain associated with configuration of JavaScript build tools, which right now is excruciatingly and unnecessarily complex and painful - create-react-app has started this process and sets the standard for other tools moving ahead - the right amount of configuration is zero.

It is necessary to use a bunch of painful JavaScript configuration and build tools in order to get your stuff to run. Waves of better, simpler and smarter build tools overrun the previous generation because they have found simpler and easier and more powerful ways to work.

Lets just drop the idea that JavaScript programmers are a bunch of airheads who follow the latest trends whilst they pull on their flared pants and fancy hairstyles.

I'm sorry but no, that's not a myth at all, and innovations aren't coming in waves. It's mostly a mistaken perception of the sheer volume of action in the JS sphere, most of which is not innovation at all.

My feeling with the ever growing list of fotm js frameworks that are now firmly dead and buried in the ground is this:

    10 ShinyNewJSFramework = 1
    20 Use framework
    30 Do conference speech about how much better it is than JQuery
    40 Hit problem X
    50 Find ShinyNewJSFramework is nigh impossible to debug
    60 Eventually come to loathe framework because of problem X
    70 ShinyNewJSFramework += 1
    80 GOTO 20

This subroutine also describes 3.5B years of evolution. Nearly all ancestors of extant creatures are dead and buried too.

Yes, but evolution is stupid and slow. I don't want to wait 1 billion years for JavaScript to be developer-friendly.

With React, Redux, Babel, Webpack, I would say there are a lot of innovations coming in through there, and the plugin system is being moved from angular, jquery, gulp to these, if you're writing old javascript to target ES5 compliant browsers more power to you, targeting the next version ES6 increased in volume a lot just recently the version is literally called ES2015

The long view of the innovation in React is that it is a tool enabling a change in pattern from "separating concerns of the view layer" to "modular components that get fed data" which is definitely a shift in the way we have previously worked with the frontend and I find very cool. It was also specified in the Web Components spec that is set to become a browser native technology, so React and friends will hopefully be replaced by native components and maybe we can all start focusing our efforts on building standard libraries of re-usable code that will be easily portable, and we can all forget the JS Gold Rush ever happened.

This is honestly the direction I see us going. Angular has also created a component concept nearly identical to React, the only difference is implementation details. It's a natural way to go, because it decreases cognitive load.

I am intrigued and ponder the idea of there being "JS Standard Libs" and wonder which ones will initially get picked for the honor. I don't think it will be React or Angular but definitely "something" like them, even if it is a version of Web Components.

That'll also mark a huge change in performance and download metrics, because if your browser already has your framework built in, your delivered code base is suddenly a fraction of what it was. And then there will be more opportunities there, too - dynamically providing the framework where needed in a separate code split, vs. a browser that does not need it.

We're just at the beginning, really. Browsers stalled for 15 years and have shifted into a period of innovation again.

  Segmentation fault. Core dumped.
  $ ls
  brain.core

For me Vuejs is one example of the "no innovation" part.

My journey has been JQuery -> Angular -> React with background noise of Node.js

I've specifically tried to avoid Choo/Vue/Whatever until there has been real traction in the job market and the community behind that framework. BUT the move from each 'framework' to the next has been a revelation in how to do things better.

I feel comfortable now that React is delivering an ecosystem that is going from strength to strength and has brought a maturity to the front-end javascript ecosystem that was missing. Huge props to the community for that.

Yep definitely, either way React is here to stay and it is in large part not due to Facebook, but to the maturity of the community that has supported it. I'm consistently impressed by their level of professionalism.

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?

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

These are good points. In my experience other platforms have the same tooling as JS has been getting over the past few years.

Look at Android for comparison:

- ReactJS: React Native, also any overall architecture like MVVM or MVP.

- ES2015/ES7: JDK 7/8

- Transpilers: Kotlin

- Minifiers/packers: proguard and others

- Gulp and co.: gradle

- Other libraries: android has a number of libraries to handle network requests, image loading, animations etc.

What I'm trying to put across is that JS has transitioned from a language that would show and hide elements of the DOM to a serious language used everywhere.

A good developer takes the time to understand the tooling around their platform and language.

There's a very good point here - JS is being used for way more than just showing and hiding DOM elements anymore. It is becoming a full application language, and to that end requires the features that full application development requires, not just on frontend, but in Node as well.

I have just inherited a project written in 100% ES5 and I had forgotten how obscenely verbose JS <= ES5 really was. Every extra line of code is a liability and will slow down app development. Language features support precision and conciseness and that in turn promotes enterprise-level development. A toy language (old JS) can never support a full in-browser application.

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, ...

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.

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

* ...

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

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.

That argument can be used to justify using assembly because you would sometimes have to drop down to assembly level when debugging native code.

I mentioned that. There are still programmers that do justify using assembly that way, and many historically. There are many programmers that just C/C++ over C#/Java/et al for very similar reasons.

I agree, it's not a strong argument, but it is an applicable argument to the discussion. There are trade-offs in every decision, and this is a consideration in those trade-offs.

Well, to be fair, the difference is that with Python (or basically any other langauge) a change in a library may introduce a bug, but you won't have to throw away the library or even substantially change your code, save perhaps for some temporary work-around- and the bug will most probably be fixed eventually.

With javascript, as far as a I can tell, "change in a library" means you do indeed throw out the library and adopt a new one, then write your entire code again from scratch and repeat the cycle next year. To me, that sounds like madness and just makes me happy I don't have to deal with all this.

Well the problem lies in exaggerations of not-actually-using-javascript crowd. If the "cycle" would be five years, would it still be that bad? If the previous framework would be of the very first generation of actual workable JS frameworks, and new one brought major improvements, would it still be that bad?

Reality is very different from these discussions.

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

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.

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.

I could write a CAD system in the 90s with 10 lines of C and linking a few libraries :)

Well, given sufficiently good libraries everything can be written in 10 lines of C.

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.

Could you point us to said article? A few keywords to search, at least. Thanks.

I'm sorry, now when I'm re-reading the said article, it looks like what I meant were some related comments: https://news.ycombinator.com/item?id=13650730 Several people complain that the voids space after Delphi[1] has never been filled in with something that would come close in the speed and easiness of development of desktop applications. [1] not that it doesn't exist, but it doesn't count anymore, mostly because of its exorbitant price

I can't find it either, just spent over 30 minutes searching.

Yeah Clearly NODE.JS was not picked because it's cool but because of its single threaded poor performance (talking about the cool years of node.js)

Compared to Python or Ruby, NodeJS has phenomenal performance. The single threaded argument is also flat out wrong, given that you have clustering or web workers to take advantage of every core. It's also completely misleading even within a single core, as non-blocking nature of JS will accomplish on a single core what otherwise behaves as threading would.

the cool years of node are just beginning with AWS Lambda and other cloud services that help node.js scale easier

Wait, maybe I am dumb, but why do you need AWS Lambda to scale Node.js better? You use something like Lambda which is build to handle one request per instance to scale something which is single threaded anyway?

Say I have an endpoint that has to parse a giant JSON object, which can take 100ms to parse... if that locks the thread it can block another request. With lambda I would just make one lambda function for each route and routes won't block each other.

JavaScript is unlike other languages, it take the big 4 (Chrome, Safari, Firefox and IE/Edge) to come to an agreement to get something done.

And standardization takes many years to reach mass adoptions. No language come close to such a mess. Even Python 2 to 3 migration wasn't as complex.

Yet, they move fast, faster than those languages that are controlled by one authority.

Frameworks are important because at the lower level, things are not as simple to get done as those language with only one authority.

They API agreed by the authorities will definitely be thin. So the community step up with frameworks.

It's not an issue with JavaScript it's that the Dom has always been horrible. It's actually slowly improved but not enough to do without the need for frameworks for complex front end applications.

I think that's the real problem. Most JS frameworks wouldn't be needed if the DOM was designed for what it's used today.

Yes yes yes. Simply creating nested elements and getting references to each of them is such a huge pain, and it's a huge part of why frameworks are needed.

You would think creating, say, a form with a button and a textarea, and getting references to those things would be simple, but it's crazy painful in vanilla JS.

I never understood the craze over React. I tried it, and I didn't like it. It may work for Facebook's use case, but to me it looks like a lot of people are unnecessarily rebuilding their front ends with React just because it's hot.

A lot of our industry hires based on buzzwords. For web developers, it pays to have React experience in their resume. Doesn't matter if the app they built didn't need it at all.

Depends where, though. I'm based in the South, Alabama, and most of the jobs here want C# or Angular (1x... specifically). I rarely, rarely see React mentioned.

Of those who want JavaScript experience, it's usually followed with "Do you have any .NET experience?"

Yeah same back home in Texas (Houston, not Austin). NYC and SF are different stories :-)

Facebook's use case happens to mirror a great deal of web products currently.

Certainly not in scale.

That's true, but React doesn't directly deal with those problems (and certainly not the parts specific to Facebook).

> To me, it is incredible that the frameworks matter THAT much in the JS world

It's not the JS world, it's the browsers world. I think a better comparison is iOS vs Android vs web development.

Is webassembly ever going to help in this regard? Seems like it could.

This also has to do with browser compatibility. Vanilla Javascript sucks so hard because it's so difficult to write non-trivial stuff that just works. This is the whole raison d'être for JQuery. This is mainly because the different browsers don't coordinate and there is no official standard. It should have been obvious from the start that this is a recipe for disaster.

Reply on news.ycombinator.com