ian1321

When I was a CS undergrad, I used to love to write string libraries.

The amazing part to me is that SPAs are so much harder to do right compared to old-school server-side rendered HTML. One could be forgiven if they think a "simple" SPA is a good starter project, but they'd be very wrong. Async programming (Javascript Promises and/or async/await) is difficult, error-prone, and should be avoided whenever possible. On top of this, understanding how data flows through these SPAs is no small task.

Compare this to server-side rendering where you run some DB queries, generate some HTML based on those results, and send it to the browser to be rendered.

There are some cases where you actually need a rich experience in the browser. In those cases, I would start by seeing if plain old Javascript would work.

In writing this, I definitely feel like a "get off my lawn" guy. But I've just seen too many junior and senior engineers (me included) fall flat on their face trying to use these SPA frameworks.

Yeah. I feel like this is some sort of social experiment.

Java is statically typed. Clojure is not. To me, this is the biggest difference and the reason to choose Java.

As an expat living in Zurich, I can say that it is difficult to explain to American's what they're missing.

You are correct from one point of view. But, the point I was making was that the class definitions for bg color can be contained within a single file in your application. Using `style` is completely different in that anything is possible. This is a big deal, as cutting down on possibilities/simplifying is a very important process in software engineering.

There's a big difference between class="u-bg-red" and style="background: red;". The big difference being that the class make it so that it is first-class application idea.

And I think that may be one of the larger points here. CSS can be simple, and using techniques like this forces it to stay that way. You have to take a step back and understand what we're trying to do as engineers. I would argue that being able to quickly understand code (e.g. the context to understand a line of code is small) should be a top priority of most software project.

I used this technique in my previous startup. I even had shell scripts that generated my LESS files.

One of the driving philosophies was that when one saw a CSS class, they should easily be able to find it's definition in the source. Another driving philosophy was that one should easily be able to determine what the class is doing.

This lead to classes like `u-centered`. The `u` tells me it's in the utils.less file. Classes starting with `l-` were layout classes, `t-` text classes, etc..

I had classes like this:

u-{max,min}-width-{xxs,xs,s,m,l,xl,xxl}

t-white

u-bg-red (red background)

t-h3

l-container-{xxs,xs,s,m,l,xl,xxl}

You get the picture.

(The nice thing about xl and xs is that you can keep adding x's as you need.)

I found it to be very effective. I understand the arguments that it kind of defeats the purpose of CSS, but I think CSS is pretty easy to mess up, and this give you a solid, consistent structure to work with.

Of course, I didn't follow this style 100%. There were some cases where it just made sense to use a more semantic style, but I found those case to be few and far between.

I generally agree with all of this.

As a software engineer, you should be building a platform on which the product can exist.

I rarely, if ever see this done. Probably because it takes a big risk as an engineer to actually do it.

I don't have a problem with future-proofing. I do have a problem with half-solutions (which is mainly what I see in the industry). E.g. if you need to run some code before or after a transaction, make a generic way to make this happen.

The problem is that devs do not create enough leverage in their solutions, so they're never that useful in the future. And, devs tend to over estimate what is actually re-usable. The second point may be the most important. Too often, I see solutions that are half-way reusable, which means they're not re-usable at all.

In the end, building out a solid foundation is key. The problem is, this is pretty hard and takes a lot of experience to know how to do well.

Honest question. What is so annoying about that code? It's handling (in an application-specific manner) the special case of dividing by zero (which the `/` operator doesn't handle). I'm not sure of any other way to handle this.

I know nothing about pony, but if it does have an optional type, this would be a much better choice. You lose information by returning 0. Returning "none" would keep the information that you tried to divide by 0. Of course, this means all division would return an optional instead of a value. This is the cost of safe, robust programming.

<rant> I see a lot of software engineers trying to get rid of the cost of writing robust programs. It's not possible. Stop trying. You are either safe, or you are not. You either handle all cases, or you don't. </rant>

I've lived in Zurich for two years now. It would be very difficult to explain to an American who only lives in America how nice real public transit is. Or a good education system. Or the ability to let your kids walk 500m to a park on their own.

Another thing I've noticed is that most Europeans see American as a "high tax" country, and they wonder what we get for those taxes. I can say that I pay less taxes to Switzerland than I pay to the US. I would bet the impression from America is that the Swiss pay more in taxes, but that does not seem to be the case.