From the guidelines:

> Please resist commenting about being downvoted. It never does any good, and it makes boring reading.

https://news.ycombinator.com/newsguidelines.html

Disclaimer: I do not work at Facebook.

While I appreciate your vigilantism (given you aren't actually a moderator nor do you work at FB), the real elephant in the room is that HN really needs to a better solution for vote collusion. I am already familiar with the guidelines, and I usually follow this rule to a tee, but the optics here are damning.

What I'd really like to see is this discussion steered back on topic. It was originally interesting and productive. I like talking about web technologies; it is my passion.

Frankly I only downvoted because of the unfounded accusations of Facebook shilling. There's a certain level of pretentiousness in thinking one's comments could only ever be downvoted because somebody was literally paid to do it. And that attitude rubs me the wrong way.

To bring it back to the discussion itself, I'm also a huge fan of web technologies, so I'm always glad to see further optimizations being made.

I'm hesitant to use it now as it's still so early, but would like to see it mature so it can be included as a step in our gulp/grunt build processes.

Continuing the discussion means not opportunistically taking a cheap shot first. :(

You're right, but I also didn't realize until after I'd commented that I was replying to the same author as the parent poster.

Baseless accusations of collusion and shillage aren't OK on Hacker News. We care a lot about vote quality and we're more than happy to take a look at specific cases if you have concerns, but please email us at [email protected] so that the discussion here can continue.

Sure. I emailed my feedback to you, thanks.

Prepack is quite complementary to traditional compilers. It's strength is that it comes with full knowledge of the JavaScript built-ins, and it uses that to pre-evaluate the code at compile time. In an extreme case, an entire program can get reduced to the final result.

Right, I tried editing my post a bit more to make it clearer:

Added the adjective "optimizing" to "compiler" in the first sentence (I meant something like LLVM opt, what you get when you -O3 your Makefile -- constant folding, loop unrolling, dead code elimination, compile-time constexpr function evaluation -- your extreme example being running the entire program at compile-time).

Added quotes around JS "compiler" -- what your run-of-the-mill JS developers call "compilers" aren't actually real optimizing compilers, even though the JS world would say otherwise, but I digress. Yours is the first to even come close.

Your approach is subject to all sorts of breakages. You mention the lack of "environments" in your documentation which means Prepack out-of-the-box is completely oblivious to the browser itself -- the DOM, etc. What really is annoying is if Fib(6) gets replaced with 8 (including the whole definition of Fib itself, then I can't pop open my console anymore and type Fib(3) -- nor can I bind a UI control to a textbox that evaluates Fib(text) in the box).

An actual working compiler takes in account the "execution environment" as a whole. You can't Fib(x) Linux into oblivion.

How much marketshare do you think that Javascript will lose once WebAssembly gets mainstream?

Has it evolved so much that it's now a language you would pick out of free will? With ES6, I'm hearing that it's actually usable and kinda nice, but every time I use JS for something instead of Python, I get hit with things like the weird typing that you just can't change.

"How much marketshare do you think that Javascript will lose once WebAssembly gets mainstream?"

I'm no fortuneteller, but I suspect that people writing the most demanding client applications for web will be very happy when it does.

Browser-desktop convergence wasn't meant to happen through JS, and after the proliferation of the hacks that we have today to get around inherent design flaws in the language, it really shows.

"Has it evolved so much that it's now a language you would pick out of free will?"

"Free will" is a very good way of putting it. I suspect some Node developers were ex-frontend devs that just didn't want to learn another language. Moreover, the realities of project management, human resource allocation, and fast iteration are the forcing function behind using Electron instead of building a real desktop app.

> are the forcing function behind using Electron instead of building a real desktop app.

I have to work hard to not fall into this way of thinking most of the time. I am as frustrated as you with the proliferation of Electron apps. But a lot of the time it boils down to:

Application X would not exist if Electron did not exist. Cross platform dev is hard. More programmers, no matter what language they use, is a positive thing. Lowering the barrier to entry via things like Chrome Dev Tools, Electron and related technologies is a good thing.

After all, how many people are still using the first programming language they started with?

Right, that's a bit more descriptive way of what I meant when I said "human resource allocation."

> "After all, how many people are still using the first programming language they started with?"

Is the answer to your rhetorical question here supposed to be "a lot"? Because anybody who has programmed a long enough time has had to switch languages to keep up with ever-evolving technology.

You're right, a lot of people on HN who started coding around 2013 when the web/mobile bubble started inflating learned JS and haven't touched anything else.

If you've been coding since the 1990s or even 2000s, JS was definitely not your first language (ECMAScript wasn't anywhere close to being capable of doing the things it is now up to even 2006), and so you're likely equipped with the necessary skill set to build a real desktop app.

So even if you learned JS as your first language, it's not TOO unreasonable to be expected learn something else like Python, C#/.NET, or C++ that is a bit more suited for desktop app development.

But, yes, when you have a market flooded with JS developers and bootcamp grads, THAT is the forcing function for using Electron because C++ developers are now VERY tough to hire. They're all doing the most hardcore infrastructure projects at the likes of Facebook, or they're working on bare-metal performance optimization at NVIDIA, or they're working on ML infrastructure for self-driving cars, or they're doing high frequency trading in New York.

Your run-of-the-mill seed-stage startup just doesn't have the budget for someone who knows C++ really well because even the big companies struggle finding and hiring them. With things like pointers and DIY memory management, C++ programming is HARD and easy to shoot yourself in the foot by making simple mistakes that aren't even possible to make in higher-level languages like JS.

Luckily, there's plenty of other languages out there for building real desktop apps that aren't JS or C++.

> More programmers, no matter what language they use, is a positive thing. Lowering the barrier to entry via things like Chrome Dev Tools, Electron and related technologies is a good thing.

Why? Are more plumbers also a good thing, even though this reduces the average wage of the plumber and the quality of plumbing?

Because programming is an insanely powerful tool that can make so many peoples jobs easier and more productive. The more people that can use that tool the better.

This sounds a lot like the taxi driver argument against Uber/Lyft to me.

I was right there a year or two ago developing portable native client things for my project, Linux on the Web (I was able to get vim and python running).

Projects like that can pioneer a whole lot of new techniques and infrastructure that can be very easily applied to whatever technology is eventually going to win out.

@dennykane It's a shame seeing your comments are getting downvoted on here too. It really leaves me with a bad impression about how FB operates.

@rattray Even without access, downvotes don't just happen out of nowhere; you have to admit that this just looks too obvious to any reasonable person.

I'm curious what you thought was downvote-worthy of my original post pre-edit?

I get it, rules are rules, and this is a matter of principle.

Unless you have access to the HN database, there isn't a way to know the source of downvotes.

This kind of commentary is not welcome on HN.

Late to the party, but I suspect you were downvoted for your arrogant and condescending tone, combined with your sense of unsubstantiated victimhood.

I'm not sure how you can leap to conclusions about my tone of voice from textual comments? One user @rattray is even citing quotes from the rule book to me here, and somehow I'm the one being condescending? But hey, regardless of the situation, nobody deserves to be insulted like this! You can do better, man. I can give you the benefit of the doubt; I suspect you wouldn't ever act this way in person to anybody.

I also don't see how any sort of purported victimhood would be unsubstantiated (I just don't happen to take website comments from strangers all that seriously): I'm just trying to talk about WebAssembly, and this troll spends their Friday night posting these kinds of inflammatory comments on nearly-dead threads from the beginning of the week. :(

As a reminder, you're breaking the very first rule -- "be civil" -- since we're sticklers about the rules here. You are acting very rude!

Actually, it turns out that at the time you posted this, you couldn't even see the contents of my original post that was downvoted because it was flagged and hidden via the moderators, so I'm not sure how you can even comment at all on why it was downvoted in the first place.

Ridiculous leap to conclusions here!