> I’d probably fire someone if I started to see `JSON.parse(…)` everywhere in a codebase just for “performance reasons” …
Yep, and I'd fire you for doing that! There are better ways to manage instead of showing off your authority. Oh, and by the way, would some JSON.parse statements for performance be the worst thing in your codebase(s) you guess? I mean, I cannot believe that would be the worse in your codebase. Also, if it really helps to use some JSON.parse for creating big objects for performance reasons, who cares? Instead of firing 'someone' maybe you can add some annotation to it for readability (or if that is below your imaginary level, ask the developer if he/she can add that).
Sry, but I hate people that misuse their authority by imposing their subjective opinions.
You're extrapolating quite a bit from a simple comment, which tells me that you'd probably be a poor manager as well. Then again, I'm extrapolating quite a bit as well.
Seeing something like JSON.parse throughout the code is definitely a code smell and could decrease the maintainability of the codebase, and that's a very tangible problem. Obviously you shouldn't fire someone over something like this if it's the first offense, but it definitely raises red flags and should make you monitor things a little more closely. If they show a pattern of dogmatism and poor judgement, you're probably better off finding someone else with better judgement. You're not going to find a perfect employee, but some employees are just better at making decisions for a larger project than others.
Interesting how typescript plays into this - I mean back in the wild old days of plain old JS I would be totally fine with putting a JSON.parse here and there, especially on the hot path.
But now with static types - this would totally wreck static type checking. And you would need to spend additional cycles to validate that the data is actually correct.
Definitely a change request in the PR.
This has to be probably a really big validate perf advantage to warrant the loss of static checks.
Typescript gives you type checking if you import from a JSON file. (Node handles JSON imports and webpack will happily build that for you into a JSON.parse in a bundle.)
That would just obscure the lie. I'd rather see an explicit `as T` cast at the call site to make the "trust me, typechecker, I know what shape this is" claim be in-your-face instead of hidden behind a type parameter.
(This reply assumes you're not asking for TypeScript to make a major philosophical shift and start generating runtime code to validate types. If you are, that's a discussion worth having but goes way deeper than `JSON.parse`.)
> Oh, and by the way, would some JSON.parse statements for performance be the worst thing in your codebase(s) you guess?
One thing I have seen from managers who don’t work regularly in the codebase — they tend to over-focus on things like whitespace and function names more than correct abstractions, separation of concerns, etc.
That’s the compiler/minifier’s role anyway, to use the best construct when appropriate.
See Java’s whole “abc”+”ced” vs StringBuilder performance issues. When programmers have to alter readability for performance, it doesn’t necessarily mean they shouldn’t do it, but it means the precompiler is not advanced enough.
Readability is crucial in code. If you have to through and change the JSON that's being parse and it takes a nontrivial amount of time, that's a big setback. Sure, it's 1.7x faster (in v8) to parse JSON, but how long does it take to parse 10kb of an object literal in the first place? Given that these static, large objects are not common place in a codebase, is it worth the tradeoff?
The precomiler, such as Babel, could introduce a plugin for this sort of optimization. We only write ASM when it going to significantly change the performance characteristics, and typically when a particular code path is run many, many times throughout an application. If an object literal like this is getting parsed that frequently, there are better ways to optimize so that doesn't need to happen at all anyway.
I could see this being very useful in a variety of applications, such as server side rendering. However, its would be best to happen in an optimization phase as you're already bundling at that point.
That was a weird era in Java history. They changed the compiler in the subsequent major version to perform that transformation automatically, but by then people had had 2 years to stare at perf graphs looking for bottlenecks.
It never was clear to me why they didn't do both of those in the same release. Backward compatibility wasn't the problem (they were already breaking that left and right).
Even better, I think Eclipse’s Java compiler introduced the optimization in a given version, but Maven hadn’t yet. So it wasn’t optimized in production, but was optimized on the developer’s machine. What a time to be alive.
Java devs saw that "abc" + "def" involved expensive String concatenation, so as a performance improvement they pro-actively, and effectively manually, changed to use explicit StringBuffer concatenations.
When the compiler switched to generate StringBuilder (unsynchronized) concatenations for "abc" + "def" nobody benefited, because they had already changed to use StringBuffer (synchronized).
Now they had to go an undo all of their hard, manual, optimization work.
I'm done with React. They keep re-inventing the wheel, and every iteration is full of issues that need to get resolved with yet another design principle.
I'm also frustrated with the introduction of a completely new paradigm, but to be fair to the React team, hooks are really innovative and don't re-invent the wheel at all. I, for one, have never used another framework that had anything similar to hooks.
> it's actually dangerous for your project to NOT be written using TypeScript today.
Wow! Bye bye Javascript! Such arrogance! In a way it always feels like Typescript developers are way beyond all those poor suckers still coding in Python, Javascript, Ruby, Coffeescript, etc.. Dynamically typed languages are DANGEROUS!!! just as C is DANGEROUS!!! I'm so happy C is still being used and not abandoned in favor of C# or so.
I know I can be way more popular preaching Typescript nowadays, it would make me really cool, smart and up to date. Not going for Typescript proves I'm mediocre at best. This is not cynic, this is real when I talk to fellow web developers.
I believe static type checking should ideally be done by the IDE, we shouldn't need an entire new language for that with all its shortcomings, issues and whatsoever. And we'll see what's left when the hype is over and the next big thing in the Javascript world comes around. At least heaps of Typescript code bases that need to be rewritten.
> static type checking should ideally be done by the IDE, we shouldn't need an entire new language
I am not sure what you are trying to say here. Javascript is barely typed, so presumably you do need a new language to perform type checking.
Unless you mean that your IDE should be able to infer types, which is unlikely because typing defines intent, and we've all read plenty of code where we can't figure out what the code author intended.
Your comment seems to be a result of ignorance of what TypeScript is and how it works.
The main point you're missing is that TypeScript is gradual. It's a superset of JavaScript, meaning that you can use TypeScript when you want it or ignore it when you don't want it.
Any valid JavaScript file is also a valid TypeScript file.
> Dynamically typed languages are DANGEROUS!!!
See above. TypeScript is dynamically typed by default. It just also has a static type checker that you can opt into.
A good practice in both JavaScript and TypeScript is to use "const" instead of "var" or "let" anyway.
> I believe static type checking should ideally be done by the IDE
JavaScript doesn't have enough explicit information for this to be possible. The IDE can do a lot, but it can't do nearly as much if the developer's intentions are implicit. In TypeScript, the developer has the option (again, not the requirement) to make her intentions explicit.
> we shouldn't need an entire new language for that with all its shortcomings
Again, see above. TypeScript is a superset of JavaScript, not an entirely new language.
> At least heaps of Typescript code bases that need to be rewritten.
No, they won't. TypeScript compilers will still be available, even if they're not actively developed. They produce JavaScript, so worst-case scenario, you'll just have a JavaScript code base.
Free will does exist, only we don't have it. We live in our own little world of illusions, thinking and dreaming. In reality every random influence can change our path.
Reality only exists in the present moment; just try to "be" there for a few minutes (without thinking) and you realize you don't have "free will". These are qualities that come with a huge price that almost none of us can or want to pay for, mainly because we love to dream we already have it.
Examples of people with free will are: Jesus Christ, Buddha, etc..
I'm curious as to what your theological beliefs are? How come you list Jesus (which I would understand if you are christian) but also, in the same breath, Buddha?
That doesn’t mean that their ideas weren’t generated by a deterministic machine inside their skulls. GGP doesn’t explain why he thinks these individuals had free will and the rest of us don’t. Seems to me even in “random” yet deterministic systems, you’ll still get “anomalous” behavior that others within the system catagorize as “somehow different” - still doesn’t mean their will is freer than others’.
Yeah absolutely. I don't agree with his 'examples', but I'll defend to the death his right to use them in the same breath. It seems absurd to claim a handful of humans to have free will and others not, not really sure what that would even mean.
In Buddhism there is a notion that the human conscious experience is a largely automatic state of "waking sleep" where the individual navigates life reactively, subject to the karmic law of "cause and effect". (Determinism)
The metaphor of "waking up" is about practicing a present state of mind, such that one recognizes how they are living life with about the same amount of awareness as a dream, with the aim to cultivate the same agency of a lucid dream in waking life. (Free Will)
A Gnostic reading of the New Testament reveals a similar allegorical prescription to awakening in Jesus' teachings, whereby adherents strive to attain "Christ Consciousness" and achieve liberation.
Many contemplative traditions hold that human suffering is caused by our baseline instinctual unconscious tendencies (a feedback loop from hell), and that it takes sustained practice to become present enough to "take the car off autopilot" permanently.
A cursory survey of the brutishness of human history is a testament to how rare this mental state is, and explains the high regard by those who attempt to emulate the characters (historical or fictional) claimed to have mastered it.
>> Hardt said. “It filters out the stuff that the brain deems unimportant.”
Most of the things I learned at school I forgot; all the math and so that I never need in my life. More than half of the curriculum is just rubbish for our brains IMAO.
Maybe this helps to start making compulsive education more pragmatic. At this moment I see kids coming from school knowing how to do advance math they'll never ever need. But basic knowledge about what is healthy food or not, or knowing how the industry is poisoning almost anything you can buy in the supermarket, they have no clue.. And I believe knowing those things do matter for our brain, we would not easily forget.
After I ran my head against math for some time and actually noticed changes to my mind structure, I am sceptical. Studying math is not (just) about the knowledge you gain, it is about the reasoning structure behind it, like a workout for the brain.
Learning things is not (just) about the facts you know afterwards. I read so many books I forgot at least half of what was written there, but my worldview and thinking was altered from that.
Not that the other stuff isn't very important too of course..
Just because you wouldn't remember how to tackle an advanced math problem doesn't mean it has been wasted.
You've gained experience and you can identify what you don't remember. Even if you can't remember it it is no longer magic, which is invaluable by itself.
Also the process of learning these abstract concepts is arguably the most important skill you learn in higher education. You might recognize what is required and you do know how to pick it up when you are faced with it - or know when you need external help.
Yeah, this 30 years old code-base.. besides it is questionable only dev's below 30yr old are working on it (age discrimination, or accidental?), hardly anything changed. If I want to copy something I still have to do the ancient mark and copy sequence from the right click menu! What are they working on then? Still fixing bugs?
Have you tried enabling QuickEdit mode in the Properties (right click on the titlebar)? Quick edit lets you use the mouse for selecting, and in Insider's releases we've even added support for Ctrl+Shift+C/V for copy paste (even in wsl!).
We've been working on not only tons of bugs, but adding plenty of new features, including support for VT sequences, 256/RGB color, improving our unicode support, enhanced accessibility support.
The fact that all of our devs are under 30 is merely coincidence :)
I just started turning Quick Edit off because I understood it was responsible for that strange bug where the console sometimes gets stuck until you press return. :-( Is that one on the to do list?
It's overeager, then. It's pausing the console even when no selection is made. Maybe I'm clicking in the window accidentally, but I'm not selecting anything. I certainly don’t have the problem on Linux.
A user cannot downvote a reply. I also did not downvote you, but can understand you got downvoted because of your snarky reply. You are commenting on other people's work. If a feature is in the insider's release then it will be in a normal release in a few months.
So the comment is a "if you want to try it right now" kind of reply.
Also note that "why do I get downvoted" edits itself attracts more downvotes.
> Insider's release only? Wow, that sounds like really advanced stuff for something totally basic!
This has nothing to do with how large or small the feature or change is. A feature, once ready to be publicly tested, will get in the pipeline to first get into the insider releases and eventually show up in a normal build. In what kind of release such a change is is purely based on how old the change is, I guess. But of course, don't let that detract you from snarking.
Its not quite UNIX style - it works like a weird frame selection instead of follow the text LtR like any *nix console I can think of.
It would be super if that could be fixed as well with an option.
I'm pretty sure it's block/column selection instead of line selection.
Why they made that design decision, we will never know. Maybe a dev was working with a lot of hex output? (even so, he should be slapped retroactively, unless he's Raymond Chen, cause Raymond Chen is amazing so we'll forgive his transgressions)
The console 'screen' is a grid of (character,attribute) pairs, so there are no lines as such...
I'm not sure the box selection is super useful these days, but in the late 80s/early 90s, GUI-style interfaces were very popular, and a box selection makes a certain amount of sense, so you can avoid picking up borders and so on. Would have been nice if they'd got both types in from day 1 though...
This is one of the major changes that happened since this team started working on the console. In Windows 10 it has line selection that flows correctly over line breaks.
This is also not true as of Windows 10 build 16299/Fall Creator's Update (what I'm currently using), and may not be true of an earlier release or two. Ctrl+C and Ctrl+V both work just fine in cmd. I found evidence it was considered an "experimental feature" available in the Command Prompt's Properties dialogue back in 2015, it looks like it's been folded into the default behavior at this point.
Microsoft's done a lot of work on legacy components of Windows like cmd and notepad in the last few years, assumptions about behavior that has worked the same for the last twenty years may no longer be valid. ;)
PowerShell is a shell, thus a console application, buy not the console. So it's just the settings of the console window if you observe any differences. The PowerShell shortcut on the start menu may have different settings from the command prompt shortcut.
I love Powershell, but it still uses the exact same ConHost as cmd and command.com before it. When scripting PS this is a non-issue, but using it interactively remains painful.
May I ask what your specific pain points are? We've been doing a lot to try and improve our usability but there's so very much on our backlog that it's hard to prioritize. I'm always curious if people have specific requests
edit: pain points with conhost*. I work on conhost, the "terminal", not PowerShell
Not the parent, but personally, my only real pet peeve with PowerShell as an IT admin is that the right click start menu replaced cmd with PowerShell despite it still being drastically slower to load on many PCs. There's a setting to change it back, but if you are working on other computers all the time, that's not useful at all. This is my main peeve with the Settings panel as well: It's slower to get things done with, but the legacy panels have been intentionally made harder to reach[1] before performance parity has been reached.
My understanding is that improving PowerShell's start time is a big part of the next release of Windows 10, and that's great, but once that's done was the right time to put PowerShell as the default console on Windows, not before. 98% of why I open a prompt is to run "ping", and waiting for the prompt to actually show up in PS takes longer than a ping timeout. (Which is to say, if you need one takeaway from this post: Remember that no matter how cool you make PowerShell, most of us are only opening it to ping something, that's the most important experience to get right.)
Especially some of the decisions with the install screens for Windows 10 seem to highlight that people at Microsoft aren't aware how some subtle changes cause significant pain/delay for IT folks. Like with 1803 being forced to come up with security questions when creating the local account on a PC you're about to domain join.
[1]Example: Programs and Features from the legacy control panel no longer appears in search, even if you type it all the way out. Typing "appwiz.cpl" is the fastest way to see what's installed on a computer (and what versions) at a glance, but kinda a pro trick.
> Like with 1803 being forced to come up with security questions when creating the local account on a PC you're about to domain join.
Security Questions are a really bad anti feature that nonetheless is really persistent. I don't need 5 more random alphanumeric Passwords in case I forget that other random alphanumeric password I can barely remember. In most places online where they are used the rip open huge security holes should you actually set reasonable a answer to "Whats my Pet called?".
Yeah, and it was introduced for local accounts in Windows 10 just in the last few months. Beyond the general irritation of it being a poor security system, making me do it for a user account that isn't personal to me is additionally quite silly: I told the installer I was going to domain join the PC.
I end up mashing the keyboard for each one to create hopefully suitably random answers that even I myself don't know. But it's still arguably an additional security hole that I have to simply hope Microsoft hasn't somehow stored in plaintext somewhere.
Also true, but there's a limit to how much nonsense you want to dump into GPOs. Most of what you throw in your Group Policy will inevitably end up sticking around for the next decade and a half long past its irrelevance, and regardless of whether you throw everything in one big GPO or have several dozen small GPOs, you will never remember where that stupid setting came from down the road.
So I'm hesitant to go overboard on custom registry entry pushes (as opposed to the standard templates) for things that only affect IT experience.
This may be by design, but there has to be a better way. Unix/Linux consoles have allowed mouse copy/paste for as long as I can remember and I've never experienced this bug over there.
Really annoying when you go out to lunch with a job running, only to come back to find that it's right where you left it. So many solutions to this problem like making the copy/paste mode harder to trigger accidently. Visual feedback that it's in that mode, or allowing the buffer to expand indefinitely when copy mode is triggered.
Pausing the job is the last thing I'd want, especially since this seems to easy to trigger accidentally.
Even on Windows I use mingw64 terminal + pacman. My pain points are:
- Conemu can show up on a shorcut, Windows Console can't
- Windows Console doesn't have tabs
- There is no CTRL + R to search for the last command
Ok maybe I've got more bash issues:
- autocompletion in cmd doesn't work, not for commands nor for command arguments, like in Linux consoles
- mc doesn't work in cmd
- I really hate dos batch language because it is not logical imho (I don't want to start to rant about it here). On the other hand I remember the bash language better and can write small one liners to create commands that don't natively exist. PowerShell is not an alternative because it treats everything as text and inserts new lines, where bash does not.
> There is no CTRL + R to search for the last command
On Unix this is typically a shell feature, not a console/terminal feature. The corresponding way to do this in the Windows console would be F8, I think.
> autocompletion in cmd doesn't work
> I really hate dos batch language
None of those have anything to do with the console.
Wow! This blew my mind. I have grown very used to using cmd, but have not thought of using the F keys before (do not know why). Behavior seemed strange at first, but after a quick DDG search found this StackOverflow question [0] and that led to this documentation [1]. This is a huge area of functionality which I don't think most people know about.
I will be using F7 a lot in the future.
As an aside, maintaining backwards compatibility (this is DOS era stuff) is why IMO it would be very hard to update core windows utilities, but maintaining backwards compatibility (and similar decisions) is why IMO Windows is as popular as it is.
Almost any console is better than the Windows console. I use iTerm2 on OSX now, what an awesome UX. Maybe it's a good idea that you guys first take a look at what you are actually trying to reinvent.
2. copy 90% of that song in terms of sound, structure, base melody etc..
3. just change a little of most parts so it doesn't sound like a straight copy
4. have a smart producer who can do this
5. have a great mastering studio to let it sound big
6. use the right channels for promotion (publishing, (radio)dj's, television, social media, etc)
7. have heaps of luck, right timing etc..
Most people in this world have no clue at all that this is what actually makes a hit. It's very rare to see a 'Hit' to come out of nowhere, although it does happen. It's an illusion that a talented musician can achieve this on his own without insane amounts of luck.
It's a great little book. I had a copy which I gifted to a friend, thinking I'll just buy myself a new one... Turns out they go for over 100 pounds a pop...
I spotted a copy at the local Half-Priced Bookstore the other day, behind the counter with all the other expensive stuff. It was priced over $100. I wish I either had the money or an elaborate scheme to distract the guy at the counter and make off with it. I've read a nice chunk of it in TXT form, but to have the physical copy would be very nice.
While 1-7 is a pretty clever tongue in cheek perspective, it's not at all what Max Martin does. Arguably he's the king of modern Pop music hits - I mean, he's orders of magnitude more successful than second place. It's rare to find interviews with him but he does drop some hints at his methods and approach (balanced lines, extreme vocal comping detail work) which takes a lot of the mystery out of it.
Basically though #6 explains how acts like Cardi B can chart, because Pop music is a commodity, it's not art. Something like Gotye's hit definitely falls into #7 in that regard. "What's good isn't always popular, and what's popular isn't always good."
What goes behind the process of creating a hit is something that fascinates me, but, something I never had the time to really research.
Also, I've always been kinda bipolar on this subject; sometimes I'm 100% convinced that most popular hit songs are fabricated and sometimes I want to believe that there is real talent and creativity behind them; not formulas.
I find the following to be true most of the time for hit songs:
- The singer (male or female) is young, and most of the time good looking.
- The first time you listen to the song you hate it, but after they play it multiple times on the radio you start to like it.
- At a given time, you can see the radio/popular mediums pump up a given singer. For example, I noticed a rise in Cardi B songs, previously it was Camila Cabello. This makes me think there is actually a force pulling the strings.
- A lot of time they are one hit wonders, new "artists" appear and dissapear all the time.
- They usually sing about current hot topics: feminism, be yourself, love thyself, don't worry if you're fat, let's enjoy life. And usually with very bland messages to appeal the masses.
- The music: of course the beats are familiar and following a known structure that arouses emotions.
Don't get me wrong, I love music. I love listening to all types of music, from Merzbow to the #1 hit they're playing on the radio.
But as a geek, I love to also analyze the pop music phenomenon. I'm not really familiar with the process behind them, and would love if someone who knows could share it! I mean the process behind actual hit pop songs: Post Malone, Katy Perry, Ariana Grande, Drake, Cardi B, Dua Lipa, etc.
- Do they write their songs? How much they get censored?
- Are they good singers? I know some of them are really talented.
- How to they rise to fame so quickly? Casting? Personal contacts?
- Do they really have a say on the structure of their songs and the music behind them?
These are some of the things that don't let me sleep at night.
There's a video by the NYT chronicling the creation of "The Middle" by Zedd, Maren Morris, and Grey. [1]
It began with a girl who recorded a short demo on her phone. After a year of workshopping and 15 different vocalists, they finally had their radio hit.
It's like a blockbuster movie. Big money goes in, big returns are expected, and lots of suits are involved. It's fun entertainment that needs to sell, but there's real talent there too.
I think it’s a little bit more complicated (and perhaps more “authentic” too) than you’re making it out to be. Labels definitely have strong influence in what gets played on the radio, but in your Cardi B example, Bodak Yellow was extremely popular on SoundCloud before it got any radio plays.
For your other questions, you can see in the credits of a song how many people are involved in radio hits. Labels invest money in creating hits so they can make money. The involvement and talent of artists varies from label to label and artist to artist but it’s generally not the organic process you seem to be hopeful about. At the end of the day, these artists have to perform not only in the studio but while touring, so they can’t be talentless hacks since some talent is required to be a profitable artist.
I agree completely, but what you say about my comment does not reflect the spirit of it, I'm sure I expressed myself wrongly. I understand, because it may seem that I'm criticizing pop music/artists when I'm really not. Also, I'm ignorant on the subject of music production, I just enjoy listening to it a lot.
I'm geniunely curious about the process. Because the level of production behind these songs and artists makes me believe that a lot of it could be orchestrated and pushed to us.
I could be totally overthinking it yes, and probably they follow the same rules as any business: decent product + marketing + a bit of luck.
I don't think Gangnam Style is a good match for the formula, but the video was well produced and just weird enough that people would want to share it. I'm convinced it only became popular because of the video.
You'll find a lot of the songwriters are the same people, and the producers - who literally birth the entire song - are also the same people again and again.
It's just annoying that when I look for a new front-end job I see more and more Vue.. I really don't want to write all that markup, for me it feels like a step back from React, so I skip those jobs. Maybe I'm just afraid for non interesting technologies becoming a standard I have to concede to eventually.
And on the flip-side; I can't stand React so I'm glad to see that Vue is growing. I hate the JSX "everything is JavaScript" mentality where you shove all of your HTML into a render function.
Vue's component separation of HTML/JavaScript/CSS just clicks better for me.
> I hate the JSX "everything is JavaScript" mentality
Would you object to things like unobtrusive javascript?
Things like unobtrusive javascript came to be because people recognized early on that HTML was not enoug for writing applications -- that you needed something more. Since basically the entire world has come to embrace unobtrusive javascript, it isn't a logical leap to embrace JSX.
Some people don't appreciate being required to run arbitrary code just to view an HTML page and the eye candy of JS is just not worth it.
Sure there are cases where JS is incredibly useful and beneficial, but your website should be able to display the majority of content with JS disabled.
Saying that "your website" should be able to "display" its "content" without JS seems to assume (as so many do) that the web is fundamentally a collection of articles (read them, look at the pictures, link to other articles) with a few exceptions, and keeping it that way is every developer's responsibility.
That's not what it is anymore. It has evolved into a general, distributed computing and communications platform. More and more uses of this platform require doing things that involve customized behaviors, not just the built-in features for displaying articles, so more and more people leave JS enabled. Kids who couldn't have afforded a family PC and MS Office now have a Chromebook at school (and maybe at home) and free Google Docs. And how many people whose only internet access device is a phone turn JS off in their phone?
I think it makes more sense now to treat the JS-disabled, article-browsing case as the exception. If I were trying to distribute public health articles as widely as possible, I would try to limit them to simple text, small photos, no JS, nothing that wouldn't have worked 20 years ago. And even for less-critical articles, if they were just simple articles, I'm still inclined to leave out the JavaScript in most cases for the sake of simplicity, reliability, reach, and archival robustness.
But for general purpose today, most developers in the developed world can assume JS is going to be enabled by the market they want to target.
> Sure there are cases where JS is incredibly useful and beneficial, but your website should be able to display the majority of content with JS disabled.
That's an entirely different discussion than what the parent was discussing though. This is about those cases where you're not building a static website.
That particular argument doesn't make a case of React or Vue's approach being particularly better than the other.
In the author's conclusion he states, "JSX isn’t revolutionary. It’s evolutionary. Like most forms of evolution, it’s a clear improvement."
I will concede the author's point that React & JSX are better than the jQuery spaghetti that came before and is therefore an improvement. As the comparison here is to that of evolution which is superior the shark or the tiger? With evolution many things will evolve out of those things that came before and the strong will survive. Vue and React are both evolutions of what came before; time will tell which, if either, survives.
I don't think you are really going to have to concede to the latest hotness for a very long time. There's still plenty of jobs for building and maintaining PHP + jQuery applications. Shoot, I spent a lot of time at my last job maintaining Classic ASP serving up HTML. React isn't going anywhere.
This makes me think of the Apple marketing campaign in 2004. With Apple everything is better, hmmm not really. Apple has the fastest pc's in the world, hmmm not really.. With an Apple pc you'll get your work faster done, sure? Especially the non-technical designers, writers, musicians etc.. believed that shit. In a way Vue gives me that same feeling.
Yep, and I'd fire you for doing that! There are better ways to manage instead of showing off your authority. Oh, and by the way, would some JSON.parse statements for performance be the worst thing in your codebase(s) you guess? I mean, I cannot believe that would be the worse in your codebase. Also, if it really helps to use some JSON.parse for creating big objects for performance reasons, who cares? Instead of firing 'someone' maybe you can add some annotation to it for readability (or if that is below your imaginary level, ask the developer if he/she can add that).
Sry, but I hate people that misuse their authority by imposing their subjective opinions.