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

101–110 of 275 posts

Re: Do Not Follow JavaScript Trends

#101

Post by dpweb »

I think either vanilla js, or the other route, a full blown batteries included, like Visual Basic 6 was for windows development. Either abstract away nothing, or everything.

In the middle, is developing with a framework. The problem is you have to know the language + the peculiarities of the framework. New frameworks and "features" happen on too short a timeframe. And, frankly, it costs too little to just invent a new framework. So, 10000 frameworks.

There is a mental cost that increases exponentially with every layer of abstraction. When people have to post questions about why they can't understand such "features" of panacea x , that's the problem.

Re: Do Not Follow JavaScript Trends

#102

Post by brailsafe »

JMTQp8lwXL wrote: post #99
mxschumacher wrote: post #5

A good way to not be completely overwhelmed by all the new tooling and frameworks is to have a strong grasp of the fundamentals, here are three foundational resources: "You don't know JS": https://github.com/getify/You-Dont-Know-JS "How browsers work": https://www.html5rocks.com/en/tutorials/internals/howbrowser... "High performance browser networking": https://hpbn.co/

Somewhat agree. Fundamentals help, but understanding them won't immediately clarify every configuration item in a Webpack configuration.

That's true, but nothing will.

Re: Do Not Follow JavaScript Trends

#103

Post by Softcadbury »

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 agree for frameworks, but building tools and package management are still nightmares for me

Re: Do Not Follow JavaScript Trends

#104

Post by underbluewaters »

As a software developer I consider the most important part of my job to be evaluating new tools and techniques. This craft is in its infancy and our profession borders on complete incompetence when it comes to predictably building usable tools at a reasonable budget. Nobody can afford to miss out on productivity enhancements and that means following trends, but with a critical eye. If someone is "tired" of this process it might be time to consider another profession.

Re: Do Not Follow JavaScript Trends

#105

Post by crooked-v »

duxup wrote: post #86
julianeon wrote: post #69

Earlier quoted context omitted.

I’m personally becoming frustrated by the “we draw the line at React hooks” idea - which I feel like I’m seeing repeated. Like that’s the point at which learning new concepts crosses over from useful exercise to useless extravagance. So let me say something which is true, but totally against the spirit of this article: there should be 10x as many (!) tutorials about how to implement everything in React using hooks. M…

Yeah hooks have such a low barrier to entry as far as ... just make a new component with hooks. There is less code, it's easy to do, anyone who has seen a class component doesn't need much of an introduction to understand it. I've got class heavy applications that will stay class heavy, but almost all new components are hooks and they're quick to write, evaluate what is going on, and work with.

For me, the key thing about hooks is that they both make it easier to write everything idemopotently and mostly force you to write everything idemopotently, both of which are great for future code maintenance purposes.

Re: Do Not Follow JavaScript Trends

#106

Post by draw_down »

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…

Blessed sanity. Great post, thank you.

Re: Do Not Follow JavaScript Trends

#107

Post by Aissen »

Let's reverse the question: if you didn't follow the trends, were a decision maker, and wanted to bet on a frontend "framework" for the next 10+ years for a greenfield (or full rewrite) project. What would you chose in 2020 ?

From where I stand, it seems vue or react aren't going away anytime soon. But the same could be said of angular, ember, and probably many others. What would you chose and why ?

Re: Do Not Follow JavaScript Trends

#108

Post by brailsafe »

protonimitate wrote: post #56
duxup wrote: post #9

I'm a little lost on the examples. There are reasons to use fetch and hooks, and the article seems to relegate them to being unnecessary 'trends' without doing what it suggests, actually evaluating what value they might have... In React you can use hooks with a class heavy application and still be just fine / get the benefits of hooks in a given component(s). If you want to use fetch, that also is hardly an ordeal to…

Yeah, I'm becoming increasingly frustrated by the flood of "anti-hype-driven-development" blog posts being praised. The entire article could be summed up with: > Is it solving your problem, and what is the cost? And it cuts both ways. Change for the sake of change is bad. But so is stagnation for the sake of stagnation. Picking the best tool for the job and continuous improvement are the closest thing to universal ad…

I think the idea is to disassociate newness from improvement and only associate it with improvement when it's actually improvement. It's not wise to pick a different tool for every job, nor is it wise to only stick to one tool all the time. The fatigue imo comes from producing approximately the same output in ever more complex but not necessarily more interesting or better ways. If it does arguably provide a marked improvement, then definitely experiment and see how it might help

Re: Do Not Follow JavaScript Trends

#109

Post by dlbucci »

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 have to chime in as someone who created an Angular.js app in 2017. I suppose it happens. Not that I actually wanted to, I was just working with a dumbass who overruled me. I don't really have anything it say, I just have a really strong negative association with this specific topic, I guess...

Re: Do Not Follow JavaScript Trends

#110

Post by yxhuvud »

Tade0 wrote: post #78
mark_and_sweep wrote: post #40

Earlier quoted context omitted.

> Since its introduction in late 2016 Angular 2+ has had no major changes As someone who has used Angular 2 since beta, I can tell you, it's been a bumpy ride nonetheless. > its target audience - large companies making large-scale applications - is fairly conservative React was built for Facebook, which is a large company building a large-scale application. > All this won't matter once the next gen compiler-framework…

> As someone who has used Angular 2 since beta, I can tell you, it's been a bumpy ride nonetheless. Oh yeah. I remember the "let's just apply the good parts of AngularJS here and there" in v4-6. "React was built for Facebook, which is a large company building a large-scale application." One large scale application, which is not enough to create stable conventions that are badly needed in a framework that's supposed t…

> Users don't tolerate the inherent delays caused by this approach anymore.

Well, I certainly also do not tolerate the delays in contemporary React sites either. Take Reddit for example, which used to be lightning fast when it was mostly serverside, which now is painfully slow, especially on mobile.

Post reply on HN