Looks nice and clean! Also feels very snappy in two tabs.
However, you're breaking the back button with your redirect to a unique room. Once in a room, pressing back will join a new room. History replace instead of push should be a better choice.
Location: Munich / Germany
Remote: Yes (onsite preferred)
Willing to relocate: No
Technologies: TypeScript/C#/Elixir/C/Rust Web/Embedded/DevOps React/VueJS/NestJS/Absinthe/Postgres/Redis/Docker/Kubernetes
Résumé/CV: https://www.dellinger.dev/resume/
Email: jonas [that-symbol] dellinger.dev
I'm nearing the end of my CS master and I'm currently looking for a summer internship for 2021 (flexible regarding date/duration). I'm mostly interested in backend or embedded work, but in the end I'm very open for interesting projects of other fields as well.
In .NET we have a very similar tool for creating such packed binaries, dotnet-warp. I used it in one of my projects and quite liked it, since it's also quite easy to cross compile (cross-pack?) for the 3 major operating systems.
I like the general idea, your independent of the system wide framework version and it still has this "one-click" install procedure (dropping the binary in your path). However, I guess this is also the negativ Part. Users don't expect that a single binary extracts itself to somewhere --> uninstalling the binary leaves traces on the system.
Definitely looking forward to try it out for elixir, wondering how fast the erlang/elixir startup really is.
The last time I touched anything .NET was about a decade ago. My somewhat old-school superiors were unimpressed with the ability to come up with a plain .exe at the end of the process. My lack of familiarity with how Visual Studio had evolved certainly played into it; the IDE made me feel like a chimp dropped into an airliner cockpit. I had the worst time trying to figure out how to turn off the "of course you have an enterprise server dedicated to delivering upgrades!" setting. None of it seemed to, uh, scale down for our piddly purposes.
.NET Core is a ground-up rewrite of the frameworks and tools. It's completely decoupled from Visual Studio. This would get you started on a toy project (one source file, one project file) now:
Yes, since Java 9: it is called "jlink" and it's shipped with the OpenJDK. It assumes you have modularized jars.
An alternative is the GraalVM, which can compile the code as a C++ binary or a shared application, using LLVM as backend.
If you work with Webservices (especially JavaEE), you might also want to have a look at Quarkus, which also uses GraalVM to create single binary executables
jlink/jpackage just isn't the same as the other things. It doesn't produce a single executable like .Net core or Bakeware which embed the vm into the binary. In .Net's case it self extracts on first run.
With jlink/jpackage you either ship an installer or a zip file.
So I recently had the opportunity to use the new composition API, which will come in V3, in a project and want to share my two cents. The project had some limitations tho: no webpack and no typescript (so basically inline x-templates and pure browser JS).
Starting of with the composition API was great. No "this", easy reuse of logic via react-like "useXYZ" hooks and a general fast development. But two things really bugged me:
* You need to be really careful when passing around values and how you handle them. Destructure a Proxy object? You instantly lose reactivity. Not using a reference to proxy object in computed? Changes won't trigger the computed function. There is a lot of magic involved and while it may seem that it takes a lot of "thinking" from you, once it doesn't work you will have to rethink and maybe even ditch some of the underlying language's features.
* "ref" vs "reactive", where "ref" is used for primitives which need a proxy object wrapper and "reactive" is used for objects/arrays. Now, my primary problem is that you again have to use specific operations based on whether your using ref or reactive. A "ref" array can be easily set to an empty array via `arr.value = []`. If you try this with a "reactive" array, you will lose reactivity; you would have to use `arr.length = 0`.
TypeScript detects a lot of those pitfalls and, IMO, it is essential when using the composition API. Without it, there is too much invisible magic happening.
I used to prefer (and by a lot) Vue more than React because of its simplicity and completeness (router + store + everything you need).
After trying to use v3 for a new project and trying out the composition API, I've gone back to React.
With v3, and the composition API, to me, it lost all of its appeal (being simple, easy and complete). Now to me it has the worst of both worlds... it's not as easy anymore, has a lot of gotchas and conceptual overhead.
The same thing happened to Meteor.js, another project with which Evan was involved. Meteor started out with an ethos of simplicity and friendly developer experience. It lost it's ethos and was picked apart in the name of "scalability". This has left people in a lurch who were drawn into Meteor for it's simplicity and now have projects to maintain in a largely abandoned framework.
I've primarily moved over to Django with server rendered content and sprinkles of JavaScript where needed.
This is the appeal of Phoenix LiveView for me. Server rendering was already incredibly fast with Phoenix, but the ability to forgo the majority of JS with LiveView bypasses all of these framework complications.
Oh well wait until you hear about Laravel. I appreciate that there is still such a large developer community committed to pushing traditional server-rendered web apps forward. Laravel has some amazing stuff for creating presentation layers within the framework, the most exciting (to me) is Livewire
Have you considered that this might be an issue on your end, and not the V3 Composition API's end?
4 year Vue dev here (right after 2.0 release). In Vue 2, you have a bunch of "magic" properties. Your state goes under the "data" key, computed properties go under "computed", methods go under... etc. Then you have the lifecycle hook magic methods: "created()", "destroyed()", etc.
In Vue 3, you have one function -- "setup()". This function returns the stuff you want to use inside of your component. This could be state/reactive data using "reactive()" or "ref()", derived data using "computed()", watchers, plain functions, whatever.
If you need to use lifecycle hooks, then you put an "onMounted(() => {})" or whatever in your "setup()".
The API was stripped down to essentially one initialization method where you set up everything you need.
Though to be fair, these days I write Vue like a weirdo and I use JSX with it.
This doesn't add up. None of the simplicity or completeness has changed, and the composition API is completely additive and optional. You can still use Vue exactly like you always have, with better performance and flexibility.
Do you use Hooks in React? Because in that framework, that actually is replacing the older methods, and if you use Hooks then the Composition API is the same (and better in many ways).
> will likely be the de facto standard if/when the majority of projects and tutorials use it.
Why would you think that? To me it sounds like a completely unbased opinion and goes agains everything that I read in the v3 documentation or in numerous discussions.
> Possibly the biggest change is our new Composition API, which is entirely additive- the previous Options API will continue to be supported, as the Composition API is an advanced feature.
Agreed. That's generally how these things are introduced.
It's a shame, because Vue as it currently stands, offers impressively simple answers, to many complicated UI development questions.
Yes I fully understand this. Also with vue2 you often get problems with the internal version of "array" that is wrapper around a normal array to detect changes.
At least a year or so ago, when I was still working on a Vue project, some external libraries didn't work with Vue reactivity due to the way it was implemented by overriding Array built in methods. I think we ran into this issue with some lodash functions.
Haven't looked @ v3, but I have a question: why would the Proxy object be available to destructure? Why not use a revocable proxy that is only a proxy when it's being modified through accessors? Why would any state management library author expose a Proxy? It should expose ubiquitous, useful, human-readable, undecorated save for maybe Symbols, JSON.
While kube-ps1 helps, remember that the context is set session-wide. So even if your last command says "development" in one terminal, another terminal may have modified the context by now.
So make sure to spam the return key before deleting stuff :D
Does anyone want to share how they use the WSL2 & X-Server combination?
In my case, I'm mostly happy with the VSCode WSL2 integration. I keep all my projects on the linux fs and it is fast to work with. The only thing which annoys me is the window management in Windows. Too much Mouse movement and random ALT-TAB-ing.
I've never got i3 to work with a Windows x server on multiple displays with high dpi. X401 also only supports a single display.
As for Windows native window management, FancyZones is better than nothing. You can overlay zones, I have split each monitor in half with two zones each, then overlayed a bunch of smaller zones for stuff like terminal windows, etc.
FancyZones is great! Already a huge enhancement to the normal windows snapping.
However, it only solves the window placing problem, not the window navigation problem. I would love to navigate with something like SUPER + LEFT/RIGHT, similar to i3. Currently the only possible way is to (CTRL)+ALT+TAB, which completely lacks window layout context and changes order depending on recent uses.
I'm curious, I always thought that devs who choose Windows do so because they like the window management and the UI tools etc. That's my reason for sure. What's stopping you from just running proper Linux with VS Code, if you don't like the way the Windows shell works?
Windows shell is a good reason not to use Windows. It's like an early 2000s KDE desktop mixed with a bunch of Gnome and ancient Motif apps. On the command line side, PowerShell isn't half bad, but it still requires you to write C# from time to time to make things work... The biggest four reasons to use something other than Linux (Mac included):
* Adobe software, MS Office, pro audio, pro video, and other income-dependent software tools mostly run on Windows and/or Macs and don't have a Linux version.
* Ease of asset management for the company (yes, it can be done with Linux, but Apple, MS and Google have great tools for managing huge numbers of computers). Google (Chrome) and Apple have a great story on configuration management by having much more consistent hardware.
* Company issued laptop (usually combined with the need for MS Office & corporate asset management)
Oh, and I love VS Code, but it really needs a full org-mode equivalent. It's the only thing that keeps me reaching for Emacs at least once a day.
The strongest argument for Windows is not its window management or UI tools, it's that you can use third-party software without dealing with too much bullshit.
On Linux, if your third-party software is available at all, it's on some third party repo you have to add manually, or maybe it's a binary which may or may not work on your particular distribution on your particular version.
This is basically the reason why I gave up on Linux on the desktop, it just hasn't gotten better in decades, it probably will never get better. The distributions have no incentive to make this work well, because first-party packages are a big selling point.
(After re-reading my own comment, I don't think I'm particularly rebuking what you said, it's turned into a "I hate computers" vent :-))
In my eyes, how Windows and Linux deal with third party software is identical...
The Windows model forever has been "you just double click an .exe or an .msi and it runs".
i.e. outside of stuff published on Windows Store (which many developers will not do), it's down to the developer to:
- Distribute their software and provide an update mechanism (download an exe? Windows Store? chocolatey? Steam / epic games launcher / origin / uplay? jetbrains toolbox? adobe software updater?)
- Deal with the many different environments (i686 vs x84, Windows XP / 7 / 8 / 10 / 10 Home / 10 Pro / 10 Pro N* / 10 Basic Server Education Edition N RT for phones)
- (Probably) bundle their software with the exact version of the libraries they're using (looking at you, "Installing Microsoft VC Redist" and DirectX, every single game that I run), because any in /system32 might be the "wrong" ones
* 10 Pro N = "without media essentials" or something, which I stupidly chose last time I forked out the money for a Windows license. Every time there's a new major Windows update (assuming it doesn't repeatedly fail to update, forcing me to reinstall from scratch,) I need to go and reinstall the Media Feature Pack so Rockstar Launcher and GTAV and $software don't all fail to launch with an obscure error code that means one of 100 things that some corporate web forum rep will not have the answer to... Because none of them put a .log file somewhere ...
So the fact that stuff "just runs" better on Win is more to do with third party developer effort rather than a failing of the OS and distribution. There's no incentive for microsoft to make it work better either, because it's Not Their Problem. A whole slew of software runs like bullshit on Windows too, but we just kind of accept it as it is...
Yet me running a program by installing Wine and double clicking the .exe, or via mono, or running one via a snap image, or an .AppImage, or a docker image (those 3 are essentially containerized environments which should work regardless of distro as they bundle their own libraries a la the windows dll hell, though your kernel version may cause issues, just like windows driver versions do), or my Linux distro's packages... is apparently jumping through more hoops than Windows?
As a power user of both OS'es, they're just as much a pain in the ass as each other.
One key difference is the OS <-> application interface is defined as a group of system provided dynamic libraries on Windows, not syscalls. So Windows effectively provides a set of very reliable core libraries that is guaranteed to be backward compatible. And as long as you don't use newly added APIs, also forward compatible. While on Linux even libc is decoupled from the kernel, each distribution uses a different version, the application cannot distribute its own libc in any sane way, and the glibc choose to use ELF symbol version to make incompatible changes to frequently used APIs (like memcpy), sabotage bidirectional compatible attempts.
Oh, and there are only one Windows distribution. Not at least 3 major ones.
These both make packaging for Linux hard (requiring kinda funny solutions wrapping up a sysroot as a whole, like Snap or AppImage), while on Windows, the developer builds an exe, and voila, it works everywhere, even on very old systems. There are simply no funky stuffs e.g. glibc symbol version issue.
* Corp Policy
* Gaming
* Professional Tools (Photoshop etc.)
* Ease of Use
I tried concepts like dual booting windows & linux, but in the end they often created a mental barrier ("Ugh, I could do some work but I would've to reboot"). With WSL2 and PowerToys I'm 90% happy. The missing 10% is a better window navigation via keyboard concept.
While I generally agree that you should use the best tool for the job, for small and simple scripts I see nothing wrong with picking a language your comfortable with.
I wonder, why do you think python is a better alternative? I would understand bash since it is dependency free, but I don't see any advantage for python vs. nodejs
How? Both Python and Node have some https client in their standard libraries, and both have headless Chrome drivers (what this script uses) in easily installed third-party libraries.
However, you're breaking the back button with your redirect to a unique room. Once in a room, pressing back will join a new room. History replace instead of push should be a better choice.