> “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 don't think it does, so long as one uses a sufficiently broad definition of religion (e.g. crypto, wokeness).
Also my impression is that there was a spike of js hate ~3-5 years ago that has since subsided. I think it grew alongside the development of web applications, where more and more people who had little previous exposure to js were suddenly forced to confront it as some part of their workflow or other.
Can you point to a big dust up thread about js recently? I can't think of one personally. At most there are various complaints about specific js technologies like npm.
EDIT: Since everyone wants a definition of religion, here's the copypaste from my response downthread: Priests, holy writings, dogmatic beliefs, original sin, etc.
I get there similarities, but I worry we are engaging in semantic diffusion.
If we define religion as "anything people get super passionate and opinionated about" then it's pretty much tautological that people will argue about such things, without telling us anything about why such arguments start in the first place.
> I don't think it does, so long as one uses a sufficiently broad definition of religion (e.g. crypto, wokeness).
Crypto and wokeness are not religions in the actual sense of the word religion. It's a shame that people redefine words in order to change their meanings to fit what they are saying.
I suppose it's too soon to tell if they take off, but they seem to fit the bill to me: Priests, holy writings, dogmatic beliefs, original sin, etc.
As a way of bounding this definition, I don't think javascript would count as a religion. Although perhaps I'm not sufficiently tapped into that world to make the necessary parallels.
Definitely not, although any grouping of beliefs with a concept mapping to original sin strikes me as religious. So kind of a "not all rectangles are squares but all squares are rectangles" situation.
No, it's a game of labels, where people like to slap labels on things to assume commutative properties of other things they have attached labels to in order to celebrate or condemn the people who identify with those labels.
How do you define religion? And how does crypto and wokeness fit into that definition. I feel like you're using crypto and wokeness in a perforative sense, but I'm giving you the benefit of the doubt, and assuming you have a working definition that's interesting and useful.
>For example, the question of the relative merits of programming languages often degenerates into a religious war, because so many programmers identify as X programmers or Y programmers.
This happens to every question into which people are so emotionally invested that even discussing any modifications or alternatives seriously is painful for them.
That is, when it's a part of one's identity, like religion, or [list other protected classes here].
Maybe in 2009 people around pg were not emotionally invested in JavaScript so much. Like,they were more professional, or maybe just still preferred Lisp and didn't care about JS much.
In any way, the whole thread here just illustrates the pg's point, which only grew stronger since 2009.
> For me, after spending two hours listening to an interview with a woman who escaped North Korea, it might as well be.
I think I listened to the same interview a few days ago. Most likely the Jordan Peterson interview with Yeonmi Park. Very interesting and well worth the time imo: https://www.youtube.com/watch?v=8yqa-SdJtT4
Totally agree. Politics has ripped the fabric of society. I vividly remember how political discourse was in 2009. It was nowhere near as toxic, fascist, rage-fueled, woke, and dangerous as it is now. What has been lost? Truth. We've stopped caring about seeking truth and instead have resorted to subscribing to mob-mentality. Equally applies to both sides. The mere act of listening to both sides is considered as "silence is crime". WTF people. HN is probably one of the better places to have a political discourse but it has also suffered.
You are discounting the fact that 8 billion people are connected (nth-removed at worse) to the largest communication network ever. There are legitimately only large mobs at this point.
We’re fundamentally struggling with scale and there’s no two ways about it.
> ““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.
> your existing view has tons of data access logic embedded right in it.
This is not at all how Blitz is set up to function. Your data access logic is clearly separated into query resolvers that run on the server.
What the "Zero-API" does is in practice is handle all the HTTP stuff for you. So as a developer all you are thinking about is "function calls". The function call happens to occur over the network, but as the dev you don't have to think about the details of how that happens.
> 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.
You can separate these out. Treat public functions from your data/business logic layer as if they were an API in terms of organization. Your views shouldn't be doing any logic, they should be dumb. Overall, we've found switching to a MVC framework for new applications (React/Express -> Phoenix) has increased productivity a lot, especially with a tiny team.
Then again, I'm pretty green, so if there are cases where that kind of separation isn't possible, please let me know!
> 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.
We use Blazor in production(admittedly for internal facing app) and it works wonders for us. We mainly share models with frontend part, it's an insane productivity boost. You don't have to embed data access or server business logic into your views. You can, but you don't have to(and you shouldn't). Even just sharing models and calling endpoints like you would call a service is just... convenient.
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)
Finite state machines will never not be useful for the same reason regular expressions will always be useful. They're a supremely simple model of computation, making them easy to reason about.
The problem with state machines in Java is not the state machine's fault, it's Java's fault.
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.
> 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.
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.
As someone currently trying to juggle a massive, extremely complex Python project, our code looks very Java-esque just so we can actually understand what's going on. Java/C# absolutely have a place, but the heavy startup mentality here will always lean towards "whatever lets me pump out my crapware and go to market fastest". Startups aren't known for producing well maintainable code (not that you can't make maintainable code with JS/Python, it just gets much harder at higher complexity scales).
Same. I also flag seemingly good things like !!x. If you want to convert something to boolean be explicit and do Boolean(x). In most cases it turns out there was a bug in input parameter in the first place and developer was just lazy to fix it.
Exactly, because it won't be the first innovation nor the last and if you let them all through, your code becomes a bazaar of curiosities rather than a business solution...
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 think it’s fair to say that we often put too much business logic into the front end.
As a back-end dev, this reminds me of the time I used our own product and saw a read-only field on the UI. It was some interesting bit of data that only existed in the database (we didn’t expose it in the API) and I brought it up how cool it was that we were doing that now. The front end dev said, “oh, it’s not from the database, we make several API calls to get the bits we need and then calculate it the same way we do on the backend”
I facepalmed. Like, just ask to expose that data, it’s a single line of code! Instead we made 7 API calls... :sigh:
Man I’d love it if our backend teams were that willing to make changes for us. So often I stumble across bizarre, complicated business logic in our various client code bases and ask the devs “why is this here? surely this is better put on the backend/already exists on the backed” and am greeted with “we agree, but when we asked the backend teams to make a change on their end they told us it would be done in the next year or two”.
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.
> I facepalmed. Like, just ask to expose that data, it’s a single line of code! Instead we made 7 API calls... :sigh:
The reality here is that this person who worked in your company, along with everyone else who saw that code and deployed it, all thought it was easier to do what they did then ask you to expose that data with one line of code.
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.
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.
I love how you say "Here's the same guy..." like it was someone other than yourself.
I was going to point out that the beginning of the article says that this was a "five minute long talk" given at YAPC, and did not represent your complete thoughts on the matter.
I got some bad news for 2009 PG from the future…