On the react bandwagon for almost 5 years now and haven’t regretted it a single day. Started using it because it allowed me to build d3-type data visualisations but with way more flexibility in terms of hierarchy and grouping of DOM elements in what for me felt like a very intuitive format of components and JSX. So I would say thrust your own judgement when considering which tools! Not all trends are pure hype, there might be something real behind it :)
Do Not Follow JavaScript Trends
71–80 of 275 posts
Re: Do Not Follow JavaScript Trends
#72Earlier quoted context omitted.
> What is possible today that was very hard to do 10 years ago in web dev land? Declaratively writing components and reusing behavior (e.g., hooks) across components/applications was basically impossible with the tools of 10 years ago. The benefit to the user is more stable interfaces and a faster release rate.
> benefit to the user is more stable interfaces Doubt. Websites are constantly redesigning their interfaces so that they can use the latest trendy technology.
Is that the fault of the frameworks for existing? That's like saying we'd be better off if we didn't have so many programming languages.
Re: Do Not Follow JavaScript Trends
#73I'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…
But do we get it? If we get it, why is frontend churn so prevalent? I don’t think we get it.
All client-side development churns. Because it's hard, it runs on user devices in the field. And client development is not a solved problem. It's more a moving target of constant research because client devices aren't static either. It wasn't long ago that touch screens didn't even exist.
The whole Apple client-dev ecosystem is still in the process of changing to Swift, and Apple is trying to develop SwiftUI into a compelling layer alongside/atop {App,UI}Kit. It's not just a web/JS challenge.
Client dev is always changing.
Re: Do Not Follow JavaScript Trends
#74Earlier quoted context omitted.
But do we get it? If we get it, why is frontend churn so prevalent? I don’t think we get it.
Is front end churn really so prevalent? I hear this opinion all the time, but React is 7 years old. I've been using it for around 5 years, I think. Redux is 5 years old. How old does the most popular web framework need to be before we consider it to be low churn? [Edit: Also, anecdote: before JS, I was mostly a C# developer, and the churn there was at least as bad, maybe worse in my personal experience. Over 15 years…
JS has always been relevant as an ecosystem because it incorporates new ideas. I liked jQuery more than what came before it, and I like React more than jQuery. They make the task of translating an idea into a work app much easier for me, and other programmers I work with also benefit from more readable code.
I wouldn't re-write an existing app to use fetch or hooks, but now that I've taken the time to learn, I'm happy I did. The vast majority of the mental work was done by other people, and I get to reap the benefits. The alternative to this is stagnation, and relegation to legacy systems... I guess the author wishes they could work in COBOL?
Re: Do Not Follow JavaScript Trends
#75Earlier quoted context omitted.
in the negative, I agree. I see all the hype around React but when I use Facebook.com I am thoroughly underwhelmed.
Eh? You can't "tell" what framework a site is using just by interacting with the site. What you see is what the designers decided. A better proxy, though weak, would be the number of UI bugs you encounter. The best metric would require you to have insider knowledge, to see how much work is saved by reusing components and writing them declaratively.
Might just be a firefox thing, or a symptom of my ad-blocker, but facebook and the reddit redesign are both pretty terrible performance wise. The thingiverse redesign seems performant though so I don't know.
Re: Do Not Follow JavaScript Trends
#76Shiny new thing (SNT) comes along, sales people and thought leaders get excited about SNT because they can sell it, everyone piles on as SNT picks up more and more hype, SNT falls apart as soon as it hits real world use cases, sales people and thought leaders start looking for new SNT and the cycle repeats. I can not stop the cycle. You can not stop the cycle. All we can do is notice it and let it pass and hope some…
That is a great article!
Thanks!
BTW: I did write a bit about this phenomenon, here: https://medium.com/chrismarshallny/concrete-galoshes-a5798a5... (Scroll down to "It's Not An Either/Or Choice")
Re: Do Not Follow JavaScript Trends
#77Let 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…
My argument for using axios is developer ergonomics. There are a few libraries that I use both in the frontend and the backend, for which I gladly accept the increased bundle size: axios, lodash, moment, Q. My users get the benefit in me being able to ship features faster because I don't have to constantly keep up with which feature ships in which browser version etc. I also found the fetch API horrendous to use. It'…
Do you take on the entire of Lodash as a dependency?
If so, do you use any of the Lodash features not described here?[0]
If you use more than described, or if a specific Lodash feature is more performant, you can selectively import[1].
[0] https://github.com/you-dont-need/You-Dont-Need-Lodash-Unders...
[1] https://www.npmjs.com/search?q=keywords:lodash-modularized
Re: Do Not Follow JavaScript Trends
#78I feel like these problems are endemic to React and the surrounding ecosystem. Since its introduction in late 2016 Angular 2+ has had no major changes on the scale of hooks and is unlikely to introduce them, because its target audience - large companies making large-scale applications is fairly conservative. Vue I think had one measurably large syntax shift around v2.5(or 2.6) and will have another one with 3.0, but…
> 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 to be used in multiple such projects done by very different organisations.
Personally, I hope that server-side rendering will be the new ~old~ trend.
Users don't tolerate the inherent delays caused by this approach anymore.
All those hoops current frameworks are jumping through so that we can eat the cake and have it too are there because of this.
Re: Do Not Follow JavaScript Trends
#79I feel like these problems are endemic to React and the surrounding ecosystem. Since its introduction in late 2016 Angular 2+ has had no major changes on the scale of hooks and is unlikely to introduce them, because its target audience - large companies making large-scale applications is fairly conservative. Vue I think had one measurably large syntax shift around v2.5(or 2.6) and will have another one with 3.0, but…
As an outsider, I feel like React both does too much (a virtual DOM? Aren't current web standards enough to make a flower shop website?) and too little -- there's all these terms/technologies/subframeworks that people are using like "create-react-app" and "Redux" and so on. It's neither an overarching architecture that makes normal web technology obsolete but runs on it, like Windows 95, nor a website generator like…
> As an outsider, I feel like the Model-T does too much (an internal combustion engine? Aren't current horses enough to carry our wagons?)
If you don't need a virtual DOM, nobody will judge you for not having one. But once you really feel 'behind the wheel' of a framework like react or vue, it's hard to go back. Not only is it easier to hack out something quick over a weekend, it's also more suitable for collaborating large, complex applications.
Re: Do Not Follow JavaScript Trends
#80Earlier quoted context omitted.
Serious question, why do they need to know anything about creating prototypes?
The argumentation went like: We did design projects for companies and showed them our ideas as mock images and they didn't like them. We then implemented the exact same designs as prototypical apps, they clicked around in it and loved it.
Oh, that makes sense. I thought you meant Javascript object prototypes!