vikingcaffiene

This reminds me of the lie detector scene from the wire[0]. I love that show and thought this scene was clever and funny. After reading this it has me wondering if cultural touchstones like this glorify what’s actually something pretty devastating.

[0]https://youtu.be/AJ5aIvjNgao

> “As a rule, any mention of religion on an online forum degenerates into a religious argument. Why? Why does this happen with religion and not with Javascript”

I got some bad news for 2009 PG from the future…

> ““Zero-API” data layer lets you import server code directly into your React components instead of having to manually add API endpoints and do client-side fetching and caching.“

Sigh… I’m sure the author(s) of this framework mean well and sincerely believe this to be a good thing. I can tell you from having experienced php templates that did stuff like this that this is a terrible idea in practice. Worse, you won’t know it is until you’ve built quite a mess.

Consider for example needing to make a change to a view but your existing view has tons of data access logic embedded right in it. Now consider if there was tons of mission critical data access code inside sub components. Right there you’ve got to do a pretty risky rewrite just to change some UI.

I’m sure it’s possible to use this framework and speak to server concerns in such a way as to keep presentation and business logic concerns separate? but it’s way harder to do at scale. Thin clients are the way to go in pretty much every case I’ve ever encountered.

I feel like you are refuting a point I didn’t make. I was just talking about how we re-discover patterns. My feelings on Java have nothing to do with it.

This is a Finite State Machine meaning there are a limited set of states and state transitions allowed. useReducer doesn’t have any of the state/transition validation logic which makes it an infinite state machine. Both are very useful. Different use cases though.

It’s interesting to me how certain design patterns get rediscovered over the years. A few years back FSM’s were a dirty word for crusty Java devs. I myself avoided them for that reason. Then one day I had a perfect use case for one and took the plunge and was amazed by how useful a pattern it is. I’m embarrassed at how long it took me to get hip to it. I’m writing a feature at my job right now that makes heavy use of FSMs. Very testable and the nature of the pattern means you can have a lot of confidence in your state being valid. I highly recommend trying it out even if you don’t adopt this hook or xstate (you can make a FSM fairly easily)

> Each ticket is one commit. If you revert one commit, you are guaranteed to have a working piece of software and you won't have a potentially not even compiling intermediate commit that was subsequently fixed up during a PR, which can happen without squashing.

This is the key point and I liked it so much that I bookmarked it. Hope you don’t mind. :)

I frequently have to debate with my teammates on the value of squash merging into our mainline branches. Another value add that squash merge brings is that it enables what I call “accidental documentation”. You get a easy to parse log of work that was done and a link right to the PR with a description and any discussion around it. As a lead I frequently need to coordinate teammates and communicate technical decisions. It’s invaluable to be able to just pull up the commit log and go right to the work in question without having to wade through a bunch of noise.

It also helps a ton with writing release notes.

Agree. It’s YAGNI until you YNI. ;p

There is no greater sin than to say something positive about Java on the orange site...

IMO Java and C# and other compiled languages have the opposite problem with languages like python and JavaScript (I love all these languages btw). It’s easy to get up and running quickly with the latter. It’s not until your project has grown in complexity when the formers value becomes apparent. This is similar to mongodb vs say, Postgres.

Also modern Java has picked up a lot of the better ideas from Kotlin and Scala. I still prefer Kotlin but I think a lot of criticism I read is referring to older versions of Java.

I’d flag this if it came up in PR. It’s clever and novel which is precisely why it’s a bad idea. Always bet on boring.

This is a thinly veiled commercial for the authors start up. There’s so real advice here save to join his new social network.

That’s aggravating. I do full stack dev and work at startups so that particular scenario hasn’t come up but I could see how that disconnect could create some tech debt. That said, I think it’s a planning process problem. You really should have someone on your project capable of making those changes. People really are the hardest problem.

Yeah I generally think the UI should only manage stuff like that cosmetically. Stuff like form validation etc. The real work should happen on the backend and not care about UI stuff. So it just throws if the user tries to get cute. IMO that is a nice separation of concerns and keeps the client thin and presentational in nature.

