I was wondering if you would mind being a bit more specific about your criticism towards React and the JS community?
If you know React well, it seems like there are things that everyone can learn from or think about. Would you use vanilla JS or other frameworks and why?
The sentiment is that none of this mess should be necessary - why isn’t all of this well-trodden functionality (like Redux/Reflux (not React) for state-management, for example) built-in to browsers now? Why do we have JS build-processes at all? Why can’t browsers cache modules and scripts (by hash?) indefinitely instead of falling victim to the browser cache and privacy gods?
It's what happens when no one group controls the "open" web, and instead you have different advertising & services giants competing for the future of human information exchange. Blame Netscape for hurriedly shimming in a shitty language in the 90s and jumpstarting a war among the digital cartels.
Microsoft wants TypeScript and abandoned .Net dominance. Google failed with AMP. On the backend, Facebook's HHVM saw limited adoption, and node.js took over, even surpassing PHP in developer mindshare. So streamlining the front & backends was inevitable. Angular 2 was so bloated that it made React seem simple, and by the time Vue et al came around, React had so much inertia and community support that it was harder for them to gain traction. Apple checked out completely, Mozilla is still fighting the good fight but losing more ground every year, so now it's really just Facebook building on top of Google...
For what it's worth, the nightmarish toolchain is slowly getting better, with ES6 modules, dynamic imports, Web Components, service workers, and the such. NPM is also slowly improving, and semver has done wonders for maintaining library compatibility. Frameworks-on-top-of-libs like Next.js bring some much-needed boilerplate and tooling to React and generally make the whole experience both quicker and far more tolerable (you rarely have to edit tooling configs, and webpack/babel are invisibly handled for you). Not to say it's ideal -- far from it -- but people are definitely working on streamlining the developer experience. And from the UX side there is a lot of optimization and tree-shaking work happening too, to try to shrink down the ultimately delivered package sizes.
That's not to say React is right for every project. It's just the most popular, so easy to hire for and easy to collaborate on. Every vendor provides React demo code or readybuilt components and hooks, vs having to write your own for every trivial API use case. It's a real time-saver, and the closest thing to a de-facto standard the web dev world has had since jQuery was pronounced dead (RIP).
But hey, the JS ecosystem at its worst now is at least still better than having to choose between Flash, ActiveX, Java, and VRML. At least it all compiles down to JS. Or at least it did until WebAssembly (cry)...
In a way, JS is a victim of its own success. Reminds me a lot of the Linux ecosystem, where there are always 10,000 ways to do something depending on your particular distro and package manager and shell and window manager, yet never a single "best practices" way. There are a million ways to do anything in JS/TS/CoffeeScript/ECMAScript/React/Vue/Svelte and none of the come close to the relative orderliness of, say, PHP or the .Net stack. I'd say it's what happens when you do design-by-committee, except it's not, because JS is more like design-by-retrospective, and only after years or decades of suffering do best practices emerge from popular use and bubble up eventually into ECMA proposals, only to be largely ignored by Apple and so require polyfills (thanks, Safari).
Which is all to say, yes, it's still hard to work with and has room for a lot of improvement. The community at large is working on a lot of those problems, slowly but surely, while being constrained by the will and pacing of the behemoths. Maybe in 20 years' time things will be better... but who are we kidding.
Those were my reactions, too! The one thing that I want the most whenever I have to jump out of the CSS per-processor world and write regular CSS.
It is worth noting that in SASS you can already refer to parent elements as they have shown with the `@nest` rule (apologies if I misunderstood what you said and you already know this). I do prefer the more verbose `@nest` syntax though, as the intention is clearer.
I'm sure there's a reason here that I'm not seeing, but it feels like it's being different for the sake of being different to me-- requiring `&` even in the simple case where you're combining them with the descendant combinator (plain space), but then also requiring `@nest` in any situation where `&` is not at the start of each selector.
SASS takes the opposite approach-- there's an implicit `&` at the beginning if you don't specify it elsewhere, and it can appear anywhere (i.e. the example `:not(&)` does not have to have anything like the `@nest` syntax in SASS).
I don't disagree with you on the potential financial burdens faced by PhD students but, in this case, and if I haven't missed anything, the infrastructural barrier is not high:
> All experi-ments use a single thread on a Macbook Pro with a 2.6GHz Intel Core i7-4960HQ processor. Unless stated otherwise, all timing results use five trials, with each trial reporting the fastest among 20 executions.
It may also be worth nothing that, even as a hobby, one can actually do a lot with modern hardware if you scope your project well. There is also a lot of free resources such as CoLab available to those who have very limited computing power at home/work.
Last but not least, there is also nothing stopping you from announcing your results on arXiv and, if you can be bothered (as a hobbyist), get it published in a peer-reviewed journal.
So if you still have ideas, I encourage you to go ahead and try them! :)
I see where you are coming from, but I personally don't find the comment narcissistic: I read it the OP of the comment thinking out load, saying "ah! It's nice to know that I have thought about something similar, and someone made the effort to show that it works!".
I think that may be a bit of an unfair statement. They do note just above in the public instances the following:
> Note: Use public instances at your own discretion. Maintainers of Whoogle do not personally validate the integrity of these instances, and popular public instances are more likely to be rate-limited or blocked.
Having tested with various search strings, the time to first search-result paint for the the first public instance [1] feels just as fast a Google.
Maybe it was a different time and/or environment, but that couldn't be furthered from the truth according to my experience — even if I read that as a metaphorical door.
Many of the people I have worked for/with who are amazing in objectively measurable ways, including fame, appear to balance their open- and closed- door times well.
If you're just chasing after fame and want to work on what "everyone" thinks is important, then I don't disagree that keeping your door opened and getting "all kinds of interruptions" is likely the way to go.
Also anecdotally, the "forever-open-door" people I have worked with who are always talking about "important problems" to solve; have huge networks; and are hopping from collaboration to collaboration working on a completely different domain of expertise every other year: they seem important to the community but, often on closer inspection, they don't actually produce much that is of substance.
A wise professor I knew always scheduled a one-on-one research meeting directly at the end of office hours.
If office hours was an hour long, students come and go for an hour with questions plus some overtime duration of extra clarifications. If office hours was four hours long, students come and go for four hours plus the same bit of overtime. With no bookend between office hours and everything else, students would beg for one more question and push the boundaries of the open-door policy.
In their eyes, the instructor who slams the door in the student's face because, "It's two o'clock, I need to work," is impolite and insensitive.
Putting an unavoidable, important meeting at the end of office hours suddenly put the burden of being impolite on the students. Suddenly, office hours became more efficient and students, more punctual. The professor was no longer so unbelievable cruel for ending the open-door session (gasp) on time. And, most importantly, research could get done at a normal hour.
Résumé/CV: Available upon request. For a slightly-outdated overview, and if you don't mind LinkedIn, please see [removed].
E-mail: [removed]
GitHub profile: [removed]
Personal website: [removed]
====================
Hello! I am looking for a junior software-engineering role. I have about 3 years of experience in full-stack web development and am particularly comfortable with JavaScript-based environments.
I prefer working in organisations that do not produce negative social impacts. I am looking for stability and would very much appreciate resources for personal development, ongoing interesting problems to solve, mentorship, and a pathway for growth.
====================
Other things of potential relevance:
- I have basic knowledge of Python, some machine learning frameworks, and SQL. Currently learning Rust — just mentioning in case there is an off chance that I could learn on the job.
- I have a background in chemistry and I recently did some applied machine learning work for about a year. For these reasons, I would happily work in data and/or research-related roles, too.
- I am self-taught. I’m only noting this because some people prefer knowing that up-front. I don’t just “write code that works” and forget about it.
- Honesty is important to me, and I expect that to be reciprocated.
Any feedback that is not job-offer related would also be very much appreciated! :)
I'm not sure whether military intervention is right or not, but for everyone making comparisons based on absolute numbers, please note that the population in Sydney is tiny. If you take the lower population density into account, all of a sudden ~200 cases no longer appears to be a trivial number.
I see people constantly breaking lockdown restrictions outside of my window here. It's pretty damn frustrating for those who are obeying the restrictions.
My point still hasn't changed: that people who are saying that "we have X many cases in our city, your ~200 cases is nothing compared to ours" are perhaps over-trivialising the problems we are facing.
Maybe I'm missing your point: but wouldn't one be more concerned if there are more people vaccinated and the number of cases is higher?
Also, I was under the impression that the long-term effects of COVID isn't well understood yet, and that people who are vaccinated can still be carriers. If I'm not mistaken on both accounts, then everyone should be just as cautious until basically the majority of the population is vaccinated -- otherwise those who are vaccinated are basically just walking around infecting those who aren't since everyone has the guard down?
We aren't close to having issues with hospital capacity, while long covid is an issue, the fear was always overrunning the hospitals and the old people. The first isn't an issue and the rest are vaccinated.
That's fair enough. We were lucky that hospital capacity wasn't much of a problem, but the lack of vaccination coverage together with a lot of... questionable strategies and mixed messages has done us in.
Given there are still a lot of unknowns with the virus, I still think we should all be more cautious. But it's just personal opinion at this point, so I don't want to dwell on that.
Not to pressure but having open/save buttons (implementable either as upload/download Javascript shims) would be interesting. They can also be quine-like (I.e. you save the HTML and Javascript of the editor itself together with the content). I did once that for Suneditor but did not publish it, alas.
It's now a Gist because I only realised later that the original note will be deleted after 24 hours.
There are now two mechanisms that persist data between sessions:
1. Auto-saving to localStorage every 5000 ms (adjustable as per the instructions).
2. Manual data saving/download implemented using an anchor element that triggers a download. We can now restore markdown by loading a downloaded file (in principle this should work for any plain text file).
One important thing to note here is that localStorage doesn't work in private browsing mode and its behaviour is not entirely consistent between browsers. So I wouldn't rely too much on it!
Excellent. Useful for being on a chromebook, offline and not logged in, so only opening local html files for tools is an option (no Chrome extensions). Will add file saving to my copy.
Mn. :( By the time I found out about the 24-hour thing I couldn't edit my original post anymore, the Gist link that I included eventually include for an improved version was also a couple of levels down.
The title is not misleading, and the golden layer formed is metallic water and not any of the metals used -- where electrons are delocalised/shared between water molecules. They have strong evidence that the layer is indeed metallic water and not something else:
> Experiments at a synchrotron in Berlin confirmed that the gold reflections produced the signatures expected of metallic water.
In my opinion, the ingenious part of the experiment is the following part, and I'm glad that they were lucky enough to find the right conditions:
> The key to avoiding an explosion, Jungwirth says, was to find a window of time in which the diffusion of electrons was faster than the reaction between the water and the metals.
I forgot to say that what you said is perfectly reasonable and not too different form my initial reaction. This is indeed very weird (but cool) science. :)
I agree. The original explanation is a good guess but it's not what is happening in the OP.
There is experiment to detect some sugars, that is somewhat similar to this alternative explanation (and unrelated to the experiment in the OP). More details in:
> ... receiving sincere and well-expressed praise can feel as good as an unexpected windfall.
Going on a bit of a tangent: I think giving "sincere and well-expressed" criticisms is just as, if not more, important.
Some of the most profound lessons I have learnt in life come in the form of criticisms from people who don't know me well or at all. As far as I can tell they all have this in common: they are not afraid to be honest and they make sure that I know they are just looking out for me.
> The effects of the flattery were dramatic, with 79% of the participants offering to help with the event publicity, compared with only 46% of participants in a control group, who had not received the compliment.
In contrast, and somewhat related to the quote above, I feel that compliments are just short term "hacks" and, at least to me, don't really shape me in any meaningful way.
If you know React well, it seems like there are things that everyone can learn from or think about. Would you use vanilla JS or other frameworks and why?