1. 2

    This is awesome! A friend of mine has been talking about recreating popular video game loading screens and transitions with CSS. I think it’s a great idea for a showcase.

    1. 1

      That’s a really nice idea! I would love to see that.

    1. 4

      I’ve been working on 30 Hour Jobs for the last 6 months or so. I’m in the process of rebuilding the whole site as a more cohesive experience instead of various services on subdomains cobbled together. I’m hoping to release v2 in the next couple weeks.

      1. 3

        Non day-job work:

        I recently launched a new website and blog for myself and need to fix a couple issues and add some stuff:

        • the generated sitemap is missing some things
        • add a projects page for info and posts about the things I’m working on
        • keep writing

        One of those projects is 30 Hour Jobs. I want to hire a writer to help me with content on the blog.

        1. 1

          Excited to see WebAuthN being added to safari and enabled by default.

          Some more details about the protocol here: https://webauthn.guide

          1. 19

            I was disappointed to find out that the positions apparently aren’t really 30 hour ones, at least based on reading the job descriptions. This seems in line with the author’s post on HN, stating:

            I should also clarify that 30 Hour Jobs is the title here but I would like to capture companies of all sorts that support a flexible work week or simply embrace work/life balance and/or reduced hours in some way.

            I believe a disclaimer like this should be stated upfront on the website, not buried on a random forum (i.e. HN). Probably even going as far as tweaking the title/tagline to add “or flex”. Otherwise, I personally find this site and ad misleading and, I’m afraid, not fully honest. At least I felt cheated. Unless the postings are verified to offer 30h or shorter weeks, then such an info should be explicitly displayed in each of the offers, because as it is, it feels at least dubious to me.

            1. 4

              That’s definitely the most common bit of feedback I’ve seen today. I’ll work on make that more clear.

              1. 3

                Maybe take another DN like flexiblejob.com and link to a filter with the ones that are flexible?

                1. 2

                  I think it’s much less useful if your site has no hard requirements or at least filters with hard requirements. If it includes jobs that “simply embrace work/life balance and/or reduced hours in some way,” then it’s just a dumping ground for employers who want to attract workers who value work/life balance.

              1. 3

                Never signed up for something so fast ever. Hope this isn’t a honeypot for figuring out who in tech is lazy has a life.

                Don’t let me down, @nbrempel :)

                1. 2

                  Thanks!

                  This is a new idea but it seems to be very popular.

                  I’ll be curating 30 Hour Jobs on a regular basis to send to the list ☺️

                1. 2

                  Subscribed. The only way to find out if this is a real service or just collecting email addresses.

                  1. 2

                    Thanks for signing up!

                    1. 2

                      Aha !!! :)

                    2. 2

                      add a +something when you sign up and see if you start getting spam to that address later :-P

                      1. 1

                        Assuming they are using a mail server which supports that.

                      1. 18

                        Slightly off topic: I see people complaining a lot about Electron, with Slack being a prime example.

                        I think the success of Visual Studio Code means that it is possible to build excellent apps using Electron. And that the performance of Slack app is not necessarily representative of all Electron based apps.

                        1. 26

                          I think it’s possible. But VSC is literally the only Electron app that doesn’t blatantly suck performance-wise. Is that because Microsoft just actually put in the effort to make something good? Or is it because Microsoft has built best-in-class IDEs that scale radically better than any alternative for a long long long time?

                          Now no one get me wrong, I’m a UNIX guy through and through, but anyone who claims there’s anything better than Visual Studio for large scale C++ development has no clue what they’re talking about. C++ as a language is complete bullshit, the most hostile language you can write an IDE for. Building an IDE for any other language is child’s play in comparison, and Microsoft is proving it with VSC.

                          I don’t think it’s currently possible for anyone besides Microsoft to make an excellent Electron app. They took a bunch of internal skill for building huge GUI applications that scale, and built their own language to translate that skill to a cross platform environment. I think they could have chosen whatever platform they felt like, and only chose to target Javascript because the web / cloud is good for business. We’ll start seeing good Electron apps when Typescript and the Microsoft way become the de facto standard for building Electron apps.

                          But I also haven’t slept in 24 hours so maybe I’m crazy. I reckon I’ll go to bed now.

                          1. 7

                            but anyone who claims there’s anything better than Visual Studio for large scale C++ development has no clue what they’re talking about.

                            JetBrains CLion might actually be a bit better – but they started building addons to improve development in VisualStudio (e.g. the amazing ReSharper) originally, and only expanded to build their own IDE later on.

                            I fully agree on all other points.

                            1. 5

                              CLion definitely has a great feature set, but I’ve found a lot of it to be unusably slow, at least on our large codebase. Lots of us use Qt Creator even though it’s objectively worse and has some sketchy bugs, because it’s at least fast for the stuff it does do. I look forward to the day I can comfortably switch to CLion.

                              1. 3

                                CLion is fantastic, I came to it after a lot of use of PyCharm.

                            2. 3

                              Is there a chance that the ill reputation of Electron apps is that Electron itself offers ample opportunity for prime footgunmanship?

                              I’d argue that yes, it’s quite possible to build a nice simple (moderately) lightweight thing in Electron; it’s just pretty hard in comparison to building, say, a nice simple (definitely) lightweight CLI. Or even a desktop app using a regular graphical toolkit?

                              1. 10

                                Visual Studio Code, Slack, Discord, WhatsApp, Spotify all are unfortunately not simple. And while they could be reduced to simpler apps, I kinda feel like we’re all using them exactly because they have all these advanced features. These features are not useless, and a simpler app would disappoint.

                                It also seems like GUI and CLI toolkits are lagging behind the Web by maybe a decade, no joke. I’d love to see a native framework that implements the React+Redux flow. Doesn’t even have to be portable or JavaScript.

                                1. 4

                                  I’m a huge fan of CLI software that eats text and outputs text. It’s easier to integrate into my flow, and the plethora of tools that are already available to manipulate the inputs and outputs.

                                  An example: I’ve written a CLI client to JIRA that I have plugged into the Acme editor. I just tweaked my output templates a bit to include commands that I’d want to run related to a given ticket as part of my regular output, and added a very simple plumber rule that fetches a ticket’s information if I right-click anything that looks like a JIRA ticket (TASK-1234, for example). It’s served me well as a means to not have to deal with the JIRA UI, which I find bloated and unintuitive, and it allows me to remain in the context of my work to deal with the annoyance of updating a ticket (or fetching info regarding a ticket (or listing tickets, or pretty much anything really)). It’s far from perfect, but it covers most, if not all, of my day-to-day interaction with JIRA, and it’s all just an integration of different programs that know how to deal with text.

                                  [edit: It’s far from perfect, but I find it better than the alternative]

                                  1. 1

                                    Is either part of that open-source by chance? I’ve been trying acme as my editor and use JIRA at work. I have a hunch you’re largely describing four lines of plumb rules and a short shell script, but I’m still having trouble wrapping my head around the right way to do these things.

                                    1. 3

                                      Full disclosure, the JIRA thing has bugs that have not stopped me from using it in any meaningful way. https://github.com/otremblay/jkl

                                      The acme plumbing rule is as follows:

                                      type	is	text
                                      data	matches	'([A-Za-z]+)-([0-9]+)'    
                                      plumb	start	rc -c 'jkl '$1'-'$2' >[2=1] | nobs | plumb -i -d edit -a ''action=showdata filename=/jkl/'$1'-'$2''''
                                      

                                      It checks for a file called “.jklrc” in $HOME. Its shape is as follows:

                                      JIRA_ROOT=https://your.jira.server/   
                                      JIRA_USER=yourusername
                                      JIRA_PASSWORD=yourpassword
                                      JIRA_PROJECT=PROJECTKEY
                                      #JKLNOCOLOR=true
                                      RED_ISSUE_STATUSES=Open
                                      BLUE_ISSUE_STATUSES=Ready for QA,In QA,Ready for Deploy
                                      YELLOW_ISSUE_STATUSES=default
                                      GREEN_ISSUE_STATUSES=Done,Closed
                                      # The following is the template for a given issue. You don't need this, but mine contains commands that jkl can run using middleclick.
                                      JKL_ISSUE_TMPL="{{$key := .Key}}{{$key}}	{{if .Fields.IssueType}}[{{.Fields.IssueType.Name}}]{{end}}	{{.Fields.Summary}}\n\nURL: {{.URL}}\n\n{{if .Fields.Status}}Status:	 {{.Fields.Status.Name}}\n{{end}}Transitions: {{range .Transitions}}\n	{{.Name}}	| jkl {{$key}} '{{.Name}}'{{end}}\n\n{{if .Fields.Assignee}}Assignee:	{{.Fields.Assignee.Name}}\n{{end}}jkl assign {{$key}} otremblay\n\nTime Remaining/Original Estimate:	{{.Fields.PrettyRemaining}} / {{.Fields.PrettyOriginalEstimate}}\n\n{{.PrintExtraFields}}\n\nDescription:   {{.Fields.Description}} \n\nIssue Links: \n{{range .Fields.IssueLinks}}	{{.}}\n{{end}}\n\nComments: jkl comment {{$key}}\n\n{{if .Fields.Comment }}{{$k := $key}}{{range .Fields.Comment.Comments}}{{.Author.DisplayName}} [~{{.Author.Name}}] (jkl edit {{$k}}~{{.Id}}):\n-----------------\n{{.Body}}\n-----------------\n\n{{end}}{{end}}"
                                      
                                      1. 1

                                        Thank you so much! I’ll take a look shortly. It really helps to see real-world examples like this.

                                        1. 2

                                          If “jkl” blows up in your face, I totally accept PRs. If you decide to go down that path, I’m sorry about the state of the code. :P

                                  2. 1

                                    It also seems like GUI and CLI toolkits are lagging behind the Web by maybe a decade, no joke. I’d love to see a native framework that implements the React+Redux flow. Doesn’t even have to be portable or JavaScript.

                                    I couldn’t disagree more. Sure, maybe in “developer ergonomics” Web is ahead, but GUI trounces Web in terms of performance and consistency.

                                    1. 1

                                      I’d love to see a native framework that implements the React+Redux flow.

                                      Maybe Flutter?

                                      1. 1

                                        Flutter is such a native framework, although only for mobile (i.e. Android & iOS).

                                      2. 2

                                        I belive one of the things that gave Electron apps a bad reputation (aside from the obvious technological issuses) were things like “new” web browsers, built with electron, offering nothing practically new, that most people would actually want, such as lower memory consumption, for example.

                                        1. 2

                                          Building UIs is hard in general - it seems like electron trades off ease of making UIs performant for ease of building them.

                                          That being said, it seems like it’s not prohibitively difficult to build a fast UI in electron: https://keminglabs.com/blog/building-a-fast-electron-app-with-rust/

                                          It seems like most people building electron apps just don’t think about performance until much later in the process of development.

                                        2. 2

                                          I think one of the few main selling points of Electron was accessibility. Anybody with solid knowledge of HTML, CSS and JS could find his way around and build the app that was running on multiple platforms. But it wasn’t performant and it was quite resource hog as it turned out. Now why is this not the case with Visual Studio Code? Because it is being written by really good developers, who are working for Microsoft, who worked on creating Typescript, in which is Visual Studio Code written, on top of Electron. Now you can get the sense of things why Visual Studio Code is different case than rest of the Electron apps, people behind it are the reason. And whole story defeats the point of Electron. If Electron as a platform could produce half as good results as VSC in terms of performance and resource efficiency than maybe it would be more viable option, as it is right now, I can see the pendulum swinging back to some other native way of implementing applications.

                                          1. 2

                                            I mean, I hate the web stack like few others, but I think the point that ultimately the people are more determinative than the technology stands.

                                            I just really hate the web.

                                          2. 1

                                            I completely agree. I think that a lot of the frustrations with the quality of Electron apps is misplaced.

                                          1. 3

                                            This an interesting move. I wonder what will happen to apps that currently has the system integration that allows the developer to gain access to a Twitter/Facebook profile through a system prompt?

                                            1. 3

                                              They will move to the API that has existed since iOS 8 which allows credentials(?) sharing

                                              1. 1

                                                I can imagine existing credentials to stick around for a while, retrievable through a deprecated API.

                                                This is mostly is the deep integration into the OS, with every app, etc.

                                                As the linked article states, iOS has a model of “sharing extensions” now, so the special treatment of twitter in the photo app is not necessary anymore, the relevant apps can just register themselves for that service.

                                              1. 1

                                                It’d be nicer if this was a little more specific in its advice and a little less, well, fluff.

                                                1. 1

                                                  Thanks, noted.

                                                1. 1

                                                  I don’t really understand the schematics. Does a specialist have three middle-management bosses?

                                                  A junior specialist might have a senior specialist mentor/leader, and a line manager- but then, so will a generalist, so I don’t really understand what’s going on here. What about a junior leader? Will they not have a mentor and a line manager? Sometimes the mentor is the line manager, but sometimes they aren’t.

                                                  An entrepreneurial specialist may outsource a lot of contractors, while an entrepreneurial generalist might focus on the incremental moving slow and automating everything – while still an entrepreneurial leader might move to the bay area and try to get people to work for free/peanuts.

                                                  By following this model, we know that the more connections we create, the more valuable we are in our careers

                                                  I agree with this statement, but I don’t understand how the schematics demonstrate this.

                                                  1. 1

                                                    The examples I provided there are meant to be loose examples. I wasn’t thinking of creating a concrete schematic here; it was more a thought experiment.

                                                    I think there is value in 2nd, 3rd degree connections as well which makes the model more flexible.

                                                  1. 2

                                                    I realized that it’s possible to reduce the elements of any workplace down to two things: tasks and people.

                                                    @nbrempel What’s your sample set of ‘workplaces’ here and what’s the point of view of your experience? E.g. is this tech startup focussed? Do you mostly work in software engineering?

                                                    If you could refine your model and add some properties to these things or a couple of extra classes, or annotate/classify the relationship links, what would you add?

                                                    1. 1

                                                      The data here is purely anecdotal, I haven’t done any sort of study although it would be interesting to correlate something like salary to number of (1st, 2nd, 3rd degree) connections in an org chart.

                                                      I think if I spent more time thinking about this, I might try thinking about the model as a directed graph which takes into account who reporting hierarchy.

                                                    1. 15

                                                      Hey all, happy to join your community. ☺️

                                                      My comparison between Flash/Electron was meant to capture both technologies in a positive light by taking a more holistic view. We can all agree that both platforms have many issues. My opinion is that, while Electron has it’s problems, it’s still pushing the industry forward as a whole. Will the existence of Electron spur the creation of newer cross-platform frameworks that are less resource intensive while remaining extremely easy to use and get started with?

                                                      I don’t think Electron is perfect, but I do think it’s still a good (and necessary) step in the evolution of cross-platform software development.

                                                      I argue that these imperfect stages are actually needed for the evolution in this area as a whole. And for that reason, I believe Electron is a great thing (just as flash was).

                                                      What do you all think?

                                                      1. 22

                                                        Will the existence of Electron spur the creation of newer cross-platform frameworks

                                                        One of the problems is that these cross-platform frameworks do not benefit me as a user of a fairly mainstream platform on the desktop (macOS). Most software vendors care about macOS, so they will provide a version for macOS. However, where they used to write a Carbon and later Cocoa application, they now write an electron application to tick off that platform. For me, as a macOS user, it is a terrible regression. Even if we do not take the problems of Electron into account (memory use and CPU use), these applications do not integrate in the native look & feel. They look out of place, but even worse, there is virtually no platform integration (keyboard shortcuts, macOS services, integration with other Mac applications, AppleScript support, etc.). I stopped installing applications that use Electron, just because their experience frustrates me (besides eating a lot of memory and killing my battery).

                                                        The argument of the Electron crowd is that eventually cross-platform frameworks will integrate better. Unfortunately, history has shown that it will never get that far. Even with the gold standard of cross-platform frameworks (Qt), you typically notice that you are not using a native application (on macOS and Windows). Usually cross-platform frameworks will end up at the lowest common denominator of the platforms that they support.

                                                        Another question is why Electron is reinventing the wheel? Qt et al. are miles ahead as a cross-platform framework and does not require a fully embedded browser (though you can do so). Are some people so allergic to anything that is not Javascript + DOM that they’d forgo having somewhat reasonable resource use and better (but not perfect) platform integration?

                                                        (Edit: I do understand that there are (perceived) economic incentives using Electron above native apps.)

                                                        1. 16

                                                          Are some people so allergic to anything that is not Javascript + DOM that they’d forgo having somewhat reasonable resource use and better (but not perfect) platform integration?

                                                          Spend a few months in JavaScript communities and the answer is yes. The “JS for everything!!” is fun as a weekend project, but less fun when you find yourself relying on it for work.

                                                          1. 20

                                                            Correct. The crux of the matter is the fact that the statement, “native apps are hard!” seems to go completely unchallenged, especially in JS land.

                                                            The reason it bugs me is that it’s used to justify all manner of things that challenge and broaden one’s horizons, including FP, static typing, testing, etc. I’m sick of hearing “it’s hard!” from seemingly the same crowd that loves to write on Medium about how launching a startup is so hard but they have learned so much on their incredible journey.

                                                            Bring back the intellectualism in programming. If you don’t know something, then accept that in humility and put it on the to-do list of things to learn. I’m not asking for people to buy into any of that aforementioned stuff wholesale, just stop being so proud of not knowing it, okay?

                                                            Edit: it’s amusing that “RTFM” is considered profane, but the culture it reflected felt like one where putting the time in to study mattered, and that such study was expected of you. What we have now is…quite different.

                                                            1. 9

                                                              The crux of the matter is the fact that the statement, “native apps are hard!” seems to go completely unchallenged, especially in JS land.

                                                              Native apps may require you to develop environment-specific code, but the code you develop is far simpler than equivalent JS/DOM-driven UIs. Anybody who says, “Web UI is easy,” is a lunatic, or knows nothing but web development.

                                                              1. 6

                                                                I’d argue the messiness of the web is almost countered by the extensive toolset that has grown up around it, such as React/Vue, hot-reloading, and general ease of getting started.

                                                                It doesn’t fix the fact that it is lipstick on a pig, though; other parts of the ecosystem remain of questionable quality.

                                                                1. 6

                                                                  I’d argue that the forest of toolsets around web development shows that we still haven’t figured out how we want to do web development.

                                                                  1. 1

                                                                    we still haven’t figured out how we want to do web development

                                                                    I guess “producing and adopting reams of solutions in search of problems” is a way to do web development :)

                                                                    It’s just not a very good one.

                                                                  2. 1

                                                                    I’d argue the messiness of the web is almost countered by the extensive toolset that has grown up around it

                                                                    I think it’s more the other way round. Now that IE6/7/8 isn’t really a problem anymore, standard plain old JavaScript isn’t all that messy anymore.

                                                                    What’s messy is the proliferation of solutions in search of problems that get adopted despite being such. The front-end world is so crazy that I don’t even have the energy to try and describe it here.

                                                                    But even the mere fact that ‘left-pad’ exists and has been adopted by eeeeeeevvvvveeerryone speaks volumes.

                                                                  3. 2

                                                                    What’s currently the best cross-platform framework/lib in terms of it working on major platforms and easy for newcomers?

                                                                    1. 4

                                                                      There was a good link/thread on this recently; the best sounding suggestion was to build native three times and reuse the core stuff.

                                                                      1. 1

                                                                        Which to be honest probably forces you into a better architecture anyway. Too many GUI apps mix the business logic with the presentation layer instead of enforcing good layering.

                                                                        1. 1

                                                                          the best sounding suggestion was to build native three times and reuse the core stuff.

                                                                          Java would be a pretty good solution if people weren’t (seemingly) so upset by desktop apps not looking completely native.

                                                                          But do they really care? Wouldn’t anyone rather just use a valuable application even if it doesn’t look native?

                                                                2. 2

                                                                  Even if we do not take the problems of Electron into account (memory use and CPU use), these applications do not integrate in the native look & feel. They look out of place, but even worse, there is virtually no platform integration (keyboard shortcuts, macOS services, integration with other Mac applications, AppleScript support, etc.).

                                                                  I agree it’s even worse for Electron apps (though the ones I use do at least have the common macOS keyboard shortcuts). But I think companies, including Apple, care less and less about a particularly coherent UI these days in general. Even native macOS apps don’t strongly conform to any one coherent UI convention, as mac apps used to in the days of ye olde Human Interface Guidelines. Photoshop, for example, looks nothing like a macOS app, even though it’s native. Even Apple first-party apps, though not diverging as extremely as Photoshop, are no longer all that consistent: Pages, XCode, Safari, and iTunes are kind of all over the map in their UI design.

                                                                  1. 1

                                                                    Another problem is that the cross platform support is limited to just a few platforms compared to most open source software

                                                                  2. 11

                                                                    I don’t know that electron is pushing the industry forward. What’s your evidence there? That there are more desktop applications now than there previously were? Is that an advantage when they’re just a web browser frame around a web app?

                                                                    Does it lower development time for someone who already has a web app and wants to say “look, we have a desktop app too”, absolutely. But I don’t think on the whole that’s been a push forward for software development. If electron were something that could do that with native toolkits and native performance, I’d absolutely say that, but given that it’s essentially a web browser, minus the chrome. I don’t think that counts.