People trot this one out every now and again and what they mean is “front end used to be the easy part of the stack”. If you lived in the bad old days of jquery spaghetti and in-line php templates you’d realize what a bad take this is. Yes it used to be that anyone could jump into the front end. And the front end _sucked_ because _anyone could jump into the front end_ and so they did. There was no organization. No architecture. Nothing. Just a bunch of files that got harder and harder to maintain as the app increased in functionality and scope.

Modern FE is a discipline every bit as complex as anything that we face in the backend. It requires that we actually apply an architecture. Design our code so that we can respond to changes in our business requirements etc. Serious engineering rigor in other words. Hell I could make the argument that in some ways backend dev is much more straightforward.

I think it’s fair to say that we often put too much business logic into the front end. Fat clients are not something I agree with. But to say things used to be better is just flat out incorrect.

I don't know why you are getting down voted. For what its worth I appreciate the analysis.

I kind of feel like this post shouldn't exist without the author taking the time to explain his POV better than a few bullet points on a slide. The postscript kind of goes there but its not enough IMO. What we are left with here reduces whatever his point is to a few reductive statements that probably over simplify his arguments and leave the rest of us either nodding emphatically or shaking our heads in disgust because its just generalized enough to confirm any pre-existing bias we already have. In other words this wont change any minds.

I guess the one good thing to come out of reading this is that I'll pick up that "Pattern Language" book and give it a read. Perhaps this post will gain some value in retrospect with that context.

Thanks for the thoughtful reply!

> I'd go so far as to say there is a current of anti-intellectualism in terms of frontend application design

I try to walk a line here between relying on my experience and being open to the idea that there is possibly a better way to do things that is just unfamiliar to me. "Beginner mindset" and all that. React hooks are a great example. At first I hated them because I didn't really understand what problems they solved well. To my eyes they encouraged mixing concerns in the component layer in ways that made testing and re-usability way harder. It was when I started considering hooks as "headless components" that I started understanding where they fit into a front end architecture. I think they solve a specific class of problem that react had no answer for previously. I don't use them for everything but now that I consider them as a special kind of component, they fit into a larger set of tools that I have at my disposal.

I also think there are different kinds of front end developers and we all get lumped into the same bucket right now. There are those that work on flashy UI stuff (which I suck at) and those that do more "middle tier" type stuff where they are building out web apps that solve business problems (more my sweet spot). Those two skill sets are way way way different from one another to the point that I think they should be classified as different disciplines.

I don't know why you are replying with this like some kind of gotcha...

First of all Java and the JVM are two different things. One is a language and one is a runtime.

Yes Kotlin requires the JVM. So does Scala and a lot of other languages. Leveraging the JVM runtime means that Kotlin can inter-op with Java libraries and the ecosystem at large without having to build all those things anew. Its all upside. You get the niceties of the language plus the rich ecosystem. I can for instance leverage Apache POI in Kotlin to generate some excel workbooks despite the fact that that library is old af and doesn't know anything about Kotlin. I have in fact. It works great.

Your argument doesn't have legs to stand on. Languages like Elixir leverage existing runtimes as well. Its not uncommon and its a feature not a bug.

I've written front end for nearly all of my 13 years in this field. I've written some absolute dumpster fires in my time and have also written some very large and complex UI's successfully. I would like to think I have some insight to add here. I agree with a lot of the points brought up in this article. I'd like to add a few more points about why I think FE can be such a pain to get right:

1. Mixed concerns and a lack of application layering. In React code bases and others like them, its not uncommon for me to find business logic embedded directly inside the components themselves. This makes the component inherently coupled to the specific implementation its being used and can only be re-usable in other contexts by passing in modifier flags to the props etc. In my opinion, components should be mostly of the stateless flavor and delegate anything not directly related to their immediate UI concerns elsewhere. This increases the likelihood of re-usability of your components and makes testing business and component logic much much more straight forward.

2. This might just be my personal experience, but I've noticed a bit of a dismissive attitude around design patterns and traditional computer science principles among my front end brethren. YAGNI and all that. While I think its fair that the UI != to the back end, I think frequently the baby gets thrown out with the bath water. For instance, I frequently leverage dependency injection in my front end work as a way to make my code more flexible and testable. It's hard to sell the benefits of something like DI until your application grows in complexity to the point that you are dealing with things like nested mocks in your tests and/or need to make a non trivial change to some piece of functionality. I've been seeing the winds start to shift a bit on this which is encouraging.

