disillusion

If you're talking about thumbnails, I think they made the right choice. Just the top part of the homepage already contains 5MB of image assets. Scrolling down a few times quickly ups that to 15MB and more. I'd rather have reasonably sized and optimized images throughout the site - with high resolutions ones as downloads - and a very speedy browsing experience, then the other way around.

However, I would expect the online tiled image viewer to show the full, high quality image - at least, when zoomed in.

It's a nice exercise, but please be aware that using that font in your website makes it terribly hard to read for users who need to zoom in. As in, enlarged pixelated letters are even harder to read then blurry ones. Bitmap fonts are only good on exactly the original size they're designed at.

In my experience, margin isn't harmful. Using a container to space components relative to each other is harmful.

In fact, using margin correctly can prevent an explosion of exceptions on the relative positioning of your components. It also brings you more in line with how a designer thinks.

Consider this: one of the things a designer takes into consideration is composition and whitespace. In effect, this means that distances between components might change, depending on what their layout is, and what components are situated around it.

When you have a wrapper component, you can set some sensible spacing defaults for its children. But some components visually need more breathing room, while others need less. This depends on the design of the component. It also depends on what components comes before or after, so a simple padding won't suffice. Two visually heavy components need more space in between as compared to two that are visually airy. You'll eventually end up with a long list of + selectors to precisely tune every single combination. This quickly gets out of hand. With or without a wrapper element, those exceptions must be applied somewhere.

However, when using margins, you avoid all that. Since margins collapse, you can be assured that any combination of components has the minimum amount of whitespace between them, determined by who needs the most. Now this isn't perfect, but it gets pretty close; any component that needs a bit more breathing room can force a larger distance. This way, you might still have one or two combination exceptions, but these will be rare.

So, looking at it like this, margins _are_ a property of the component itself: it's the equivalent of a guy stretching his arms out and saying "don't come too close, I need my space!".

$sun1: green; for an instant aurora.

The style of question marks used, while perhaps correct, is extremely uncommon in Dutch. It's also not easy to type, even with a Dutch keyboard layout. I'd bet that the author is German.

I've been a developer in both good and bad Scrums. Usually, the difference boils down to one or more of these points:

- Is the product owner any good? (physically present, has mandate, shields the members from company politics, open to story input from the team; like taking care of some tech debt or swapping stories around to fit developer needs, setting requirements that are not too rigid)

- Are the team members any good? (physically present, self-sufficient, experienced enough or with a buddy, communicate open and clearly with the product owner and other team members / disciplines, flexible enough to produce a balanced result within the requirements)

- Is the scrum master any good? (physically present, proactively alert for difficulties in the process or team, encourages interdisciplinary pragmatic solutions, expectation management product owner, balances the needs of the team vs the needs of the product owner, enforces 5 minute standups in the morning and a good but short retrospective after a demo)

