Live data from Hacker News

JavaScript frameworks and topics to learn in 2017

medium.com

101–110 of 121 posts

Re: JavaScript frameworks and topics to learn in 2017

#101
post #69

Earlier quoted context omitted.

>> don't want and can't use node.js on the server I don't understand, you want a javascript framework to do server-side rendering, but don't want to use node?

No, I want to do server-side rendering using whatever I want, and have the js framework take over once it is clientside.

Please please please look at jQuery-Pjax. It does exactly this. If you have any questions about it, feel free to ask!

Re: JavaScript frameworks and topics to learn in 2017

#102
post #38

> Webpack: The most popular bundler for standard JavaScript look for simple starter kit/boilerplate config examples to get things running fast Unless you're already familiar with a tool, I'd suggest starting with the very Hello, world basics. For Webpack, that's creating an empty project and incrementally adding config, starting with just an entry point (use a simple script importing some modules) and an output filen…

Webpack?!? Somebody didn't get the memo... I think we're supposed to use Rollup [0] now... [0] http://rollupjs.org/

Webpack 2 is where it's at. Tree-shaking was Rollup's big feature and Webpack 2 has it.

Re: JavaScript frameworks and topics to learn in 2017

#103
post #102

Earlier quoted context omitted.

Webpack?!? Somebody didn't get the memo... I think we're supposed to use Rollup [0] now... [0] http://rollupjs.org/

Webpack 2 is where it's at. Tree-shaking was Rollup's big feature and Webpack 2 has it.

That's great, but it ain't there yet. [0] Incidentally, releasing a version 2 without deprecating version 1 seems a bit of a project smell... It might be the right thing to do in a particular situation, but what happened on the project that led to that situation?

[0] Tree shaking completely broken? #2867 https://github.com/webpack/webpack/issues/2867

Re: JavaScript frameworks and topics to learn in 2017

#104
post #86

The only issue with the blog post is that most of those tools will be obsolete before you finish reading. JavaScript as an ecosystem needs mature robust solutions rather than a new way to do things every other week.

That's simply not true. I'm kind of tired of hearing about this kind of stuff said about JS. This comment adds absolutely nothing to the discussion about this article. Did you even read the article before making this comment? It would appear you didn't since this is just a classic, low effort javascript bashing comment that mentions no evidence from the article. Every single thing he marks as important to learn is ei…

This! Lodash turns 5 in 4 months :)

Re: JavaScript frameworks and topics to learn in 2017

#105
post #102

Earlier quoted context omitted.

Webpack 2 is where it's at. Tree-shaking was Rollup's big feature and Webpack 2 has it.

That's great, but it ain't there yet. [0] Incidentally, releasing a version 2 without deprecating version 1 seems a bit of a project smell... It might be the right thing to do in a particular situation, but what happened on the project that led to that situation? [0] Tree shaking completely broken? #2867 https://github.com/webpack/webpack/issues/2867

Not smell just semver – http://semver.org/

Re: JavaScript frameworks and topics to learn in 2017

#106
post #78

Great list! But I was perplexed by the text editors mentioned. Author claims to be looking at trend data, but seems to have a bias against Subljme Text editor. I don't know if there is some connection to Atom or VSCode, but it seems easily verifiable that Sublime and vim are vastly more popular than other editors mentioned, yet Sublime is inexplicably absent and vim is mentioned last and sort of offhand as more of ju…

Sublime is absent because a lot of previous sublime users are now Atom users, and it is now the more popular editor by a large margin. Those comfortable with Sublime will find Atom very inviting.

Re: JavaScript frameworks and topics to learn in 2017

#107
post #69

Earlier quoted context omitted.

>> don't want and can't use node.js on the server I don't understand, you want a javascript framework to do server-side rendering, but don't want to use node?

No, I want to do server-side rendering using whatever I want, and have the js framework take over once it is clientside.

That's easy with both React and Angular.

Re: JavaScript frameworks and topics to learn in 2017

#108

The only issue with the blog post is that most of those tools will be obsolete before you finish reading. JavaScript as an ecosystem needs mature robust solutions rather than a new way to do things every other week.

React is mature and robust now, and still growing in popularity like a rocket. It's not going to be gone tomorrow. Angular 2 is just starting to become stable, but it still uses some ideas pioneered in Angular 1 going on 4 years ago.

It also won't be gone tomorrow. Angular is still the dominant framework by a healthy margin. Yeah, there are newcomers like Vue.js, but they're currently about 1/10th as popular as React.

This "over in 5 minutes" meme in the JS discussions isn't exactly telling the whole story.

Re: JavaScript frameworks and topics to learn in 2017

#109

Earlier quoted context omitted.

No, I want to do server-side rendering using whatever I want, and have the js framework take over once it is clientside.

Please please please look at jQuery-Pjax. It does exactly this. If you have any questions about it, feel free to ask!

That's basically the pattern my company is already using, implementing using our own plugin. We render the full page server-side (using ASP.Net MVC, which is hooked into our server-side Enterprise Application Framework), and then we hook up javascript handlers to manage client-side events. Those handlers can make AJAX requests for content updates, which we deliver either as pure data or server-side rendered html (which are rendered using the same partial templates that the initial page used.)

Depending on the page, we can go anywhere from old-school full-page-refresh to a complete single-page-app design. Mostly we do Enterprise back-office interfaces and customer web portals, both of which tend to have a lot of data grids. So a very common feature of our applications is a data grid that supports paging-in-place, along with server-side filtering and sorting of large datasets. So we'll do that SPA-like, even if the overall site is more of an old-school design where each link loads a new page.

Our plugin does more than just fetch a url; the client side and server side are designed to work together to allow standard options to be passed up to the server along with the request, standardized error handling and content in the response, and standardized ways of handling the response when it gets back client-side.

Post reply on HN