Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of JavaScript 2018

2018.stateofjs.com

Post reply on HN
Print view View original

271–280 of 286 posts

Re: The State of JavaScript 2018

#271

Post by ix-hispana »

pledg wrote: post #39
reichardt wrote: post #35

As a student currently studying and working in Berlin I wonder why Vue and specifically Angular are way more popular than React. Looking at local job posting Java and Angular seem to be king for almost everything. How come?

Popularity with developers who reply to surveys is not the only factor in whether it is used. There's loads of sites that would need maintaining already written in Angular.

There are lots of new projects being written in Angular as well. Just not in the United States, Canada, or Australia.

Re: The State of JavaScript 2018

#272

Post by SonicSoul »

marcosdumay wrote: post #258
tabtab wrote: post #245

Earlier quoted context omitted.

With HTML Tables, it's easy to switch on the grid (border=1) and see what's really going on. Maybe I'm old fashioned, but WYSIWYG sure the hell made life easier. Unless you are a dedicated UI specialist, you'll probably spend way too much time dinkering with the web UI because it's not WYSIWYG. It's like trying to park an 18-wheeler truck in a normal lot: you can't just "go there"; you have to plan it all out in 7 st…

> With HTML Tables, it's easy to switch on the grid (border=1) and see what's really going on. With CSS it's actually easy to display the grid `\*{border=1;}`. With tables, you have a lot of them, and must go into each line of your page adding that clause.

Nah you can target both with css (I.e. use table td selector to target all cells)

Re: The State of JavaScript 2018

#273

Post by _Tev »

tracker1 wrote: post #235
nkjoep wrote: post #113

Earlier quoted context omitted.

I've got the same feeling but with bad connotation. React is easy the same way jQuery is. Easy, unstructured, foggy, too much permissive tool. Far too easy to end-up with spaghetti-code. I prefer not using it, Angular is far more organized.

Like another reply. // MyHello.jsx import React from 'react'; export default ({name}) => Hello {name} ; Now do the same in Angular.

I cannot speak for GP but for me the complexity comes from stitching dozens of libraries to get similar "base" to build the app on. Ember/Angular have way more stuff baked in or standardized, while in React you have to handle ball of ever changing dependencies ... For seniors it's ok(-ish) tradeoff (you get much more choice / control), for juniors it is hell on earth.

But that is more of an issue for projects maintained for a long time. If you want to crank out small apps fast, your "example" is relevant, and React definitely is the better option.

Re: The State of JavaScript 2018

#274

Post by tracker1 »

spankalee wrote: post #262
tracker1 wrote: post #247

Earlier quoted context omitted.

I think React has pretty much reached saturation in terms of raw percentage. I think Vue is going to continue to erode from Angular. Also, I'd be surprised if a revised Polymer didn't see some growth since the other browsers are now starting to support a lot of the vdom features.

We have a revised Polymer, two in fact. First is Polymer 3, which is Polymer available as standard JS modules and on npm for the first time ever. Dropping the huge barriers to usage of Bower and HTML Imports should have a large impact all on their own. The other is lit-html and LitELement. lit-html is a template system that's much better suited to being embedded in JavaScript, and allows a very similar style and expr…

Understood, I just haven't kept up with Polymer, or that much with the VDOM features in the browser, just know that a lot of those featers have started landing cross browser, and assumed that Polymer was keeping up.

I do think that if not Polymer specifically, something similar will win in the end eventually... probably something between React and Polymer. Of course Polymer will be a better model working with HTTP2 features and js modules. It'll likely come down to who gets the tooling stories worked out, or if the browsers themselves catch up first.

Re: The State of JavaScript 2018

#275

Post by wild_preference »

devxpy wrote: post #196
wild_preference wrote: post #178

Earlier quoted context omitted.

But client development is always hard. Comparing backend work to browser client development in an effort to attack Javascript never made sense to me. At least you have pretty good wiggle room to use other solutions on the browser client, whether it's other languages (TypeScript, Elm), to completely new abstractions (React, Elm again, etc). For example, Elm or React are a fuck ton better than anything we have native o…

Look at flutter. Please.

Like everything, it has trade-offs and is not a free abstraction.

Re: The State of JavaScript 2018

#276

Post by bryanrasmussen »

gagege wrote: post #259
bryanrasmussen wrote: post #120

Earlier quoted context omitted.

yes that would be nice, but then lots of things that do not match reality would be nice.

The second step to making things better is to believe they can and should be improved. The first step is knowing that the current state of things is deficient in some way.

I think the should be improved is implicit in the first step, does can be improved imply a suggestion - if not the third step is a suggestion, and it's that third step I'm always seeing problems in, not to mention the third step in a scenario of too much too learn runs into the XKCD standards problem https://xkcd.com/927/

Re: The State of JavaScript 2018

#277

Post by tracker1 »

equasar wrote: post #264
tracker1 wrote: post #236

Earlier quoted context omitted.

I keep repeating myself here... import React from 'React'; export default ({name}) => Hello {name} ; Now duplicate in Angular and tell me it's simpler.

what's the point of this? I mean, Angular has its use cases aswell as React does. The point you are trying to achieve leads to nothing.

My point was, angular is emphatically NOT the most simple component option. I, personally, can not think of a single use case where Angular (any version) is a better option than React, Vue or Polymer.

Re: The State of JavaScript 2018

#278

Post by tracker1 »

sAbakumoff wrote: post #269
tracker1 wrote: post #236

Earlier quoted context omitted.

I keep repeating myself here... import React from 'React'; export default ({name}) => Hello {name} ; Now duplicate in Angular and tell me it's simpler.

If I were to write such an app, html + vanilla js is more than enough.

The point was in response to how "angular is the most simple..." where it is emphatically NOT so.

Re: The State of JavaScript 2018

#279

Post by tracker1 »

_Tev wrote: post #273
tracker1 wrote: post #235

Earlier quoted context omitted.

Like another reply. // MyHello.jsx import React from 'react'; export default ({name}) => Hello {name} ; Now do the same in Angular.

I cannot speak for GP but for me the complexity comes from stitching dozens of libraries to get similar "base" to build the app on. Ember/Angular have way more stuff baked in or standardized, while in React you have to handle ball of ever changing dependencies ... For seniors it's ok(-ish) tradeoff (you get much more choice / control), for juniors it is hell on earth. But that is more of an issue for projects maintai…

What do you need that isn't in the box with React? Aside from fetch, which is in all modern browsers? The new Context component interface pretty much flushes out the last of what you are likely to need. As much so as what you get in the box with Angular. Even then, with Angular you'll usually need at least a visual component library, and with React, disparate components tend to work together with less friction comparatively.

Re: The State of JavaScript 2018

#280

Post by bryanrasmussen »

dentemple wrote: post #263
userbinator wrote: post #121

Earlier quoted context omitted.

Not long ago I had to write some JS (had to, not wanted to) to do something on a site, and got something working based on what I knew, only to be derided by a "real JS developer" that my code was "deprecated", "not following best practices", "not modern", etc. He gave me his version which was around 10x more code and only worked in a subset of the latest browsers, while mine not only did but would probably work in ev…

If his ES6 required 10x more code than your ES5, then he doesn't actually know ES6.

I think he probably doesn't know JavaScript at that point. I remember I got invited to an interview one time and they were impressed by my code for their coding assignment partially because it could print out in less than a page (no minification), and they referred to another applicant whose code had taken 6 pages. And I was just like - how could it take that much code?
Post reply on HN