3. Most of the time there is little to no overall _conceptual integrity_ to a given front end code base. Its uncommon for me to come into an existing code base and have anyone be able to tell me what the architecture is comprised of. Things like what logic lives where and why. I'm not saying people _don't_ do this, but in the more gnarly code bases I've encountered, this "accidental architecture" is more common.

4. Front end is still see as "easy" and the place you stick the less experienced engineers first. I sincerely hope this doesn't come off like I am gatekeeping or anything. I work with some absolutely brilliant people who are only a year or two into their career and much smarter than me. IMO its less about skill and more about having been burned enough times to know where unexpected complexity lie.

I love front end. Its challenging and interesting and maddening. My hope is that it will continue to mature and grow to the point that it gets the same respect as other disciplines within this field. These days I work full stack so its not all I do, but it will always be my favorite. :)

It runs on the JVM. That's one of its selling points. :)

I've been writing Kotlin professionally for the past 2 years. I'd highly recommend it as a worthy successor to Java. It's very powerful and thoughtfully designed. Java just feels so old and clunky after using it.

I've not had the pleasure but I hear Scala is great too.

We just started using these at my job. I like how the approach takes the conversation out of a slack thread and generates some documentation to boot. The tooling ecosystem is also excellent (adr-tools is awesome) and you can easily integrate stuff like confluence document generation as part of your ci pipeline.

We've taken the approach of submitting adrs as a pull request on the repo they affect (we have a dedicated repo for higher level adrs) and submit the link to a dedicated slack channel so folks can have a look and submit any comments they might have on the proposed decision. Once everything has been hashed out, we either merge the PR and get busy implementing the idea or close out the PR and move on.

Am I missing something or is there no IE11 support? A fairly common use case for a datagrid like this is as the heart of an enterprise app. Dead in the water with no IE11 support sadly. Looks great tho!

This is the correct take. If it's so easy to do then there should be a button or menu option that does it.

If she sends ODT to her publisher or editor, they will laugh at her and throw it in the trash. There are very specific rules about this stuff and no wiggle room for interpretation. It _has_ to be in docx format or it's not getting read.

This is correct. Any writing software that aims for an audience larger than HN needs to have a very robust docx export capability.

My partner tells me that it has to be formatted a certain way down to the font and line spacing too or they won't accept it.

I'm cracking up at all these comments suggesting that her recipients brew install pandoc lol. Good luck with that.

I'll tell her to let her editor know that. Lol.

This has no word export option (unless I missed it) which makes it infeasible for a lot of writers. Like it or not, docx is the format a lot of folks in mainstream publishing expect.

Context: My partner is a published author and I've pitched stuff like this at her on multiple occasions as an alternative to Scrivener. In addition to her laughing at my insistence that markdown is a superior way to write, she cites the need for a rock solid word export option that "just works" as a requirement for any tool she uses.

This is the right call and I applaud Airbnb for putting the integrity of our democracy ahead of short term profits. I simply cannot believe that we are at the point where we have to brace for domestic terrorism in our capitol but here we are. May sanity return to the country soon.

There are some good ones in here but I'm not sure I agree with everything. The disallowing of reduce for instance strikes me as kind of arbitrary. I'm definitely going to knick a big chunk of these for my projects though. I'm all about automating away bike shedding syntax arguments.

Don't eat the blue mint while being trickled down upon...

I mean is anybody surprised? I can't believe anyone ever swallowed this lie. Even when I was a kid and Reagan was trotting this one out for all the adoring boomers (just aged myself there...) I remember thinking "that doesn't sound right...".

This idea of the benevolent wealthy class that shakes loose "wealth dust" for the proletariat is insane. It's way past time that we reverse course on this. We need to put the regulations and tax policies _back_ in place and shore up our tax laws. This isn't some radical idea. We actually had laws in place up until the 70's that kept the scales balanced somewhat in this regard. It's hard to ignore the wealth inequality gap began widening riiiiiight at about the point we started stripping them away...