The slow death of Electron & Co?
Electron apps like Discord, Slack, etc. don't seem to gain any benefit from being wrapped in Electron anymore. Have one codebase, one app, that works everywhere and can now even be "installed" with Safari.
555 karma · joined December 3, 2021
Electron apps like Discord, Slack, etc. don't seem to gain any benefit from being wrapped in Electron anymore. Have one codebase, one app, that works everywhere and can now even be "installed" with Safari.
I agree the sys admin stuff, no thanks. the appeal of "serverless edge", at least to me, is ease of deployment. but, that ease of deployment is tooling / git integration rather than the underlying architecture.
the benefit of "your functions are globally distributed" has yet to appeal to me. for large ecommerce maybe. but then again, just deploy your servers in a distributed fashion which is "easy" if no state persistent is involved and tooling like fly.io is emerging.
i started my web dev journey with JAMStack, Vercel, the "edge". everything is easy as long as one only deploys a full-stack NextJS app. the moment other apps come in, just use a server deployed as VPS and avoid "edge runtime hell". edge runtime hell refers to "you can't do this (function with over 2MB payload), you can't do that (because not supported by X)".
EDIT: I implicitly meant with "deploy as VPS" -> deploy your server via Render/Heroku/CI-CD instead of serverless functions running on the "edge".
> Are you referring to the part that solid components "disappear" at runtime? Or that solid signals can be used outside of components?
My mental model of Solid's reactivity is "plain JS". Components are also "plain JS" with a bit of syntactic sugar that auto injects one effect on render. No hook rules etc. That should make reasoning about Solid apps easier (in theory) and we might use the reactivity system outside of UI. In particular, we need to develop a filesystem implementation for the browser that could benefit from Solid's reactivity system.
> I looked at that RFC and i found it interesting that Svelte was considered, but Vue wasn't
I started my web dev journey with Svelte (coming from Python + Flutter). The first prototypes were built in Svelte. It became clear that Svelte might be too restrictive for a complex SPA. Solid felt/feels like a baby of Svelte + React.
The decision for SolidJS, and likely the differentiator to Jotai et al., is simplicity. The reactive system (signals) are de-coupled from rendering. SolidJS is not doing a good job communicating that fact. The de-coupling leads to a simple reactive model that works in plain JS and thereby JSX too.
I recommend this video https://www.youtube.com/watch?v=J70HXl1KhWE
The state issues we have right now are non-issues with SolidJS. They don't trigger re-renders and thereby don't degrade the user experience.
RE Vue JS: The nice thing about Solid is that state is de-coupled from rendering. I thought that building complex state with Solid will be easier than frameworks that couple state to rendering. I haven't evaluated VueJS in depth though. Here is an RFC I wrote about choosing Solid https://github.com/inlang/inlang/blob/main/rfcs/tech-stack/R...
no hosting, extra accounts, or synchronization required. use git(hub) workflows like pull requests.
I will update the readme!
> No one bothers to consider: what are the workflows that people actually want to do? What are the features that would make those workflows easier?
What a coincidence, I just created a document [0] that collects engineering and UX issues that we are running into with inlang (localization infrastructure built on git) [1]. Part of bringing version control to people outside of software engineering is fixing UX related issues.
For example, your proposed `sync` command is interesting. Our observations lean towards some real-time collaboration workflow that could make `pull, push, sync` workflows redundant. Applications that benefit from version control like a next-gen Figma, Adobe Premiere, Excel, etc. require real-time collaboration. A question that I've been asking myself whether real-time collaboration in software engineering makes sense too. To be elaborated! :)
[0] https://github.com/inlang/inlang/blob/main/content/git-sdk-n...
Why are you onboarding this co-founder?
Motivation and quick learning skills can be an illusion for the lack of skills, network and experience that will bring the company forward: „This person has none but this person is really motivated and eager to learn!“.
If the previous quote resembles your line of thought, you should question the co-founder position. The person could start as regular employee (you have money), prove themselves and „earn“ the co-founder position.
I have experience with this situation and can share more details privately. Feel free to write me a mail proxy+hn32@stroschein.me
I am working on dev-first localization infrastructure after being frustrated with i18n from a dev perspective myself. Your remarks seem like they fit into the infrastructure approach I am taking. See https://github.com/inlang/inlang
other than that, no gatchas i encountered. i would choose vite-plugin-ssr again.
SvelteKit might offer a slightly higher DX by being the new kid on the block that learned from NextJS and Co. The big difference is just Svelte vs React. Svelte is delighting to use but a headless UI library, or generally good UI lib is missing and JSX has its advantages. The advantages of JSX being more flexible and better TypeScript support. I decided to go with Solid for a new project. Solid combines Svelte's easier reactivity and JSX. More about the rationale behind choosing Solid can be read in an RFC I wrote https://github.com/inlang/inlang/blob/main/rfcs/002-tech-sta...
Vite-plugin-ssr describes itself as "Like Next.js/Nuxt but as do-one-thing-do-it-well Vite plugin.". I use it for https://github.com/inlang/inlang. The control and ownership of the underlying rendering techniques is truly relieving and enables us to run static sites + a high dynamic (client-side rendered) app in one monolith instead of the typical static site + app.domain.com split.
Version control infrastructure that potentially enables a new gen of professional apps. This new gen build-in automation and collaboration between departments.
We are building developer-first localization infrastructure as a testbed for our hypothesis, which by itself solves a large problem: Offering software in multiple human languages is too damn hard.
Looking for early stage employees with engineering background(s). Preferably a design engineer (designer who can write production code). Tasks span product, engineering and distribution.
contact me if you want to know more about our hypothesis and/or localization infrastructure under samuel.stroschein [at] inlang [.] com
[0] https://www.bemopro.com/hs-fs/hubfs/slack%20vs.%20teams.jpg?...
Nobody said that macOS has "terrible UI". Some people expressed that the window management in MacOS is inferior to Windows. I laid out UX reasons why macOS window management is inferior to Windows.
I will not participate in further discussion.
The right click Mac OS solution is the best example. By default, right click on MacOS is deactivated. Even if someone right clicks on an app icon, that person has to click AND process the titles windows instead of seeing a visual preview as on Windows of the window.
Windows has great window management = less chaos, less orphan open windows Mac OS has inferior window management = chaos, hundreds of open windows
The main reasons stems from the fact that Windows open window discoverability is higher. Open windows are always displayed in the menu bar. MacOS only displays the app icon but provides no information about the open windows except for pressing F3.
I hope that answer makes sense.
I tried out uBar for Mac OS https://ubarapp.com/. Too buggy though.
PS There is a small web sdk that enables comments on sited via github issues. see https://github.com/utterance/utterances
Correct, the term git backend refers to git as a content database (with built-in version control and automation).
Regarding front aid, great to see fellow startups working on solution built on git. It took months to realize the benefits of git and the logical step to build the backend on git. sorry, use git as the content database.
PS ty, fixed the links! :)