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

Do Not Follow JavaScript Trends

pragmaticpineapple.com

Post reply on HN
Print view View original

131–140 of 275 posts

Re: Do Not Follow JavaScript Trends

#131

Post by wnevets »

andrewl-hn wrote: post #92

I vividly remember 2016. I was doing backend programming at the time, but no one I knew were using Angular.js at that time for new codebases. React emerged in 2013, by 2014 the hype was at full swing, and by 2015 React "won" the framework battle. It's been 5+ years since then, and React JavaScript world was remarkably stable. Fashion changes were largely superficial: React.createClass vs ES classes, Heavy use of Deco…

What do you mean, everyone is now updating their codebases to remove redux, HoF and switch to hooks.

Re: Do Not Follow JavaScript Trends

#132

Post by sdfhbdf »

joshribakoff wrote: post #64

I find it interesting the blog post mentioned Kent Dodds article recommending everyone rewrite fetch. I just argued adamantly against Redux docs about writing tests being switched off of Enzyme to his library because it’s “more trendy”. https://github.com/reduxjs/redux/pull/3708 Unfortunately, the community overruled me and the docs no longer show how to test Redux apps with enzyme. It only shows Kent’s “react testin…

I looked through Your comments. Seems like the compromise You suggested didn't go down well. I understand the maintainers POV - just avoid the flamewars. I liked Your soluton of weighing pros and cons of the different libraries. Maybe the next step would be to create a PR to add enzyme back as a suggested alternative and just build of off this PR?

Re: Do Not Follow JavaScript Trends

#133

Post by torb-xyz »

andrewl-hn wrote: post #92

I vividly remember 2016. I was doing backend programming at the time, but no one I knew were using Angular.js at that time for new codebases. React emerged in 2013, by 2014 the hype was at full swing, and by 2015 React "won" the framework battle. It's been 5+ years since then, and React JavaScript world was remarkably stable. Fashion changes were largely superficial: React.createClass vs ES classes, Heavy use of Deco…

Yeah I have to say I agree. I think there was valid reasons for some of the framework churn early on (basically no proper standard way to do client side GUI). When the MVC-oriented stuff started to stabilise we all discovered that functional reactive programming UI was a good thing and that drove stuff like React and Angular 2.

But there simply hasn't been a paradigm shift in UI after that (and I doubt there will anytime soon, it's not often a whole new UI paradigm that changes stuff the way MVC and FRP have done is popularised).

Stuff like Vue and Svelte are simply attempts at optimising or improving the reactive approach, but is basically still fundamentally the same idea. Someone versed in React would easily move over.

Re: Do Not Follow JavaScript Trends

#134

Post by throwaway286 »

andrewl-hn wrote: post #92

I vividly remember 2016. I was doing backend programming at the time, but no one I knew were using Angular.js at that time for new codebases. React emerged in 2013, by 2014 the hype was at full swing, and by 2015 React "won" the framework battle. It's been 5+ years since then, and React JavaScript world was remarkably stable. Fashion changes were largely superficial: React.createClass vs ES classes, Heavy use of Deco…

I don't think hooks are a superficial change. If react stayed with class based components, I'd agree with you.

Re: Do Not Follow JavaScript Trends

#135

Post by sdfhbdf »

wereHamster wrote: post #29

Let me make the argument against axios. Even if you are happy, your users may not. Axios (btw still on version 0.x despite being one of the older javascript packages, means it can introduce breaking changes without any warning, think about that) adds 4.4kB (minified+gzipped) to your bundle. Do that a few times and you have hundreds of kB of additional code your users don't need to download (and execute!). If all you…

In the end fetch was supposed to supersede all these libraries. Unfortunately in cases like this seems like Node.js, and JavaScripts's lack of standard library really shows. Every developer will use whatever either they encounter first because they don't feel like learning a new shiny library or whatever is the most comfortable and maybe not right. NPM has its positives - discoveriblity being one for sure but also its drawbacks - million ways of accomplishing the same thing.

Axios after fetch being standard everywhere starts to feel like jQuery after document.querySelectorAll being available everywhere.

Re: Do Not Follow JavaScript Trends

#136

Post by mettamage »

wegs wrote: post #118
andrewl-hn wrote: post #92

