• 8 Posts
  • 223 Comments
Joined 5 years ago
cake
Cake day: May 31st, 2020

help-circle




  • Well, part of the problem is that web apps themselves are kind of alien on the web. The web is generally document-based. Web apps take the document format and try to turn it into something it’s not.
    There’s a way to not do the JavaScript, but it doesn’t fix things being document-based and it can be argued that it makes other things worse in some respects.

    I’m talking about WebAssembly. Basically, you can write your web app in HTML+CSS+Rust and then the Rust part is compiled to WebAssembly, which then takes the role that JavaScript would normally take. It does not have to be Rust, lots of languages can be compiled to WebAssembly, but Rust has the most mature ecosystem for that, as far as I’m aware.

    In principle, it is also possible to use WebAssembly to render directly to a pixel buffer, but that’s really rather heavyweight and not terribly responsive, so not generally done, unless you implement a game¹ or similar.
    Alright, so back to the document mangling approach. There’s various frameworks available for Rust. I’ve used Leptos so far. There’s also Dioxus and Yew and probably others.

    Advantages:

    • Don’t have to write JS.
    • Can write Rust. Rust has some concepts that mesh really well with frontend dev, like the Result and Option types for error handling, which you can pass directly to your rendering stack and it can show either the data or the error (or nothing).
    • Can use the same language in backend and frontend and therefore also get compile-time checks that the two work together.

    Disadvantages:

    • The ecosystem is young. You will find barely a fraction of the component libraries as you can find for JS.
    • Rust also has concepts which don’t mesh well with frontend dev, like the whole memory management concept. Those frameworks bypass that or make use of it in clever ways, but things can be a bit peculiar or overly complex at times.
    • WebAssembly is sent to the browser in one big blob, because it’s a compiled program. This means you get somewhat of a loading time when first loading the web app. There’s ways to mitigate that with “hydration” strategies, but yeah, still a thing.
    • While JS is often minimized/uglified and therefore not readable anyways, WebAssembly makes that even more of a reality, because it is essentially assembly code that’s sent to the browser. It does still call the same APIs under the hood as JS does, so content blocking shouldn’t be affected, but yeah, can’t try to understand the code itself. This can also make debugging during development somewhat more painful.
    • Well, and it’s also yet another web standard that browsers have to support. It doesn’t make browsers simpler in the sense that suckless would like.

    I’ve listed a lot of disadvantages, so just to point out that, yes, to me, the advantages are absolutely worth it. But I can totally understand, if others see that differently.

    ¹) See, for example, Bevy and this UI example in particular.


  • Yeah, I’m honestly a bit confused. I have basically the same paper bin and it’s not heavy at all. I’d expect a cat to be able to knock that over no problem. Like, maybe it doesn’t try to while you’re around, because it might fall over with the bin or hit itself with it, but I wouldn’t expect a real troublemaker to worry about that either…



  • As a software engineer, I’d say statistics is more useful for journalism. If in doubt, you could be analysing papers about entirely different fields, like physics or biology or whatever. Those also deal with statistics.

    But I also just feel like there’s not terribly much journalism to be done surrounding computer science. There’s the bog standard news cycle of tool XYZ had a new release, but beyond that, it’s more a field where techies try out or build things and then they tell each other about it.
    I guess, you could also consider some of the jobs adjacent to computer science / software engineering, like technical writer or requirements engineer or project/product owner. In some sense, the latter two involve interviewing customers and their domain experts to figure out what’s actually needed.
    Having said that, to my knowledge you typically get into these roles by being a software engineer and then just taking on those tasks regularly enough until someone notices…



  • It’s a programming language, which is particularly relevant for Linux, because it doesn’t require a runtime (separate program that runs the code). This allows it to be used in the kernel.

    But it also means that it’s very good for building libraries. With a small bit of extra work, virtually any other programming language can call libraries implemented in Rust (like you can with libraries implemented in C).
    Add to that, that Rust allows for performance similar to C and makes lots of typical C bugs impossible, and suddenly you’ve got folks rewriting all kinds of C libraries and applications in Rust, which is something you might have also heard about.






  • Yeah, Wikipedia tells me the longest word that was actually in use is Grundstücks­verkehrs­genehmigungs­zuständigkeitsübertragungs­verordnung. It was a decree from 2003 until 2007.

    Basically:

    • “Grundstück” is a plot of land.
    • “Verkehr” is traffic “trade” in this context.
    • “Genehmigung” is approval.
    • “Zuständigkeit” is responsibility.
    • “Übertragung” is transfer.
    • “Verordnung” is decree.

    So, it decreed that the responsibility of approving traffic on trade of private plots of land should be transferred (to a different government body).




  • Wildly depends on the complexity of the feature. If it only takes 4 hours to implement, you might have good enough of an idea what needs to be done that you can estimate it with 1-hour-precision. That is, if you’re only doing things that you’ve done in a similar form before.

    If the feature takes two weeks to implement, there’s so many steps involved in accomplishing that, that there’s a high chance for one of the steps to explode in complexity. Then you might be working on it for six weeks.

    But yeah, I also double any estimate that I’m feeling, because reality shows that that ends up being more accurate, since I likely won’t have all complexity in mind, so in some sense my baseline assumed error is already 100%.


  • Well, I think your idea would be simpler, if we weren’t talking about Java.
    Pretty much everything is an object in Java. It’s only logical that a type would also be an object and have associated fields.

    Similarly, what you’re thinking of as “reference types directly” doesn’t make sense in Java, because it lacks many of the systems to make that actually usable like a type. What you get from .class is a Class object, which you can’t stick into a generic type parameter, for example.
    It basically uses reflection to give you e.g. the name of that type and you can also instantiate an object of that type, if no parameters need to be passed to the constructor function.

    And then, yeah, I think for explaining that you merely get an object which roughly describes the type, the separate .class field is a good idea.


  • I figured, I’d ruffle some feathers by saying that. 😅
    But yeah, I stand by my point. Just because your target users are capable of dealing with complexity, doesn’t mean you should be making use of that rather than simplifying usability, since your users have plenty other things they could be learning instead.

    I will caveat that I can see it becoming worth it to learn an intricate logic for a power user, when things fall into place and make sense at a higher level as you learn more about it.
    But in my experience, that’s just not the case with package managers. You need a few specific commands to be obvious and then the special cases can be obscure flags.