321–330 of 391 posts
Earlier quoted context omitted.
Having just gone through all of this (two years ago), it isn’t “hard”, you just have to stop assuming it’s easy and will only take a bit. Also Parcel is easier by a factor of 10, skip Webpack entirely.
>Having just gone through all of this (two years ago), it isn’t “hard”, you just have to stop assuming it’s easy and will only take a bit. So it isn't hard - it's just not easy and it's time consuming. Wait, what?
sounds like the same experience I have with pretty much every language I'm not used to. I just want to try this C++, download, unzip, oh it's windows so .project file. Fine, redo on windows , oh it's 3 versions of vstuido old and says it wants to upgrade , okay. Hmm errors. Try to fix. Now it's getting linking error. repeat the same with xcode and any project in c, c++, objc, swift okay how about ruby? oh I have old…
I have been writing JavaScript professionally for nearly 20 years. I try my damndest to keep up, but the fact of the matter is the ecosystem is garbage. It’s really not a not-knowing-the-language thing. It’s a legacy of years and years of incompatible tooling requiring even more tooling to work around nightmare scenario. Node modules not working in the browser without translation was the original sin that kicked the…
Node modules are just a reaction to the actual original sin, which is building a popular language that essentially had no standard library. I suppose that's the kind of thing that will happen when you have to build one in a matter of weeks, but everything from webpack to left_pad is essentially the fault of the language not having a standard library.
Earlier quoted context omitted.
I know a construction worker, a recruiter and a mechanical Engineer, among other random professions, that moved to JS without much trouble. It somehow seems overwhelmingly that it's other fellow devs that have trouble with getting started JS. TBF right now JS is in transition from commonjs to ESM, and we all believe for the better, but this transition period does yield some strange issues like the article said, for i…
But the problem is, JS has been in a transition from some X to some Y for the last 10 years.
Earlier quoted context omitted.
If we have a middle class in tech, we also have the "temporarily embarrassed millionaires" pretending to be the top claiming everyone below them isn't good enough for something as simple as creating a few endpoints and vibechecking rather than checking skills. And this extends all the way to the job market, where you now need 3 years of experience for a skill most people know how to use in about a week tops, and only…
I had an interesting conversation the other day with our delivery manager and two other developers from another team, who had a wildly different than me assessment of a recent candidate. Their argument was that he didn't know this and that and how is it that I deemed him worthy? I interjected by saying that during these 30min I get to ask questions I don't have nearly the time to check one's skills throughly. And the…
Earlier quoted context omitted.
in what scenario an amish farmer, a professional welder, or, well, anything but a programmer, would know anything about this "javascript" thing?
You would be suprized. I know a few people whom keep up on tech trends, even though it has nothing to do with their job. I follow programming trends, basically through HN, and self study. (I have wasted a lot of money on programming/Computing books.), and I'm basically a Jack of all Trades in life. I'm a mechanic certain years. I'm a contractor certain years. I'm a Electrician when I am very low on money. I'm a Watch…
It significantly predates the selfie. Tyler Durden mocked the question in Fight Club before smart phones existed, and it was already very old then. I'd bet money you could find films and books in the '50s that document that question (I think I know of a novel that does, but I'd have to double-check to be sure). I bet the only reason it'd be harder to find in 18th and 19th century literature is that so much of that was by and for aristocrats. Pre-industrial-revolution, perhaps it was an uncommon question.
It makes sense in a world where most people spend the best 40+ hours of their week working a job for wages, lose another 5-10 good hours to commuting to that job, and the rest of their waking time is spent desperately catching up on neglected housework and recovering from that 40 hours. It's only outliers who are bugged by the question, or see it as presumptuous. These outliers usually have settled for a lot less than most people are willing to (materially, and maybe family-wise—this'd be your Tyler Durdens, your actually-poor-and-not-just-slumming-it bohemian sorts or members of Fussell's "Class X"), or else have found themselves in a situation where they're much richer than most people but don't have to work all that hard for it (some of the Fussellian upper-middle, especially later in their careers, plus your usual trust-fund kids).
Earlier quoted context omitted.
I don't think the Rust team are unaware of supply chain attacks, so you don't need to warn them. It's just that there's no easy solution. Or do you have some easy solution they aren't doing. Just to pre-empt you, namespacing doesn't solve the issue and manually vetting authors/crates is not something the Rust community wants.
Namespaces do not solve the issue but they do mitigate a specific vector, while also removing a perceived need to preregister crates. There’s no downside beyond “it requires development time and maintenance” like any other feature.
Earlier quoted context omitted.
Or perhaps the interviewers are under-experienced, under-perpared and/or under-trained? True story: I had an interview a couple of weeks ago. I was interviewed by two people who were younger than me, and relatively less experienced than me. My CV has a number of links to repos for various side projects and such. Best I could tell, neither of them looked, at least not more than a minute. Not a single "Your ____ repo l…
> Best I could tell, neither of them looked, at least not more than a minute. I once interviewed a guy with a nice, short 1-pager résumé—not from lack of experience, just a solid, terse document. Not just out of school. Had three or four tech jobs in his history. He listed one research paper near the bottom, that he'd co-authored in grad school. I found the paper, skimmed it, and asked him about it in the interview (…
Earlier quoted context omitted.
This seems like a great place to ask how the ever-loving shit you get a front-end project with simple NPM-fetched libraries to bundle into either a single .js file ready to go in a tag, or a block of tags with all the referenced .js files in a directory and ready to serve. Ideally with typescript support, but surely (ha. ha. ha. ha.) I can just tack that on top and point whatever-this-is at typescript's output direct…
For me esbuild has worked pretty well. Given a index.js as the entrypoint for your app: npx esbuild index.js --bundle --sourcemap --minify --outfile=out.js --format=esm esbuild is also pretty quick and does not have a lot of npm depencencies thanks to being a go binary. npx should download and run the binary for you and npx is almost always installed with node automatically.
Earlier quoted context omitted.
I have been writing JavaScript professionally for nearly 20 years. I try my damndest to keep up, but the fact of the matter is the ecosystem is garbage. It’s really not a not-knowing-the-language thing. It’s a legacy of years and years of incompatible tooling requiring even more tooling to work around nightmare scenario. Node modules not working in the browser without translation was the original sin that kicked the…
> Node modules not working in the browser without translation was the original sin that kicked the whole nightmare off. Node modules are just a reaction to the actual original sin, which is building a popular language that essentially had no standard library. I suppose that's the kind of thing that will happen when you have to build one in a matter of weeks, but everything from webpack to left_pad is essentially the…
Moving javascript out of the browser and trying to use it as a one-size-fits-all replacement for everything from systems to application programming, and every language from C++ to Java, is the original sin. Stop complaining because Brendan Eich's toy scripting language isn't a good replacement for things it was never meant to be used for. A screwdriver isn't a good hammer, either.
Earlier quoted context omitted.
Good answer. Here is one more, and I got to say I am really unsure why it isn't done this way: Check each update to a crate for the usage of a TCP / HTTP / UDP stack usage. There is absolutely no reason a crate for math (for example) should be introducing any of that in its code. If you catch something like this, you can be 99% sure it's malware. Or even better, make crates request permissions for what kind of functi…
Transitive crate "permissions" would be amazing. To know at a glance if a crate does networking, filesystem access, IO, etc. Someone could always roll their own IO, but self reporting and automated detection tooling (to catch those that slip through the cracks) would bring this percentage way down. Maybe the language could even evolve "unsafe" for IO, even if just as a flag for users. That way it would all be incredi…