HN user

xab9

427 karma
Posts0
Comments227
View on HN
No posts found.
Introducing Hooks 8 years ago

The article says bind as a negative point - I perefer the new non-bound class method syntax:

``` private handleClick = (event) => {} ```

By "mental lazyness" I mean that people (as in people I have met with) piss on javascript and praise typescript and in the process they never bother to learn about javascript.

I do like vue, react, angular of course, but I don't think that you become a frontend developer from one day to the next and keep saying that typescript is _exactly_ like java (or dotnet).

Introducing Hooks 8 years ago

I "don't actually understand why people like Typescript", or lemonade, or skiing, or eating fish. I know why I like it, including static typing, and how I can find a balance with using its features (and not using some).

On the other hand I'm not trying to hide that I'm bitter about the mental lazyness around typescript - I had some bad experience with interviewers who praised ts (without ever bothering to learn the core principles of javascript) a bit too much for my taste (but again, this may just be dismissed as anecdotal evidence, which it is).

Introducing Hooks 8 years ago

I'm focusing on classes, because it seems to me that to "React" classes are a necessary evil (or they are treating them like they were).

Hooks, suspense, context wormholes - I'm not sure if these features should be part of a view engine. React, to me, did one thing and did it well, but now... I don't know.

Introducing Hooks 8 years ago

I know, but lately during frontend interviews I was surprised how many times I met with "I'm a developer I can do anything" type interviewers - some of them were dotnet, others were java devs and they preferred typescript, because 1. javascript is a terrible language 2. with typescript they feel right at home 3. they can use a "proper ide" (please, don't ask, I already had an argument and a rejection when I tried to ask about webstorm)

Introducing Hooks 8 years ago

Maybe newish coders should learn the language they are using.

And of course there is typescript (and a gazillion of languages that can be transpiled to js these days), which synergizes very well with enterprise people and java/dotnet devs who never did a line of frontend before.

Introducing Hooks 8 years ago

According to the article yes, the issue is "what is a class":

"You have to understand how this works in JavaScript, which is very different from how it works in most languages. You have to remember to bind the event handlers." etc.

I worked last time on a large scale project with full waterfall and heck, it was good. I knew what to do, when to do it, team lead had great domain knowledge and was a nice guy etc.

Then the company decided that products are not built fast enough, so we should be "agile". Guess we all know the rest of the story.

Well, typescript is nice. But. The amount of boilerplate I write with redux is downright annoying, add typescript to the mix and the interfaces, typedefinitions, enums, various scattered exports, actioncreators and typehelpers are just mind-boggling - I don't like it.

Heck, I already have huge livetemplates in my ide to generate most of these stuff, but it feels wrong. And while we have fun writing "enterprise quality code", routing falls apart, load indicators are missing, form validators are a mess, error handling is broken, etc.

I still think that facebook can be tremendously useful, even if I unfollowed everyone and have zero posts (mostly to see events, access facebook-homepages, let people find my email address or just occasionally tell someone to send me an email instead of writing on messenger) - but heck, this latest breach is a bit too much to swallow.

Can you recommend a tsx-friendly linter and its setting? The sites I worked with never followed this rule and whenever I tried to bring it up, it was too late to refactor things (at least from a roadmap/burndown po/sm perspective)

Afaik the render part is purely dynamic and the advocated style of creating closures with fat arrows to avoid scope binding (which is essentially the same if done in the render section) is quite expensive in terms of performance.

React and fiber tries to be smart about rendering with tree section diffing, but unless you use immutable, it's "not enough" to rely on - without immutable even in a smaller redux app there is a good chance that you have unintentional rerenderings triggered, which while may not create new tree branch renderings, still need to be evaluated.

This of course applies to the client, I don't have experience with nextjs or similar tools.

Just unfollow 'em all.

You have to spend half an hour clicking through your list of "friends" (or fans or whatever these relationships are called these days) or write fifteen lines of javascript to click on the dom elements, but then that's it. Clean wall. Silence.

Every man is an island in the world of microservices.

Look, my microservice is clean and nice and has a 100% test coverage, I couldn't care less if you can't communicate with it from yours. Solve it somehow.

Now get off my lawn and let me rewrite the whole thing in scala.

We call it Hype Driven Development which is just as bad as Marketing Driven Development... and yes, monorepos, don't even mention it, good heavens.

Another hype that keeps coming back is the magic of trunk based development (with a random po reading some flashy article about feature switches as the wonderous solution for a-b testing AND faster development).

Nowdays I even consider putting react and angular into this pack, since, you know, "if it's good enough for facebook/google then it must be really good" - anyone ever tried to increase performance for a react site (and realizing that precompiling templates was not exactly a bad idea years ago) or hitting the wall with inline async helpers and rx magic might know my voes. But then again, give me a fast and reliable server rendered site over an unsteable trainwreck spa anytime and I will be happy.

After using bugzilla, mantis, tfs, jira, gitlab and github, I honestly think that jira is not half bad. In fact I prefer it over gitlab, but I'm alone with this view on the team.

The hatred towards jira is on par with desktop java.

Whenever Microsoft tried to do web frontend it was "not really good" (it was borderline catastrophic). Asp spaghetti, aspx components, viewstate handling, razor templates etc.

When I worked with .net guys (which happened quite often) 9 out of 10 had been like wow, I don't have to touch frontend, because MS will solve that for me "somehow", plus the frontend is messy and crap and javascript is a terrible language and C# rocks (but F# even rocks more) and I'm not going to learn all this sillyness (because I want to reuse my skills).

At least with new-angular they feel a bit better and they can praise typescript, because typescript is "just like C#". Let's just hope noone pulls an angular-one-to-two style rewrite/clusterfuck...

That's interesting. Been at their Hungarian office for a job interview (Hortonworks, a year or so ago), it was weird though. Haven't tried Cloudera, but they too have an office at Budapest, I wonder how it will effect their workforce in the region.

All software is terrible and not all bugs will be (or can be) ironed out.

It really amazes me how people are always forming ideological groups - C vitamin is the best cure for everything. C vitamin is useless, just forget it. iOS has memory leaks. No, you are holding it wrong, iOS 12 is good.

And here at least we are a techy bunch, but outside the tech circle, how people treat software is just astonishing. Like the guy who made photographs sitting on the passenger seat, because his Tesla is a full autonomous car and it is perfectly capable of driving by itself.

What really helped me is psychodrama (not sure if that's how it is called elsewhere) and non violent communication (courses available internationally I'm sure). I still tend to be cynical and offensive at times, but it happens less often.