-
I have a system built on top of workflowy. In there is my main gigantic tree of bullets and I truly have everything in there: personal, hobbies, work, packing lists, checklists, meeting notes, etc. I use tags to mark a handful of things that need attention soon, #p for personal and #w for work. I have a workflowy favorite that filters the huge tree down to just those bullets tagged as such so at any time I can fit on a single screen everything I need to get done near term. As that list gets small, I revisit the main things, reprioritize, and choose what gets tagged for completion next.
I have a daily routine thing similar to pushcx but it’s got a bit more smarts in it and it’s basically a template of a full week. So it knows what day of the week today and tomorrow are and allows me to tweak each day’s daily routine for weekly things like fitness class every Tue at 6pm, taking it easy on the weekends, etc. Each day I have a script that spits that out and I paste it into workflowy, cross-reference my calendar for any meetings/appointments to remember, and then just go about checking them off. My feelings on this are basically the same as pushcx’s: it’s helpful to have that and I’m pretty rigorous about it being realistic and achievable. There’s generally a morning and afternoon block for work and for that I switch to a particular project’s area in workflowy for the details and next steps for a particular work project.
-
From my perspective lobsters is already federated hacker news for nice people.
-
-
-
Not in the mastodon definition but in terms of the web itself, it is. Don’t like this discussion forum over here, go use this other one over there with different servers, different community, different norms. Counts as federated in my book.
-
-
-
This matches my experience. I’m many months and at least two books worth of reading into my rust journey and I’m still struggling a lot. I think the language actually requires such an enormous change in how I plan my program, which tools I use, and how a program is coded that I might need to just start over and not assume anything. The actual coding process I use in other languages, which is write an iota of code, run it, rinse repeat doesn’t seem to be viable in rust and I need to figure out what the fluent rust coders actually do at an expression-by-expression level of detail.
-
I’m not a “fluent Rust coder”, but from the Rust I have coded a Haskellish strategy seems to work: write an iota of code, try to compile it, rinse repeat (eventually run when it compiles. sometimes.)
-
I get into trouble a few minutes later when I realize I used the wrong type for something (like I used String but whoops I should have used Path). Now all of a sudden I’ve got tons of unused import warnings and like 0% of the string API overlaps with the Path API and I have to basically start a fresh project and port the code over based on the dependency graph bit by bit.
-
-
-
OK well I guess the debate in my mind about bzip2 vs xz is over now.
-
-
JS standard lets developers put stuff on prototypes, that’s game over, NO LANGUAGE UPDATE should EVER put stuff there, period
JS standard lets developers put stuff on the global window object. So does that mean no new globals can be added to the language ever?
I wish the discussion here wasn’t about what to do in this case or that case but how to change the language in a fundamental way such that this entire class of issues cannot happen in the future.
-
I think this is a misguided blaming of the language when the programmer is at fault. If you are catching an exception in JavaScript, verify the type of exception before continuing. This is just a straightforward necessity when you don’t have a language with static types.
So there are two programmer errors in the example: the typo of ‘sedn’ and the absence of a branching for the ‘nouser’ exception.
I get that it’s not fun and the overall point is that JavaScript should handhold the programmer a bit better, but hey, it’s JavaScript and we’re used to Stockholm syndrome.
-
-
I think verifying the type of the exception is difficult in practice. It is not a uniform practice to use granular “subclasses” so the
instanceofoperator can’t really help with application-specific or library-specific errors. You end up with very ad-hoc set of codes or flag properties that are just in no way comprehensive, stable, or reliable. I think the best you can do is what bounce does which is detect the 6 known programmer errors, but now we’re basically accepting the fact that what javascript itself provides is just not sufficient to properly categorize.
-
-
Aside from the control flow aspect, I think promises are poisoned by exceptions which are very problematic in a dynamically typed language. Here’s my blog post on the problem with try catch which gets brought along into promises, which get brought along into async/await. The only solution I’ve seen proposed for this is bounce.
-
-
Interesting read. Another solution could be to yield a promise from a generator and re-enter the generator with a list of two items. The first representing a potential error (or undefined) and the second the actual resolved value. This way we could handle errors ala Golang and avoid mixing exceptions with operational errors.
-
-
I have a layer of navigation (arrows, page up/down, home/end) plus formatting (delete, backspace, space, tab) all accessible with my left hand in the home position. here’s an image of my L1 layer. As a bonus my right hand has pairs of coding punctuation on this layer.
-
Some of us miss native desktop applications that worked well. It’s tragic that desktop platforms are utterly non-interoperable and require near-complete duplication of every app. But at the same time not everyone is satisfied with the solution of “build them all as electron apps starting with a cross-platform browser base plus web technology for the UI”. I can sympathize with app developers who in no way want to sign up to build for 2 or 3 platforms, but I feel like berating dissatisfied users is unjust here. Try comparing a high quality native macOS app like Fantastical with literally any other approach to calendar software: electron, web, java, whatever. Native works great, everything else is unbearable.
-
I think people are just tired of seeing posts like Electron is cancer every other day. Electron is here, people use it, and it solves a real problem. It would be much more productive to talk about how it can be improved in terms of performance and resource usage at this point.
-
-
There’s a huge opening in the space for something Electron-like, which doesn’t have the “actual browser” overhead. I’m certain this is a research / marketing / exposure problem more than a technical one (in that there has to be something that would work better we just don’t know about because it’s sitting unloved in a repo with 3 watchers somewhere.)
Cheers!
-
There’s a huge opening in the space for something Electron-like, which doesn’t have the “actual browser” overhead.
Is there? Electron’s popularity seems like it’s heavily dependent on the proposition “re-use your HTML/CSS and JS from your web app’s front-end” rather than on “here’s a cross-platform app runtime”. We’ve had the latter forever, and they’ve never been that popular.
I don’t know if there’s any space for anything to deliver the former while claiming it doesn’t have “actual browser” overhead.
-
“re-use your HTML/CSS and JS from your web app’s front-end”
But that’s not what’s happening here at all - we’re talking about an application that’s written from the ground up for this platform, and will never ever be used in a web-app front end. So, toss out the “web-app” part, and you’re left with HTML/DOM as a tree-based metaphor for UI layout, and a javascript runtime that can push that tree around.
I don’t know if there’s any space for anything to deliver the former while claiming it doesn’t have “actual browser” overhead.
There’s a lot more to “actual browser” than a JS runtime, DOM and canvas: does an application platform need to support all the media codecs and image formats, including all the DRM stuff? Does it need always on, compiled in built-in OpenGL contexts and networking and legacy CSS support, etc.?
I’d argue that “re-use your HTML/CSS/JS skills and understanding” is the thing that makes Electron popular, more so than “re-use your existing front end code”, and we might get a lot further pushing on that while jettisoning webkit than arguing that everything needs to be siloed to the App Store (or Windows Marketplace, or whatever).
-
But that’s not what’s happening here at all - we’re talking about an application that’s written from the ground up for this platform, and will never ever be used in a web-app front end. So, toss out the “web-app” part, and you’re left with HTML/DOM as a tree-based metaphor for UI layout, and a javascript runtime that can push that tree around.
Huh? We’re talking about people complaining that Electron apps are slow, clunky, non-native feeling piles of crap.
Sure, there are a couple of outliers like Atom and VSCode that went that way for from-scratch development, but most of the worst offenders that people complain about are apps like Slack, Todoist, Twitch – massive power, CPU, and RAM sucks for tiny amounts of functionality that are barely more than app-ized versions of a browser tab.
“Electron is fine if you ignore all of the bad apps using it” is a terribly uncompelling argument.
-
Huh? We’re talking about people complaining that Electron apps are slow, clunky, non-native feeling piles of crap.
Sure, there are a couple of outliers like Atom and VSCode that went that way for from-scratch development, but most of the worst offenders that people complain about are apps like Slack, Todoist, Twitch – massive power, CPU, and RAM sucks for tiny amounts of functionality that are barely more than app-ized versions of a browser tab.
“Electron is fine if you ignore all of the bad apps using it” is a terribly uncompelling argument.
A couple things:
- Literally no one in this thread up til now has mentioned any of Slack/Twitch/Todoist.
- “Electron is bad because some teams don’t expend the effort to make good apps” is not my favorite argument.
I think it’s disingenous to say “there can be no value to this platform because people write bad apps with it.”
There are plenty of pretty good or better apps, as you say: Discord, VSCode, Atom with caveats.
And there are plenty of bad apps that are native: I mean, how many shitty apps are in the Windows Marketplace? Those are all written “native”. How full is the App Store of desktop apps that are poorly designed and implemented, despite being written in Swift?
Is the web bad because lots of people write web apps that don’t work very well?
I’m trying to make the case that there’s value to Electron, despite (or possibly due to!) it’s “not-nativeness”, not defending applications which, I agree, don’t really justify their own existence.
Tools don’t kill people.
-
-
we’re talking about an application that’s written from the ground up for this platform, and will never ever be used in a web-app front end.
I’m really not an expert in the matter, just genuinely curious from my ignorance: why not? If it is HTML/CSS/JS code and it’s already working, why not just uploading it as a webapp as well? I always wondered why there is no such thing as an Atom webapp. Is it because it would take too long to load? The logic and frontend are already there.
-
I’m referring to Atom, Hyper, Visual Studio Code, etc. here specifically.
I don’t think there’s any problem with bringing your front end to desktop via something like Electron. I do it at work with CEFSharp in Windows to support a USB peripheral in our frontend.
If it is HTML/CSS/JS code and it’s already working, why not just uploading it as a webapp as well?
I think the goal with the web platform is that you could - see APIs for device access, workers, etc. At the moment, platforms like Electron exist to allow native access to things you couldn’t have otherwise, that feels like a implementation detail to me, and may not be the case forever.
no such thing as an Atom webapp
https://aws.amazon.com/cloud9/
These things exist, the browser is just a not great place for them currently, because of the restrictions we have to put on things for security, performance, etc. But getting to that point is one view of forward progress, and one that I ascribe to.
-
-
-
-
-
I can think of a number of things that could be done off top of my head. For example, the runtime could be modularized. This would allow only loading parts that are relevant to a specific application. Another thing that can be done is to share the runtime between applications. I’m sure there are plenty of other things that can be done. At the same time, a lot can be done in applications themselves. The recent post on Atom development blog documents a slew of optimizations and improvements.
-
-
-
It’s tragic that desktop platforms are utterly non-interoperable and require near-complete duplication of every app.
It’s a necessarily sacrifice if you want apps that are and feel truly native that belong on the platform; a cross-platform Qt or (worse) Swing app is better than Electron, but still inferior to the app with a UI designed specifically for the platform and its ideals, HIG, etc.
-
If we were talking about, say, a watch vs a VR system, then I understand “the necessary sacrifice” - the two platforms hardly have anything in common in terms of user interface. But desktops? Most people probably can’t even tell the difference between them! The desktop platforms are extremely close to each other in terms of UI, so I agree that it’s tragic to keep writing the same thing over and over.
I think it’s an example of insane inefficiency inherent in a system based on competition (in this case, between OS vendors), but that’s a whole different rabbit hole.
-
I am not a UX person and spend most of my time in a Terminal, Emacs and Firefox, but I don’t think modern GUIs on Linux (Gnome), OS X and Windows are too common. All of them have windows and a bunch of similar widgets, but the conventions what goes where can be quite different. That most people can’t tell, does not mean much because most people can’t tell the difference between a native app and an electron one either. They just feel the difference if you put them on another platform. Just look how disoriented many pro users are if you give them a machine with one of the other major systems.
-
I run Window Maker. I love focus-follows-mouse, where a window can be focused without being on top, which is anathema to MacOS (or macOS or whatever the not-iOS is called this week) and not possible in Windows, either. My point is, there are enough little things (except focus-follows-mouse is hardly little if that’s what you’re used to) which you can’t paper over and say “good enough” if you want it to be good enough.
-
-
-
It’s tragic that desktop platforms are utterly non-interoperable and require near-complete duplication of every app.
There is a huge middle ground between shipping a web browser and duplicating code. Unfortunately that requires people to acknowledge something they’ve spent alot of time working to ignore.
Basically c is very cross platform. This is heresy but true. I’m actually curious: can anyone name a platform where python or javascript run where c doesn’t run?
UI libraries don’t need to be 100% of your app. If you hire a couple software engineers they can show you how to create business logic interfaces that are separate from the core services provided by the app. Most of your app does not have to be UI toolkit specific logic for displaying buttons and windows.
Source: was on a team that shipped cross platform caching/network filesystem. It was a few years back, but the portion of our code that had to vary between linux/osx/windows was not that big. Also writing in c opened the door for shared business logic (api client code) on osx/linux/windows/ios/android.
Electron works because the web technologies have a low bar to entry. That’s not always a bad thing. I’m not trying to be a troll and say web developers aren’t real developers, but in my experience, as someone who started out as a web developer, there’s alot of really bad ones because you start your path with a bit of html and some copy-pasted javascript from the web.
-
There’s nothing heretical about saying C is cross-platform. It’s also too much work for too little gain when it comes to GUI applications most of the time. C is a systems programming language, for software which must run at machine speed and/or interface with low-level machine components. Writing the UI in C is a bad move unless it’s absolutely forced on you by speed constraints.
-
-
It’s tragic that desktop platforms are utterly non-interoperable and require near-complete duplication of every app.
++ Yes!
Try comparing a high quality native macOS app like Fantastical with literally any other approach to calendar software: electron, web, java, whatever. Native works great, everything else is unbearable.
Wait, what? I think there’s two different things here. Is Fantastical a great app because it’s written in native Cocoa and ObjC (or Swift), or is it great because it’s been well designed, well implemented, meets your specific user needs, etc? Are those things orthoganal?
I think it’s easy to shit on poorly made Electron apps, but I think the promise of crossplatform UI - especially for tools like Atom or Hyper, where “native feeling” UI is less of a goal - is much too great to allow us to be thrown back to “only Windows users get this”, even if it is “only OS X users get this” now.
It’s a tricky balancing act, but as a desktop Linux user with no plans to go back, I hope that we don’t give up on it just because it takes more work.
Cheers!
PS: Thanks for the invite, cross posted my email response if that’s ok :)
-
Wait, what? I think there’s two different things here. Is Fantastical a great app because it’s written in native Cocoa and ObjC (or Swift), or is it great because it’s been well designed, well implemented, meets your specific user needs, etc? Are those things orthoganal?
My personal view is that nothing is truly well designed if it doesn’t play well and fit in with other applications on the system. Fantastical is very well designed, and an integral part of that great design is that it effortlessly fits in with everything else on the platform.
“Great design” and “native” aren’t orthogonal; the latter is a necessary-but-not-sufficient part of the former.
-
“Great design” and “native” aren’t orthogonal; the latter is a necessary-but-not-sufficient part of the former.
Have to agree to disagree here, I guess. I definitely can believe that there can be well-designed, not-native application experinces, but I think that depends on the success and ‘well-designed-ness’ of the platform you’re talking about.
As part of necessary background context, I run Linux on my laptop, with a WM (i3) rather than a full desktop manager, because I really didn’t like the design and cohesiveness of Gnome and KDE the last time I tried a full suite. Many, many apps that could have been well designed if they weren’t pushed into a framework that didn’t fit them.
I look at Tomboy vs. Evernote as a good example. Tomboy is certainly well integrated, and feels very native in a Gnome desktop, and yet if put next to each other, Evernote is going to get the “well-designed” cred, despite not feeling native on really any platform it’s on.
Sublime Text isn’t “native” to any of the platforms it runs on either.
Anyway, I feel like I’m losing the thread of discussion, and I don’t want to turn this into “App A is better than App B”, so I’ll say that I think I understand a lot of the concerns people have with Electron-like platforms better than I did before, and thank you for the conversation.
Cheers!
-
-
-
-
focusaurus
7 months ago
|
link
| on:
How have you proved to (prospective) employers that you've 'leveled up' in your career?
In one case of going from engineer on feature X to tech lead of feature X I demonstrated ability without knowing I was being tested for this role from the start. The existing tech lead was having health problems effecting their work and my hindsight read of the situation is that management wanted to fire them but was not comfortable with the risk of doing that before identifying a replacement. So I was brought onto that team and of course was not informed of the situation, so I was unaware. After a few months when it was clear I could handle the technical aspects and teamwork aspects, management promoted me. Of course this was not across companies, this was within the same company. Definitely easier to go up in the same company and making lateral moves between companies should not require any special proving.
-
And just for more concrete data, at one point my next direct technical move up would have been to a formal title within BigCo that was about 7 defined levels above entry level and 1 level below “Fellow” which was a terminal level for folks with a suitcase full of patents, buildings named after them, etc. That role had very specific and fairly stringent requirements that were well documented. If I wanted to pursue it, BigCo made it very easy to understand exactly what was required and how to go about it. Again this is for internal moves.
-
Thanks for sharing, I appreciate it and it teaches me a lot. My experience at a medium-sized company has been much the opposite unfortunately: it’s very hard to understand what opportunities are available and what the requirements are. Perhaps this fact is the most telling :)
-
-
-
There are a lot of great blog posts written by ‘recursers’. Those posts are usually spread out on different blogs though. Does anyone know if they are aggregated somewhere?
-
-
FYI, other projects call this their planet. See http://planet.mozilla.org/ or http://planet.debian.org/ or http://planet.ubuntu.com/
-
-
I’d really like this.
-
-
I was just thinking today that a huge benefit of doing Recurse Center was exposure to so many great blogs/bloggers I otherwise wouldn’t have encountered.
-
-
Bandwidth is getting cheaper all the time, whereas bugs are eternal.
What? No. Opposite of that.
-
-
Yes, either more expensive (like when your 2-year Comcast initial price suddenly increases by like $40/month) or basically same level of expensive as it was 20 years ago.
But my main issue is anyone in software claiming relying on the network to be fast or reliable which has never been and currently is not the case, and I’m infuriated daily by software that makes such assumptions.
-
I share your frustration with software that assumes an always-available network.
But it’s absolutely not the case that bandwidth costs the same or more than it did 20 years ago: 20 years ago was 1997; cable modems were just getting started and the majority of people were still on dial-up!
-
-
-
-
node.js/npm
- Dependency categorization is a bad abstraction. Just prod and dev, but no build-only, test-only, debug-only, or CI-only dependencies.
- Artifacts are not portable because native add-ons are so common. Arguably this is a gripe about node.js the platform itself but one of the reasons a team may choose a scripting language is so they DON’T have to deal with C-level library linking errors and incompatibilities.
- npm packages are bloated by default with docs, tests, random dev-only files when uploaded to the registry
All of them
- Even after how many decades, AFAIK there’s not really any cross-platform tool that can be relied upon to be pre-installed on any developer machine, even if it’s purpose is solely to facilitate installation of a language-specific and update-to-date build tool. On linux and mac it’s pretty safe to assume usable (perhaps old but not ancient) versions of python and bash are pre-installed but still not yet the case reliably on windows AFAIK.
- I don’t believe there’s much of any sharing of architecture or implementation code for common cross-language needs in a modern environment like secure efficient downloads, caching, integrity checking, archiving, compressing, etc.
https://peterlyons.com/problog