isiahmeadows at gmail.com
Wed Jul 25 19:05:20 UTC 2018
In my experience, Electron is great for prototyping, but it's a mild pain
to scale, and creating packaged binaries required building a massive
toolkit just to get something that worked for most cases. Bundling scripts
for Node itself is still a minor pain, enough that most projects don't
bother, and testing support with bundled projects is also a bit sucky.
Electron doesn't really help much in this area, since it's more Node than
browser, absorbing all the testing and building warts it has. Oh, and don't
forget that you *have* to (at least pre-N-API) recompile native extensions
to work with it, which is incredibly inconvenient to set up.
Not like this isn't solvable by more tooling, but eventually, it's going to
feel like the typical Java + Maven + Ant monstrosity, just replaced with a
mess of CLI apps instead. This isn't an issue for prototyping or larger
apps where this might affect your workflow minimally, but it's certainly an
issue when trying to scale initially. It's not really impossible, just
annoying and full of potholes while you hook up all the boilerplate.
On Wed, Jul 25, 2018, 13:42 Pier Bover <pierbover11 at gmail.com> wrote:
> Lurker here, I also agree with most points expressed by T.J. Crowder.
> the addition of class and async/await only make the language better, and if
> optional static types were included (a la TypeScript or ES4) it would
> I also think the Node ecosystem is a mess, and that Electron is a plague,
> but those points are completely unrelated to the language itself. There are
> projects such as https://nodekit.io/ that aim to provide a bloat-free
> universal Electron / Cordova replacement.
> On Wed, Jul 25, 2018 at 12:00 PM, Jacob Pratt <jhprattdev at gmail.com>
>> Mostly a lurker here. I fully agree with your points, and also use JS for
>> non-web projects.
>> On Wed, Jul 25, 2018, 07:34 T.J. Crowder <tj.crowder at farsightsoftware.com>
>>> Lurkers: If I'm alone in this, please say so. If I'm **not** alone,
>>> please say so (publicly this time). Either way, I'm done as of this message
>>> other than linking back to it.
>>> On Wed, Jul 25, 2018 at 11:33 AM, kai zhu
>>> <kaizhu256 at gmail.com> wrote:
>>> > than java/c++/python/etc. for non web-related projects. there is no
>>> > foreseeable future where employers would hire nodejs-developers to
>>> > work on non web-related projects
>>> This is where we differ (well, one place we differ), as I've said many
>>> times before, and others have said many times before. That future is now.
>>> general-purpose programming language good for a lot more than just
>>> web-related work. And "web" technologies are used for a lot more than just
>>> Windows store apps, Electron, etc. It's also a good language for writing
>>> *nix shell scripts and command-line utilities, particularly now that it has
>>> embedded device work, completely removed from the web environment. And so
>>> Separately, the idea that web projects don't benefit from features like
>>> `class`, `async`/`await`, and meta-programming features and such is flatly
>>> contradicted by the evidence.
>>> But leave all that aside. We all know you don't agree with that. You've
>>> told us, ad nauseum. It's not that we haven't heard what you're saying,
>>> it's that we disagree with it. (I say "we" because I've had private
>>> messages from people supporting my pushback on this. I wish they'd be made
>>> as a niche, limited language is not constructive at this point.
>>> Robustly-expressed differing views are an essential part of
>>> consensus-building, but there comes a point where one has to accept that
>>> one's view has not been successful *and move on*. I think frankly we're
>>> well past that point on this topic, and have been for a while. Specific
>>> input on proposals is great, including raising specific concerns with
>>> serialization etc. (ideally with a proposed solution, but sometimes just
>>> raising a concern is useful). Putting forward constructive, specific
>>> proposals for things you think TC39 should be acting on is great.
>>> Constantly trying to push a view clearly at odds with the consensus of the
>>> community here is just not useful, and gets in the way of useful
>>> conversations we could be having, including about the things you care about
>>> getting done. Please, please move on.
>>> And again: I think you're right that issues around JSON interop with new
>>> features like BigInt need focus (here, in the proposal itself, in some JSON
>>> working group, somewhere), and there seems to be interest in doing so. So
>>> if that's an area of interest for you, please contribute to that effort,
>>> rather than spending time beating this dead horse.
>>> I'm not going to keep writing these replies, I'll just refer to this one
>>> from now on.
>>> And again, lurkers, please weigh in.
>>> -- T.J. Crowder
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss