[HN Gopher] The Persistent Gravity of Cross Platform
___________________________________________________________________
The Persistent Gravity of Cross Platform
Author : Aaronn
Score : 71 points
Date : 2021-09-02 11:28 UTC (1 days ago)
(HTM) web link (allenpike.com)
(TXT) w3m dump (allenpike.com)
| vemv wrote:
| Shipping a whole browser engine along with arbitrary Node.js
| dependencies doesn't seem exactly a safe recipe for a password
| manager.
| yunohn wrote:
| Why? Those dependencies are locked and not going to auto-update
| themselves.
| vemv wrote:
| Even a specific dependency can sneak malicious code.
|
| For example foo-2.3.1 when distributed over npm is not
| guaranteed to match its source over github.
|
| Here's a popular piece explaining various plausible scenarios
| https://medium.com/hackernoon/im-harvesting-credit-card-
| numb...
|
| (npm is not different from cocoapods I guess... except that
| npm dependency trees are famed for its size/depth)
| danShumway wrote:
| Evergreen reminder that with just a little bit of work to
| avoid platform-specific native-compiled dependencies and
| Node-Gyp, you can vendor your dependencies for non-library
| Node projects, and sometimes you should.
|
| Certainly, Electron apps themselves should not be pulling
| dependencies at install time, those should be bundled into
| the app, that's the whole point of Electron. But they also
| don't need to pull their dependencies from the official NPM
| repos at build time either. You don't _technically_ even
| need NPM installed on anything other than your dev
| machines, Node 's dependency resolution during builds and
| at runtime doesn't rely on NPM at all.
|
| I think some languages (Go springs to mind) are starting to
| slightly popularize dependency vendoring more, and at one
| point this was the official recommendation for Node
| apps/websites in the official docs. It fell out of fashion
| for some reason, but I think a lot of orgs would benefit
| from picking up the practice again.
|
| It's also a good way to be a lot more deliberate about what
| you install, and a good way to make sure that new
| dependencies don't get snuck in without anyone noticing.
| It's very hard to hide a giant commit that introduces a
| thousand new files, and that can sometimes be a good
| opportunity to take a step back and ask yourself why you're
| adding a dependency that introduces thousands of files.
| jart wrote:
| Check out Cosmopolitan which vendors all its
| dependencies. https://github.com/jart/cosmopolitan You
| can't use Node with it, yet, but you can use QuickJS if
| you `make o//third_party/quickjs/qjs.com` and
| `o/third_party/quickjs/qjs.com -m
| third_party/quickjs/repl.js`. Cosmopolitan goes so far
| with vendoring dependencies that it actually has its own
| C library implementation that prevents functions like
| socket(), connect(), and getaddrinfo() from talking to
| the Internet if the software is running under GNU Make.
| Since sometimes we've found when porting software it'll
| have unit tests that do sneak leaks to public servers. It
| goes without saying that in order to make it even
| possible to vendor all dependencies, down to the binary
| level, there's a very long list of topologically ordered
| things that need to happen before you can even talk to
| the Internet. https://github.com/jart/cosmopolitan/blob/5
| 0937be7524197f23a... It's all cross platform and native
| at the same time for CLI/TUI. It'd surely make a more
| trustworthy tooling stack for a password manager than
| something like Electron since the temptation for people
| to incorporate things like FullStory into such GUIs is
| too great.
| yunohn wrote:
| That's not how electron works - it bundles dependencies.
| Like any other app bundle (exe, msi, dmg). Same goes for
| non-electron websites (/apps).
|
| I guess there's a way to also auto-update those, but that
| defeats the goal of using Electron - reproducible,
| predictable app builds to ship to consumers.
| stkdump wrote:
| Often the choice is between a cross-platform app vs a native
| Windows application only. That is because Mac users are of course
| important, but maybe not enough to pay for a separate native Mac
| app.
| SavantIdiot wrote:
| Some companies use Java as cross-platform, STMicro comes to
| mind. Their stuff is wonky, and that's possibly because they
| don't have committed UI/UX designers, but it is consistent
| cross-platform.
| pantulis wrote:
| This hits the nail. Cross-platform as a cheaper option only comes
| true if the multi-platform feature delivers real value to the
| users --which is obviosly the wager that Agile Bits is doing.
| Otherwise someone else is bound to deliver a similar feature set
| either with a less price point or with better execution using
| native frameworks.
|
| Counterpoint: multiplatform frameworks are web-based and thus are
| easier to learn and have more developer mindshare than native
| frameworks. But native frameworks are not that much more
| complicated these days and can use proprietary services: would
| you roll your own sync or use CloudKit?
| PaulDavisThe1st wrote:
| > Counterpoint: multiplatform frameworks are web-based
|
| Qt, GTK, FLTK, JUCE, NTK, libui are not web-based.
|
| I think that there's more than one definition of
| "multiplatform" floating around here.
| nvrspyx wrote:
| > would you roll your own sync or use CloudKit?
|
| CloudKit is definitely satisfactory, but it's limited to Apple
| devices.
|
| I don't know much about the space, so I may misunderstand the
| following technologies, but I wish more apps used P2P protocols
| like IPFS, Hypercore, etc. to keep my devices in sync with an
| optional pick-your-own-cloud-backup as well, so I can just use
| Dropbox, Google Drive, OneDrive, etc. The latter seemed to be
| pretty popular amongst developers for syncing (i.e. pick your
| cloud backup service) not too long ago and while there's still
| apps that do this, like Notability, I don't know why so many
| developers moved to rolling their own sync.
| dividedbyzero wrote:
| > I don't know why so many developers moved to rolling their
| own sync.
|
| Sync is great for justifying a paid subscription model
| pantulis wrote:
| Also, rolling your own sync is basically a must on
| multiplatform, I'd say.
| pantulis wrote:
| > CloudKit is definitely satisfactory, but it's limited to
| Apple devices.
|
| That was my point, exactly. If you target only specific
| platform users, easier development (ie, using Electron and
| web technologies) does not necessarily win over native
| frameworks because now they are decorated with powerful
| vendor services.
|
| Obviously if your target is multiple platforms, you are now
| on Electron land. That's not a bad thing per se, though.
| PaulDavisThe1st wrote:
| The article seems fairly confusing to me.
|
| First, I'm not even sure I understand what the author means by
| "cross-platform". At some point, he mentions Figma and Slack.
| What platforms are we talking about? Does cross-platform mean
| "web-based"? Lots of people use Figma's web incarnation ... is
| that cross-platform? Or is it cross-platform in its "native"
| Android/iOS apps? More people use Slack in it's app-based
| incarnation (probably), but those are not implemented with the
| same tools as the desktop version(s).
|
| I suspect the article suffers from the myopia often on display
| here at HN, in which essentially all software development
| involves some datastore, a means of entering data (often by one
| set of users) and a means of display the data in various ways
| (often by a different set of users). This used to be called
| "application development" in the 1980s, and these days there's a
| lot of writing about s/w development (and a lot of comments about
| that writing) which seems to be based on the idea that this the
| ONLY kind of s/w development there is.
|
| This vision excludes most "creative" software, all gaming
| software, most development tools, a great deal of
| technical/scientific computation, a large amount of automation
| software, and all actual computing platforms (kernels & user-
| space environments).
|
| Those of us who have been doing native desktop application
| development for decades have an entirely different take on this
| stuff from people for whom "cross-platform" means "web, android
| and/or iOS". We're not "more right", but we know about toolkits
| that work on macOS, windows and linux (gasp!). We've been
| compiling our software on multiple platforms for a long time, not
| relying on interpreters and VMs. We've had to grapple with
| packaging and runtime library questions for longer than web
| browsers have existed.
|
| Electron has got a group of people excited because it appears to
| move web-based development approaches onto the desktop, which is
| a totally different model than the one taken when using a cross-
| desktop-platform toolkit. It doesn't add to the list of such
| toolkits, it creates a totally different approach to tackling the
| problem, with the promise that the result could also be used for
| a web-based version, somehow.
|
| In my case, having been developing a "creative" application for
| 20+ years that runs on windows, macOS and linux via a cross-
| platform GUI toolkit (and C++), switching to a model that
| included web front ends (e.g. Electron) let alone mobile
| platforms, would be even more disruptive than just switching to
| another of the existing desktop cross-platform GUI toolkits, and
| in that sense, it's essentially a new development process
| entirely.
| munificent wrote:
| This is a really really good article:
|
| _> "What is it about enterprise companies that make so many of
| them abandon native apps, when they could surely afford to
| develop one app for each platform?"_
|
| Another way to think about the article's thesis is that
| organizations never deal directly in simple "costs", like "Can I
| afford to spend X on Y?" They always evaluate in terms of
| _opportunity cost_ , "Would I rather spend X on Y or Z?"
|
| Once you frame it like that, you realize that the choice between
| native versus cross-platform is, as the author states, often a
| choice between fidelity and velocity. And in today's software
| environment where hardware and user needs change very quickly,
| velocity often wins.
| ryandrake wrote:
| > Inconsistencies both small and large had crept into our apps
| over time. From small things like password strength being
| different between platforms to larger things like differences in
| search results and entire missing features.
|
| The solution that has worked well for me in the past, has been:
|
| 1. Keep all of your business logic and as much of the rest of
| your code as possible in platform-neutral C or C++: Something you
| can call into from all native platforms.
|
| 2. Write a very small layer of code using the native
| language/frameworks to do the UI and interact with platform-
| specific APIs.
|
| This has a few advantages: You get a single code base, for the
| most part, to maintain. You have the opportunity to implement as
| native a look-and-feel as you want, on each platform if you want.
| Most of your application is C or C++ so you don't need a team
| with deep expertise in multiple languages. Most of your
| development _should_ be on the business logic, right? This
| architecture also lets you easily add a command-line version of
| your product, for example to help with automated testing of your
| business logic. And finally, you don 't have to ship a huge,
| memory-devouring browser and JavaScript stack with your
| application--your users will thank you.
|
| It's not rocket science or anything to be terrified of! I think
| people too quickly dismiss cross-platform native because they
| imagine re-writing their application in 3-4 different languages,
| but it doesn't have to be that way.
| allo37 wrote:
| I had this experience as well!
|
| I think a big limitation to this approach is actually finding
| (competent) C++ devs who are willing to work on mobile,
| otherwise it works really well.
| twic wrote:
| Would it be possible to use Go for this? That compiles to
| native code, although it does include a much more significant
| runtime than C, it's safer than C or C++, and it's famously
| easy for developers to pick up as as second language.
| nicoburns wrote:
| Probably not very well, as these solutions typically
| involve FFI, and integrating thw runtimes would be a big
| pain. On the other hand, Rust is ideally suited foe this
| use case. Personally I'd love to see a Rust + react-native
| combo.
| nicoburns wrote:
| IME for a lot of apps, most of the development is the UI. Lot's
| of apps have most of their business logic on a server these
| days anyway. The problem is not typically how to share business
| logic, it's how to avoid writing 5 different UI's that do the
| same thing.
| pornel wrote:
| C and C++ are awful for business logic. You will be outcompeted
| by teams using JS or TypeScript.
| PaulDavisThe1st wrote:
| > Most of your development should be on the business logic,
| right?
|
| In "creative" applications, the term "business logic" is
| sometimes hard to use, but accepting it as "stuff unrelated to
| the actual user-interaction" ... I can say that in Ardour (a
| cross-platform DAW), the UI is ALWAYS by far the hardest
| component of everything we do, and takes far more lines of code
| than anything in the backend (roughly speaking, where the
| "business logic" lives).
| robocat wrote:
| DAW - digital audio workstation. https://ardour.org/
| gumby wrote:
| > Keep all of your business logic and as much of the rest of
| your code as possible in platform-neutral ...Something you can
| call into from all native platforms.
|
| This to me is the big win of Webassembly: you can compile with
| gcc/Clang to target it as well. It makes the browser another
| "native platform"
|
| I actually agree and chose C++ as well, but eluded that part of
| your quote because it could be a more general choice than just
| those two.
| travisgriggs wrote:
| > "What is it about enterprise companies that make so many of
| them abandon native apps, when they could surely afford to
| develop one app for each platform?"
|
| If this is the case though, why when I follow links to strong web
| apps like Twitter and reddit and Facebook, do I got plagued with
| "try the app! It's better!" prompts?
|
| I developed/maintain 2 apps that both have native variants. So 4
| apps total. And I often bemoan the duplicity and wonder if we
| shouldn't unify them. But then I see that the web guys are still
| pushing me to use native apps. I find it very circular/confusing.
| danybittel wrote:
| I think that's pure marketing. If you download a "native" app,
| you're more committed to their product. And they can show an
| icon on your home screen. It is probably more comparable to a
| bookmark.
| dividedbyzero wrote:
| Native apps can keep users more engaged (think notifications)
| and collect more and better data on them
| wmf wrote:
| Besides what other people said, mobile apps have unblockable
| ads. The app is better... for them.
| api wrote:
| There is absolutely no reason we can't have a very good
| lightweight native UI compatibility layer.
|
| Look at this heroic effort by a single developer:
|
| https://github.com/andlabs/libui
|
| It's not there, but it's probably too big of a project for one
| person.
| user-the-name wrote:
| There are a million reasons. The main one being that you _can
| 't_ put the same UI on different platforms and have it fit in,
| no matter how well you use the native components.
|
| The components are just one part of what makes up a UI.
| Different platforms have different conventions of how they are
| used on a higher level, and how everything fits into the rest
| of the platform UI.
| twic wrote:
| There have been many attempts to build such things, going back
| decades. None have really succeeded.
|
| I am no expert, but my understanding is that it's easy to get
| to 75%, but extremely hard to get to 100%, or even 95%.
|
| Not to mention that there are some differences between layout
| and navigation idioms on different platforms. Making an app
| truly native is not just a matter of using native widgets.
|
| I do wonder if there is mileage in building an abstraction
| layer at a much higher level than a widget toolkit. Imagine
| being able to write a very abstract description of your app in
| some DSL, saying what screens it has, how they are linked, what
| information is on each one, and then having tools to compile
| that down to appropriate native code.
| PaulDavisThe1st wrote:
| > None have really succeeded.
|
| I don't think that "success" here is particularly well-
| defined. There are lots of Qt-based applications running on
| multiple platforms with a single codebase. That could easily
| meet a fairly strong definition of "success".
| jancsika wrote:
| > It's not there, but it's probably too big of a project for
| one person.
|
| I mean, just take a single subset of functionality like
| handling multi-touch input. It's probably an hour or two to
| read through the Pointer Events[1] spec until you get a better
| idea of _why_ that API was designed the way it was. Now imagine
| coming up with such a design after at least dozens of hours
| studying the limitations of prior APIs (but probably more than
| that). And now, imagine either a) conceiving of and
| implementing that design (at least dozens of hours, probably
| way more), or b) cloning that design (still dozens of hours to
| implement).
|
| Now compare to the minutes it takes to read a tutorial and
| start using the API in a browser that probably already runs on
| probably any modern device that has a screen.
|
| That's just one cross-platform API, and probably not in the top
| ten to implement first.
|
| 1: https://w3c.github.io/pointerevents/
| jagger27 wrote:
| It's hard to justify my desire for awesome Mac-only apps without
| considering the spectre of future Apple lock in.
|
| Electron has made it possible to use a lot of apps that otherwise
| wouldn't have been ported to Linux work with no hassle, and for
| that I'm grateful. I have only recently been able to comfortably
| run Linux full time. My dev experience on Linux is effectively
| identical to what I do on macOS: Docker, VSCode, Alacritty, and
| Discord (to talk to my team). Of course Discord and VSCode are
| both Electron apps, and Docker just lives on the command line.
| Alacritty, on the other hand, is an extremely interesting example
| to me, as it is a true native program that uses cross-platform
| GPU acceleration through OpenGL. I feel that route is overlooked
| as a path towards compatibility for a lot of programs outside of
| games.
| vivty wrote:
| I prefer apps built using APIs like Vulkan or OpenGL to apps
| built using electron because they do not feel as sluggish. I
| think the Blender UI also uses OpenGL to render the interface.
| One criticism of this approach that has come up in many threads
| on the same topic however was the lack of accessibility. This
| is a big pro for electron (and also native development).
| PaulDavisThe1st wrote:
| Vulkan is a _drawing API_. Like OpenGL, It does absolutely
| nothing about the big 4 of (G)UI development:
| * text entry * file browsing & selection * menus
| * list/tree views
|
| Like OpenGL, it also doesn't even provide an event loop or
| even an event (user input) layer.
| duckfruit wrote:
| This is a very good point that I feel gets overlooked way
| too often. When people talk about the UI feeling sluggish
| most of the time they are talking about _responsiveness_.
|
| Like, who cares if your app is rendering at 120 fps if it
| takes me 3 seconds to focus on a text field? I feel like
| that's where most cross platform tooling has their work cut
| out.
| prewett wrote:
| It not even a drawing API, even. It's a 3D triangle
| rendering API. Things like lines, bezier curves, gradients
| are all do-it-yourself. None of it super-hard, I've done
| them all, but before you write your UI you have to write
| all your drawing routines, which probably wasn't what you
| wanted to be doing. And you get all the fun texture
| management issues for any gradients and images you want to
| display. And you probably won't have optimized it like the
| platform rendering will have.
|
| And then there's text... You've got to load a texture for
| every glyph of every point size used in the app for every
| font used in the app. Mind you, the OS already has a cache
| for this, but you don't have access to it, so that's more
| memory wasted. Which would be sizeable if every app on your
| system was using Japanese, or worse, Chinese, and making a
| copy of all this stuff.
| robertlagrant wrote:
| I really feel as though Vulkan is a brilliant leveller, with
| the chance to replace DirectX with a cross-platform, open
| source standard, funded by Valve and Sony? Sign me up.
| 10x-dev wrote:
| In my experience it's the coordination and mental overhead
| between the platform teams that kills productivity.
|
| I suspect that hiring and training cross platform developers,
| then having them own a feature across all platforms will
| significantly increase speed of delivery of that feature. These
| are typically called feature teams and they are most effective
| when there are backend developers on the team as well.
|
| The trade-off is that now the new feature teams are not
| communicating between each other and coordinating on the common
| code between them, which starts affecting productivity.
|
| In the end, regardless of how the new VP of engineering likes to
| split the teams and get praised for solving the current problem
| by introducing another one down the road, the trade off for
| increased size is loss of productivity due to synchronization
| overhead between the people involved.
| blacktriangle wrote:
| I've been the cross-platform dev implementing every feature
| across 3 platforms, its a miserable job. Besides feeling like
| you're living through Groundhog Day, the mental burden of
| constant context switches between languages and APIs wears you
| down over time, and that's before you look at the effort
| required to stay current on all your supported platforms.
|
| I would never organize a business like that again.
| d--b wrote:
| I can't help but believe that the native vs crossplatform
| tradeoff will eventually go away when someone does a good enough
| crossplatform library...
|
| Video games are cross-platform and polished and fast and they
| have been so for a while now.
|
| When someone comes up with a Unity for desktop applications,
| that's when this problem is going to go away.
|
| I hope Sciter.Js is going to be it.
| Zababa wrote:
| Video games often have not that much consistency between each
| others, aside from a few basic keys. Thus, they haven't really
| solved the tradeoff. Part of the complaint against the cross-
| platform apps is that you have to adapt yourself to the
| workflow of the app, instead of the app having to adapt itself
| to the workflow of the platform.
| d--b wrote:
| Sure, though it's debatable that it's a plus.
|
| I switch between computers often, and I am happy that my
| spotify looks the same here and there. I really don't want my
| spotify app to feel like gimp on Linux and like Excel on
| Windows...
| Zababa wrote:
| That's true. I'm personally happy enough that I get to have
| almost all of the apps I need on Linux with this cross-
| platform trend. I also use Linux at home and Windows at
| work, so a cross-platform experience fits me. But I can see
| how it's frustrating to be left behind when you were used
| to your platform and people adapting their software to it.
|
| For videogames, I think it makes sense that many have
| different controls. Trying to force the same controls would
| make some very hard to play. But I can see people arguing
| that most apps aren't as specialized as video games, and
| thus shouldn't need this level of personalization. There is
| the same argument to be made with special fonts for your
| apps, vs trying as much as you can to use the system ones.
| robertlagrant wrote:
| To give a counterexample, Microsoft Teams notifications on
| MacOS can't be dragged offscreen; I have to wait for them
| to vanish. They're not using the native notifications tech
| (who knows why), and so they're jarring compared to all the
| nice MacOS applications.
| JamesSwift wrote:
| And with that you will lose all sorts of quality-of-life. e.g.
| tab order, accessibility, hotkeys, etc. All of that has to be
| recreated to be a replacement.
| mook wrote:
| Video games are immersive experiences: you're interacting with
| only the video game when you play it (or at least, that's the
| design), and you don't experience the jarring from task
| switching because you don't switch.
|
| For desktop applications -- especially a password manager whose
| main use involves switching to it quickly to find something to
| enter into a different application -- there is a lot of that
| resistance when you go between apps that feel totally
| different.
|
| (I currently work on an Electron app -- but that's because it
| was already one when I joined the team, and it's in a space
| where time to market for multiple platforms is definitely more
| important than a good polished experience, at least at the
| stage we're at. Sad as that is.)
| Ericson2314 wrote:
| I worry that everyone is trained for web, no one is trained to
| write native apps outside of phones, and so the problem will
| become harder to correct.
| horsawlarway wrote:
| I don't actually know that this is a problem.
|
| The web is a pretty damn good distribution method for software.
| The user simply clicks a link and is provided with valuable
| features. No install process. No IT approval process. No
| thought at all, really, about how that code runs on their
| machine and does things that are valuable to them.
|
| Frankly - We're still inching towards the browser being the OS.
| I don't want a clunky app that needs to be installed on all my
| devices, and which has a limited feature set compared to the
| web: I just want the website.
|
| And for the vast majority of "productivity" tools - networking
| and sharing aren't backseat things, they're literally the most
| important part of the product (see Figma, for example)
|
| ---
|
| Long story short, you're saying this is a "problem to correct".
| I disagree - I think the problem these tools are correcting is
| that native distribution methods (up to and including the
| current mobile walled-garden app-store fuckery) simply suck.
| They suck SO much compared to simply opening a Url in a
| browser.
| prewett wrote:
| The web is a good _distribution method_. However, HTML /CSS
| was intended to display the equivalent of MS Word documents,
| and is completely unsuited for general purpose UI. In fact,
| we know how general purpose UI should look like, because all
| the non-browser UI toolkits look pretty similar. And it's
| nothing like HTML/CSS.
| PaulDavisThe1st wrote:
| > The web is a pretty damn good distribution method for
| software.
|
| ... that can and does run inside a browser. There's a wide-
| world of software that doesn't run inside a browser right
| now, and some serious arguments about why it probably never
| should.
|
| _That 's_ where the problem lies, not with yet another
| app/web-page that provides you with a view of some database
| columns and rows.
| zepto wrote:
| The web is _more_ fickle and opaque than the App Store.
|
| It's still a great way to deliver certain kinds of
| application, but we need an alternative.
| horsawlarway wrote:
| > The web is more fickle and opaque than the App Store.
|
| You have some examples of what you mean by fickle? I'm not
| really sure I understand.
|
| In basically every situation I can think of, the browser is
| less fickle, more consistent, and more backwards compatible
| than an app store.
|
| The only benefit to using an app over a website is offline
| access - which is moot if you don't have the app installed
| already, since the app download will certainly be bigger
| than the page load, and it's also the problem electron
| nicely solves for those cases.
| zepto wrote:
| > In basically every situation I can think of, the
| browser is less fickle, more consistent, and more
| backwards compatible than an app store.
|
| There is no guarantee of anything from any web app. Your
| data can be used for anything the provider likes. There
| are literally no guidelines.
|
| > The only benefit to using an app over a website is
| offline access - which is moot if you don't have the app
| installed already
|
| In almost every single use case you will have the app
| installed already.
|
| Electron solves literally no problems with web apps.
| Electron apps are not web apps and do not run in the
| browser. Web apps do not use electron. The fact that some
| code may be portable between the two is irrelevant to the
| user.
| horsawlarway wrote:
| > There is no guarantee of anything from any web app.
| Your data can be used for anything the provider likes.
| There are literally no guidelines.
|
| This is a feature, not a problem. To add, it's also not
| true at all. The browser sandbox is the gating.
|
| >Electron apps are not web apps and do not run in the
| browser.
|
| This makes me think you don't actually know what electron
| is.
|
| Have a good one.
| zepto wrote:
| > The browser sandbox is the gating.
|
| You really think the browser sandbox limits what the
| website can do with the data on their servers?
|
| > This makes me think you don't actually know what
| electron is.
|
| Do you think electron is a web browser?
|
| I think it's a toolkit that let's you use JavaScript,
| HTML and CSS to build a standalone app.
|
| Web apps aren't defined by the programming language they
| use. They are defined by the fact that they run on the
| web - I.e. in a browser talking to web servers.
| horsawlarway wrote:
| No disrespect, but I think you're either uninformed or
| misguided on the topic.
|
| The renderer processes in Electron are literally
| "BrowserWindow" instances...
| https://www.electronjs.org/docs/api/browser-window
|
| The whole process model for electron is almost identical
| to the process model for WebExtensions (a single process
| manages renderer processes, which are instances of
| browser window objects.).
|
| I don't recommend this, but I've done it and it works -
| your whole electron app can be a main process that
| literally caches the resources from your site, and then
| displays them in a renderer view.
| zepto wrote:
| >No disrespect, but I think you're either uninformed or
| misguided on the topic.
|
| No disrespect, but nope. Nothing you have said here
| contradicts what I said.
|
| Electron is not a browser. It is a toolkit that lets you
| use web technologies to build standalone apps.
|
| Any app can embed a JavaScript engine or web renderer and
| cache code from the web, _even on iOS_. That isn't a
| special feature of electron.
| jcelerier wrote:
| > Any app can embed a JavaScript engine or web renderer
| and cache code from the web, even on iOS
|
| and we would call that a browser
| zepto wrote:
| No, we don't call any app that embeds a web renderer or
| uses a JavaScript engine 'a browser'.
|
| Do you have any idea how many apps do this?
| horsawlarway wrote:
| > You really think the browser sandbox limits what the
| website can do with the data on their servers?
|
| And that is different than the mobile app store, how,
| exactly?
|
| Data you provide to a company is theirs to do with as
| they please - whether it was ingested through a Iphone
| app or a website makes absolutely zero difference.
| zepto wrote:
| The difference between App Store apps and web apps is
| that many App Store apps _work on local files or files
| stored in iCloud_ that are never ingested by the company
| that provided the app.
|
| This is not true of web apps.
| yunohn wrote:
| I believe the web is the future, and ChromeOS is a great
| example. Native apps are dying, and with good cause - it's not
| worth having hundreds of developers split across multiple
| platforms.
|
| The goal of any company is to provide a useful service/product,
| not necessarily a "native" app to satisfy HNers.
| Zababa wrote:
| That's a great article. I think I understand better the anger
| that certain people (often mac users) express when a product
| switches from a native app to a cross-platform app. I always
| thought it was about cost, and that the solution was to pay more.
| But it seems to be about the business thinking they know better
| than the user what a good user experience is. If you're picking a
| platform for the consistency of user experience, I understand how
| frustrating (and patronizing) that can feel.
|
| I want to apologize to the few people that I talked to about this
| here on HN. I didn't understood your side.
| SavantIdiot wrote:
| As long as there are platforms with enough market cap, there will
| be a need for cross-platform. And the easiest path wins.
| ElectronJS is the easiest path. My company relies on it.
___________________________________________________________________
(page generated 2021-09-03 23:02 UTC)