orange8

23 ms·

211.
by orange8 7y ago
I agree with you about the React team being very careful about maintaining backwards compatibility as much as possible. The API is however still a moving target, and some patterns or ways of doing things are actively pushed more than others
212.
by orange8 7y ago
> Probably a side-effect of what I usually choose to comment on, which are things that are objectively wrong or seriously misleading :) I think the HN voting system is poor, so I don’t use it, myself. Do you have any evidence that you do
213.
by orange8 7y ago
Let me get this straight: Are you saying all the changes in arrow functions, the class syntax and generator functions were all a carefully planned initiative to get rid of the "function" keyword because it does too much?
214.
by orange8 7y ago
> ... and having that declarative rather than imperative is a huge win. The alternative used to be using a template engine like handlebars While React markets itself as a declarative DOM manipulation library, any kind of HTML templating
215.
by orange8 7y ago
> The querySelector method executes thousands of times slower than the other more specific methods Do you mean this literally?
216.
by orange8 7y ago
How do you deal with IE 11?
217.
by orange8 7y ago
The rule you link to is specific to "function expressions", which may or may not use 'this'. To ask the same question differently, what about functions that do not need 'this'?
218.
by orange8 7y ago
It is much more than a matter of code style. For example, an arrow function accessing variables outside its scope is much slower, something you will notice when processing a lot of data in nodejs. And if you're working in the browser a
219.
by orange8 7y ago
I agree, but do all functions use 'this'?
220.
by orange8 7y ago
And when you don't need any of that, how do you signal that you do not need it?
221.
by orange8 7y ago
I agree with one and two, and really appreciate arrow functions in those two, and other appropriate use cases. With three, I disagree. It is kind of like saying let us just use var everywhere to be consistent.
222.
by orange8 7y ago
> they got selected by the ecosystem because they were GREAT homegrown solutions While React has lots of great ideas, good marketing and the facebook brand is really what boosted its popularity. Popular does not necessarily mean great. T
223.
by orange8 7y ago
const doThing = event => {} function doThing( event ){} Why does everyone seem to be using the first format? Isn't the second version a lot more readable/pretty? Even worse is when doThing is immediately exported and not reffer
224.
by orange8 7y ago
> Currently I'm stuck with a codebase with almost no documentation of a mess of legacy and new code with layers and layers of developers' opinions on top. If it was originally built using a framework, what framework do you thin
225.
by orange8 7y ago
A good indirect example is an actual feature added to JS recently, which are classes. Classes are the main unit of OOP, while functions are the main unit in the functional paradigm. The class syntax in JS is not a real new structure added t
226.
by orange8 7y ago
>> you don't "lose" anything: you actually gain more "flexibility" and more "language" patterns. You do not need TS to use OOP language patterns in JS. Remember TS is compiled down to JS, so all that
227.
by orange8 7y ago
I may have shaved a few years here and there to calculate that decade ;) I'm still waiting for a browser to come with an inbuilt server like netscaape 3.
228.
by orange8 7y ago
Am comfortable using both OOP and functional styles, though I do enjoy the flexibility and terseness that can be produced from the functional approach. What I meant by the comment is that when using TS, I just find it more easy and natural
229.
by orange8 7y ago
I agree, that's why I said TS aims to model a strongly typed languange.
230.
by orange8 7y ago
> It doesn't matter what your definition of a language feature is. The person you responded to was obviously talking about interfaces in the general sense of the word and was asking a question about it. Really? So now this has devol
231.
by orange8 7y ago
LOL!! |s
232.
by orange8 7y ago
> Do not use random libraries. A good library should have even some basic docs outline its API and how to use it. >>Hearing this assurance from someone who just complained about their jenga tower of tooling causing issues, I'm
233.
by orange8 7y ago
>> Then you have interfaces. Not really. My definition of a language feature is something the compiler supports and checks for. JS does not have interfaces. What you're talking about are patterns and best practices, so you'r
234.
by orange8 7y ago
\s or /s Dont care. Small minds, small arguments. Atleast you're consistent that way
235.
by orange8 7y ago
> javascript is just typescript with documentation stripped off. JS, at its core is a dynamically typed, functional language. Typescript aims to model a strongly typed, OPP language. The two programming paradigms have their own strength
236.
by orange8 7y ago
> I'm not sure whether you intended this to sound so patronizing, but wow. What languages should I explore while talking about Javascript? Why would the suggestion to explore non OOP, strongly typed languages sounds patronizing to y
237.
by orange8 7y ago
Wow! What a mature, thoughtful response \s Only the first and last sentences actually addressed the topic, the rest was just an angry emotional attack on those who think differently from you. Hope you're feeling better now.
238.
by orange8 7y ago
I'm not a myth. Some of us started JS programming over a decade ago, with no strong typing and IDE to hold our hand and tell us every time you make a mistake. The key is just discipline, good design patterns and a good linter. I see Ty
239.
by orange8 7y ago
Sorry it did not work for you as an individual, but turning that around to say that anyone else with a more positive experience is just placebo is a bit of a logical fallacy. Why do you think your own personal experience should be the one s
240.
by orange8 7y ago
The comparisons are valid because for 99% of the web apps out there, the makers could have gone with either angular or react. Regardless of the underlying philosophies, the choice between React, Vue and Angular is a very real one businesses

More ›