I think Software Engineers' role is to pick the right tool for the job - taking into account all the advantages and drawbacks of each one. Following the trends is a good way of knowing if any of the drawbacks of the previous tools were alleviated in the new ones. Of course the refactoring time must also be a deciding factor in a switch - most of the times it won't be worth it. I think what the author meant was don't follow the JS treds blindly.
Do Not Follow JavaScript Trends
171–180 of 275 posts
Re: Do Not Follow JavaScript Trends
#172Earlier quoted context omitted.
> TS feels way closer to Java than to JavaScript You and I clearly have different understandings of Java, JS, and/or TS. Typescript's structural typing feels like the opposite end of the spectrum from Java's nominal types.
> Typescript's structural typing feels like the opposite end of the spectrum from Java's nominal types. Be that as it may, I said nothing about type systems. I said that TS feels closer to Java than it does to JS. Seeing as JS has no type system, I fail to see your argument.
> Be that as it may, I said nothing about type systems.
Typescript is nothing more and nothing less than a language that adds static typing to Javascript. Any discussion about how Typescript changes the feel of Javascript is a discussion about type systems.
> Seeing as JS has no type system, I fail to see your argument.
Javascript absolutely has a type system. It's not static, and there are lots and lots and lots and frankly too many ways to automatically coerce types, but it definitely has a type system.
Re: Do Not Follow JavaScript Trends
#173Earlier 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…
I'm just now getting back into webdev after 3 years. Can you please recommend a good tutorial/demo using Hooks? Especially if it's using Typescript! I strongly dislike the create-react-app project because it abstracts everything away.
For react hooks: the base results are decent, for that particular search phrase. You won't go wrong with the reactjs docs, prominently placed there.
https://reactjs.org/docs/hooks-intro.html
For react hooks typescript: sorry, I can't. This is a pretty good example of the problem, because I just searched Google's first page of results for react hooks typescript tutuorial, and they were all bad.
3 of very top results seemed to be a derivative of each other, where they presented a list of concepts, which is not really relevant in teaching you to use them.
Some of the other ones were a very slight improvement, but still not good enough that I'd feel very comfortable recommending them.
On the 1st 2 pages of results, this was the best result I found for react and typescript (not hooks), which at least addresses the topic directly with relevant code.
https://www.educative.io/blog/react-and-typescript
Also I want to call out this example for being especially ridiculous, because it titles itself as "Using React Hooks with Typescript" and then doesn't actually use any Typescript!
https://blog.usejournal.com/using-react-hooks-with-typescrip...
Anyway, this nicely illustrates the problem. I may try to write a tutorial on this myself, after seeing how bad these are. But for now, this is what's out there.
Re: Do Not Follow JavaScript Trends
#174Earlier quoted context omitted.
Typescript doesn't strike me as a multi-fold improvement. Dynamic vs static typing is an age-old debate, and in general, advocates can be found arguing that moving your code in either direction results in benefits. So, regardless of your stance on it, it seems unlikely to be unambiguously beneficial. Many large programs exist written in dynamic languages that do just fine.
It seems like it's trending toward static, at least recently. I think the big driver for this is the popularization of statically typed languages that aren't C++ and Java. A lot of people had painful experiences with C++ and Java and attributed that pain to static typing. It's now more clear that static typing is a net benefit, but it must be implemented reasonably and it doesn't solve other language design issues. A…
Hard to say. It seems as cyclic as anything else. Hard to tease apart real benefit from the usual fad/hype cycles.
Ruby, Python, Erlang/Elixir, Lisp/Clojure, etc, all doing just fine without it. (Some, with some lightweight annotative-oriented typing for a subset of projects.)
The best counterargument to static typing I can articulate is that in general, the only way to be sure software works is to run it. And so, ultimately you need to backstop your software with testing, QA, and observability infrastructure to actually execute it and validate it. At that point, the question is what marginal gains remain from catching a subset of those problems at complile time, also incorporating a potential a false sense of security which may lead to less actual execution validation, and more user-facing issues. The other potential tradeoff of static typing is if the software design and architecture changes for better or worse, or if the velocity of shipping changes changes. I believe there isn't yet any hard evidence of which way this tilts in either case.
There's also a lot of innovation in the area of validation-by-execution as well, and so I think that will result in continual debate: state-of-the-art static typing may benefit compared to yesterday's testing/fuzzing tools, but may not compared to state-of-the-art testing/fuzzing tools, for example.
Re: Do Not Follow JavaScript Trends
#175I 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…
Angular(1) wasn't simple but knowing basic stuff made it possible to do complicated things quickly. Angular lost a lot of momentum when they decided Angular had to look like JEE and become a framework trying to justify its existence with complexity. React had the right idea, just make view management simple, don't force some bullshit IoC container on Javascript and that's it. If you want IoC that's your problem. Ulti…
I see it a little differently, Angular 1 lost momentum because it was a bad framework. It was clearly written by people that did not have a lot of experience productionalizing code. Further they choose new and convoluted naming for concepts that already had names. The came up with a creative new way to introduce globals thru rootscope and performance was abysmal. Their component model was leaky at best and the whole framework encouraged writing monolithic controllers that where in the same vain of Backbone.js. There where actually good frameworks at that time such as Dojo they just did not get the mindshare that Angular got and a lot of that was due to it being incubated at Google. The second part of the issue is there where not many people doing hardcore Javascript programming and so there was not a depth of deep CS knowledge in the front end space. It took more and more of them reluctantly converting over, getting one look at Angular and going look guys this is bad because of X,Y and Z. Angular 1 actually set the state of the art back compared to some of the other offerings at the time. The absolute tell, was when the team had to admit it, admit they where going to scrap it for a total rewrite that was to become Angular 2 and on.
The reason React has done so well, is that core team members had deeper CS experience, understood other paradigms for UI development and understood that the best state of the art for UI right now, is a render loop. If you converted it to C, squinted at it long enough you would see the very old, very tried and very true Windows render loop in it. They took a proven pattern, bolted it to the virtual DOM and brought it to the web. They did not perform miracles, they stuck to what has been proven to work. Well the virtual DOM was a pretty clever hack, but the rest is UI dev 101. The problem was most the JS developers at the time, never had that back experience of desktop UI development and a good deal of them had come to development by way of learning HTML, CSS and then bits and pieces of JS as they needed to.
Re: Do Not Follow JavaScript Trends
#176Earlier quoted context omitted.
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.
In my opinion, if you're going to add a compilation stage to your bundling anyway, you can get far more mileage out of other options (such as Fable) than the tiny improvement TypeScript is.
The additional compilation complexity is not worth the small benefits of TypeScript, in my opinion. An even better language, though? I'm in.
Re: Do Not Follow JavaScript Trends
#177Earlier 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.
When a website loads displaying a spinner or a splash screen, you know it was made with some heavy framework, it's going to be slow, it's going to break a number of estabilished web UX paradigms (such as scrolling, history or the ability to open links in new tabs) and your phone will feel warm in your hand. You just know.
Re: Do Not Follow JavaScript Trends
#178I just wish more developers would stop trying to improve their products by chasing the newest, coolest standard, and instead work on fixing bugs. But that's not en vogue these days.
Re: Do Not Follow JavaScript Trends
#179Almost every time it is better to invest in learning your framework well and learning patterns to work around framework's issues rather than learning a new framework. First, it is naive to think the new framework does not have any problems. Marketing would like you to think everything is perfect but if that ever happened, why do we have new frameworks all the time? Second, you will pay with decreased productivity whi…
I forgot to mention there is actually one reason to learn new frameworks and it is to educate yourself on the tools that are available. If you do it correctly you can get 90% benefits with 10% effort.
Just don't decide to build your new production application with a framework that you don't know or did little more than hello world.
Re: Do Not Follow JavaScript Trends
#180Earlier quoted context omitted.
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.
I would avoid doing state management in Typescript. It's still too early in my opinion. Use as many hooks and context as possible and keep your redux store as simple as you possibly can because if you end up with a deprecated state management library (redux-thunk, sagas, easy-peasy) replacing that is like pulling gum out of hair. If you add up the time spent working around typescript errors when dealing with state, i…
I'm a Redux maintainer, and I'm _strongly_ in favor of using TypeScript for any meaningful app development [0] [1].
Also, I don't know why you're referring to thunks and sagas as "deprecated". Thunks are the recommended default approach for async logic in Redux [2], and we include them out of the box in our Redux Toolkit package [3]. While most apps don't need sagas, they're a great power tool to have in your toolbox. Neither of those is in any way "deprecated".
[0] https://blog.isquaredsoftware.com/2019/11/blogged-answers-le...
[1] https://redux.js.org/style-guide/style-guide#use-static-typi...
[2] https://redux.js.org/style-guide/style-guide#use-thunks-for-...
[3] https://blog.isquaredsoftware.com/2020/02/blogged-answers-wh...