I vividly remember 2016. I was doing backend programming at the time, but no one I knew were using Angular.js at that time for new codebases. React emerged in 2013, by 2014 the hype was at full swing, and by 2015 React "won" the framework battle. It's been 5+ years since then, and React JavaScript world was remarkably stable. Fashion changes were largely superficial: React.createClass vs ES classes, Heavy use of Deco…

Rewrites only make sense if you get a multi-fold improvement. In the history of computing, that's rare. So they rarely make sense. Well, JavaScript was really horrible when it came out. It was just about the worst major programming language ever made. It sort of reminds me of an interpreter I threw together for a programming language I invented when I was in high school, when I really didn't get any aspect of program…

How about using Typescript? That still seems like a huge improvement, especially because you can implement it incrementally (aka for parts of code where type checking is vitally important).

I'm using it now at my work and I'm surprised how much info I'm getting compared to whatever JS is throwing at me.

Re: Do Not Follow JavaScript Trends

#137

Post by ChrisMarshallNY »

memexy wrote: post #55
ChrisMarshallNY wrote: post #42

Not just JS. JS is an enormous ecosystem, so it shows this issue, but pretty much all tech (and other industries, as well), have the same problems. We can have problems when folks start suddenly painting "The New Thing™" over classic designs and architectures. In my experience, that's even worse than rewriting everything. Also, it can become a requirement for hiring, because some manager, or their "top tech," have su…

I once worked with a group of people that were afraid of makefiles. I doubt it was your age. People are always afraid of things that are unfamiliar. This applies to snakes and spiders just as much as it applies to programming languages and associated technologies.

> I doubt it was your age.

Wish I could share your confidence, but I have run face-first into this phenomenon.

[...removed some stuff that I don't feel like backing up...]

We are an unpopular bunch. It used to get me quite upset, but I’ve learned to make it quite clear that I am no youngster; right up front. Avoids stuff like what I mentioned.

Re: Do Not Follow JavaScript Trends

#138

Post by dpix »

One problem I have with that hype cycle diagram is that it appears to show that all technologies that get a lot of hype will eventually even out and get good adoption once they go through some growing pains.

Realistically though a lot of new tech will get into the hype stage and then everyone will realise that is in fact no good or just disappear for some other reason.

People see that diagram and think it doesn't matter if you jump in at the hype stage because eventually this tech will become mainstream, when a lot of the time that graph just drops to zero after the hype stage.

Re: Do Not Follow JavaScript Trends

#139

Post by kqr »

furstenheim wrote: post #68

The user does care. At a previous company we started migrating from angular to vue. Vue was so fast that those parts would be completely rendered and the rest would be white. It was also snappy. Of course, one has to be mindful about the transition. You cannot stop business, but you can take a little extra time whenever there's need to modify a section to improve quality (both code and ui). Actually that's why we cho…

> BTW, someone had the "great" idea of not using a framework for an internal admin portal. It turned immediately into a huge ball of mud.

It's never the case that you "don't use a framework" for something like that. You'll use a framework, alright. The choice is between using something well-built based on best practises as we know them, or... building it yourself. Other than in very rare circumstances, I fail to see the point of reinventing that wheel. UI frameworks (web front-end or not) are a quagmire of edge cases and other infinite time sinks.

Re: Do Not Follow JavaScript Trends

#140

Post by nailer »

hajile wrote: post #117
nailer wrote: post #98

Earlier quoted context omitted.

> Kinda funny the author refuses to evaluate a five-year-old (?) standard (fetch), labeling it a trend/hype. And what are they holding onto? Fetch is a very poor standard if you compare it to high-level HTTP clients that have been around since 2010-ish. However it's author states that it wasn't intended as a general purpose HTTP library but rather a low level tool that-level tools can make use of. So yes: you probabl…

Lots of us remember the days of XmlHTTPRequest. Fetch is downright modern in comparison. You should understand how your browser actually works and in this case, it's actually gotten a lot easier.

I don't think you quite understood the point: XHR was not fetches predecessor, because few people were using XHR directly when fetch was being designed and released.

superagent was released in 2011, axios was released in 2014 (jQuery also had an HTTP client that was nice but I don't know much about it). Both of these libraries were wildly popular and do more out of the box than fetch (which came later) does.

Standards should pave cowpaths. Fetch was designed in a bubble.

Post reply on HN