- Is the project any good? (realistic budget and MVP, enough room for creativity in development and design, good reason for existence, stakeholders that show up for demo's and stay for the drinks after)

- Is the location any good? (a reasonably creative environment, preferably where stakeholders cannot make surprise visits, with an open floorplan so interdisciplinary communication is encouraged, with all needed materials and enough room on the walls for a scrum board, a burndown chart and to drown them in things like post-its, designs and technical schematics)

- Is the timing any good? (one to two sprints minimum to get the team oiled, not more then 3 days a week - so the other 2 can be spent at a lower tempo, no team members with large attendance gaps or shuffling people in and out, not more then 12-16 sprints because if the project needs more then clean it up, have some downtime, and start a phase 2)

I probably forgot something, but I believe these are the main issues that can really influence the success (and pleasure within) a scrum. One or two issues can be worked around; any more and the project is a drag or even a bust.

Can confirm, works like a charm!

I wonder if it's possible to catch horizontal touch events only. As it stands, the demo page is nearly impossible to scroll.

No, it does't allow comments. Fortunately, a project README has more then enough room for any remarks. Yes, you're better off putting numbers in strings. No big deal.

But also:

JSON files are easily readable by default, in a lot of languages. Knowledge about (the limitations of) JSON can easily be assumed. Alternatives like YAML, TOML or any of the others all have their own idiosincracies.

And non-programmability is a good thing. It might be more verbose, but you don't have to fire up a javascript environment or bash interpreter or some such just to read a configuration file. And separate code paths are very explicit since that will mean separate objects or even files.

I would like to try to switch to a JetBrains IDE. Especially the refactoring tools look to be much more advanced then Atom or VSCode.

At my workplace, most developers are either full stack or backend (python). As such, we have a grab bag of PyCharm licenses. However, I am purely a frontend developer, so frontend related tools are much more important to me then python support.

Unfortunately, the last time I tried PyCharm the integration with linters, toolchains, different template languages etc. was quite limited. Or perhaps I couldn't find the needed extensions or where or how to configure the right settings. I don't know if this is a JetBrains IDE thing, or simply because PyCharm is so geared towards Python development only.

The projects I work on are integrated in different backend systems. So one might be a C# project with Razor templates. Or it'll be some PHP with another templating language. Or it might just be mustache or handlebars. It might be a SPA in Angular, Vue or React. It might be purely Node.JS project. Some projects have Webpack, some have a Gulp toolchain. Linters might differ between projects. Folder structure also differs, one might have the git repository in the root. Another will have it one or two levels down. Some use a python virtualenv. Others use a docker container. Others use no enviroment management at all.

In my experience, because of the different nature of the projects, the PyCharm editor offered little extra functionality over Atom/VSCode, while missing a lot of simple extensions that Atom/VSCode does have. I was also quite a bit slower to start up.

Is it possible to configure / extend PyCharm to offer the same frontend related functionalities as WebStorm, or is a separate license needed? And is there support, or are there extensions, to support different toolchains, linters, templating languages etc. per project? The backend language support can be limited, as long as the very basics are there, and I'd like advanced frontend support for refactoring, debugging, etc.

Holy crap, this has blown my mind.

I've always thought that "visualizing" something is a metaphor for "think about it" or "list the properties you know".

This explains so much, at least for me.

How I always skip the long visual descriptions in books since they add nothing to the story; there is no visual component to reading a book. Why meditation is nearly impossible unless I manage to think about nothing, which is extremely hard. How I can recognize faces but not describe them, even those close to me, other then a short list of features that stand out.

Or how I can recognize a smell, but I can't tell you what the smell of a hamburger is unless I actually have one in front of me. Why people describe dreams or memories like watching a movie, while it's more a combination of emotions, situation descriptions and something that feels like the echolocation of a bat. What some people mean when they can hear a person speak or have a discussion in their head.

It explains why it's so easy to recall emotions and factual information, but nearly impossible to recall anything else. Why my "now" is so strongly affected - emotions experienced in the current moment tend to influence the vague feelings of the past, as if it's always been that way. Why it's always been so difficult to work towards certain goals, unless they're divided up into sub goals that are so close as to be easily attainable. Anything further in the future is nearly incomprehensible. Why it's so easy for me to navigate through bad experiences, but not for others, because beyond needing to process the emotions, the rest will fade away like all other experiences.

Some of those might be because of something unrelated. But somehow, reading this article, has answered a ton of questions I didn't even know I had.

My mind is truly blown.

Though one aspect I don't have: If I think about a song I know well, I can play it in my mind. The experience is almost, but not completely, like hearing the song in reality. So at least there's that. And that also explains why music is so much more "real" then anything else to me.

Can I share some observations? There are a few things I really love about this:

- You kept the end user in mind: You. The GUI looks like a mashup, in a good way: A Mac OS menu bar, Windows GUI feel and a NextSTEP launcher on top of a Unix like system. It shows that for every element, instead of simply recreating whatever system you decided to emulate, you took the parts you liked best from whatever system and simply recreated that. I haven't looked at the code too thoroughly, but I can probably find the same mindset there.

- You kept the scope tight. It's easy to lose sight of the bare minimum MVP, especially when working on a hobby project. The functionality showcased here tells me that whenever you started implementation of a feature, you built exactly what you needed, nothing less, nothing more.

- You also didn't get bogged down with premature optimizations. Yes, the PNG renderer is slow. But it does the bare minimum it's supposed to.

But most of all, this takes a crazy amount of time, skills and dedication. You've probably encountered quite some frustrating moments you had to chew through, but now you're here, presenting your work. And it's awesome!

I think it's interesting how debates about Electron inevitably end up with the arguments 'the developer wants X' vs 'the user wants Y'. However, there's one aspect a lot of people seem to overlook in their arguments: pragmatism.

The ideal application:

- uses almost no memory

- uses almost no disk space

- is extremely fast

- costs (next to) nothing

- and has all the features in the world

- presented in a manner that automatically shows the user only the exact features (s)he cares about

In the real world, we have to balance the project/product requirements. In the end, only these things matter:

- It yields a net profit (monetary or otherwise) for the company or owner

- It has (and keeps) added value in comparison to similar software

- It's fun to design and develop in/for

- It has bugfixes and new features in a timely manner, without taking up too much development time

- It has a pretty, easy to use interface

- It's quick and snappy enough to run

Adding that all up, and developing in something like Electron is a no-brainer: mean time between iterations is faster, design and development is more fun and the end user has a product that is fast enough for their needs packed with features. Try that in any low level language or without control over the engine and you'll have to severely hamper one of these goals.

Warning; I'm going to have a brutally honest opinion here.

It's better to start over. With a proper UX design, a proper visual design and a good quality frontend developer. Or at least, as close as you can get.

My first few thoughts on the design:

The design language doesn't seem to convey anything. Whoever chose that color palette? What are the core principles it's supposed to show you?

Elements are severely misaligned all over the place. There is no coherency, composition or vertical rhythm to be found. It has a hodgepodge of font sizes and weights without clear typographic hierarchy.

Links are actually missing a hover state. Buttons have a hover state, just don't expect it to be noticeable. Just like the font size on the buttons - those are 12px. We don't have 1280x1024 screens, unless I've somehow traveled back in time to 1999. 16px minimum, please.

There is too little breathing room on mobile. It's not actually responsive, it just collapses on a single breakpoint. That breakpoint is also in the wrong place (960px), making it too big on tablet portrait (750px buttons, really?) and too small on desktop (960px max on HD+ screens, even 2.5K screens - really?).

It looks like it's made with an off the shelf layout framework without any sort of customization. There's a horrible google calendar embed - why not a simple, integrated solution? There are upscaled(!) PNG logos on there (Chucklefish, Yelp) - why not use a vector file, like decent folk?

Those design patterns are barebones, but work reasonable well on the homepage. However, the moment you click through they seem to be (ab)used for anything and everything. Where are the other, less generalized patterns? And why are the patterns not actually designed for mobile as well? Just dumping all the buttons below each other and making them 100% wide does not make for a good user experience. For that matter, why are there not more effective patterns used? Code example could really use an, oh I don't know, inline code example perhaps? Fortunately, almost all links go to external (sub)sites -without warning- so you won't have to look at this for too long. Just a shame everything looks different from each other, even subsites.

Where are the loving touches? It doesn't have to be a christmas tree, but a little transitions and effects go a long way.

As for the code:

A display font is fine, but preloading six (6!) font weights of the body font, just on the homepage? And not even .woff2 or .woff, but huge .ttf files at that! That's about 3MB of fonts. Nice when you're on 3G; you can see the webpage building up.

It seems to use utility classes. The responsibility for style composition should be in your stylesheets, never in the HTML. The classes look like some clever backend developer cooked them up: "v-top pl4 pl0-l pt0 pt3-l measure-wide-l mw4 mw5-ns w-100 mw-none ph3 mw8-m mw9-l center f3". There, everybody intelligent will immediately know what it does! If you rely on good will for maintenance, this will limit the amount of developers willing to dig in.

Also, there are 4 different CSS files, separated for no apparent reason. Three of which aren't even minified.

SVG illustrations should be placed inline.

As someone with an enmity for big javascript libraries used in the wrong places, the fact that there's no JS should be wonderful. Except that I'm guessing that's part of the reason those design patterns are so barebones.

There's lots more, but let's pick the low hanging fruits first.

PS: I prefer this version: https://www.rust-lang.org/en-US/ ;-) It might be stamp-sized visually, but it does some things much better.

Funny, I'm Dutch and I learned the week starts on Monday. Well, except for strongly religious families.

Helvetica has a few very easy tells; look at the 'e' and 'c', the 'F' and 'E' and the 'A' and 'Y' in these examples, and you'll get 20/20. Oh, and the 'G' and 'R' ofcourse.

Doesn't seem to do much on mobile...

It depends on the situation, I think.

As a frontend developer who's in concurrent agile, multidisciplinary projects, the people skills and the ability to connect development with design are an absolute requirement. Being able to float in between the disciplines, catching potential problems and iterating together to make the end result more then the sum of its parts is invaluable. A strictly development scrum with a heavy development lead demands less people skills of its developers.

In my opinion, a good frontend developer writes high quality code and works well with other developers. A great frontend developer also works well with other disciplines and enables them to put more ambition in a project, while minimizing the extra amount of work this generates.