Comments URL: https://news.ycombinator.com/item?id=47493648

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=41717873

Points: 45

# Comments: 19

Comments URL: https://news.ycombinator.com/item?id=41375039

Points: 1

# Comments: 5

this.setState({this.state: val})

which was already pushing limit of normal behavior which is

state.A = val

just to be revise

i went from having to do

state.onlineStatus = 'active'

to

const [onlineStatus, setOnlineStatus] = useState('active')

Instead of being able to get autocomplete and normal refactoring you would get from plain js.. now you need to add typescript to supplement the mess...

const obj = {

onlineStatus: 'inactive', shoppingCart: '3899x', lastActive: 1834393939 }

obj. [autocomplete anywhere in the project]

vs MORE Boilerplate

I started frontend as a hobby in 2010, I've been working as one for 8 years. Jquery was great but everytime you had to invent your own MVP. Came angular and it was extremely verbose. Then came react, it didn't have proper state thing nailed down like angular but it was simple, elegant, easy to reason and made code standardized and easy to read.

I could join a new team and be productive in 3 days as a FE dev. Unheard of prior to React.

However, gradually all that has been taken away.

In my view peak React was when it used class..

in constructor you defined state

in componentDidMount and simple life cycles methods you did things you needed to do.

Now functions are actually fake, it's almost impossible to figure out when the app will render or update when the states changes. Hooks, HOC, Redux, etc... Now you hope it will does what it need to be done..

Before it was rock solid.. state management is even more messy and code is so far from procedural paradigm.. that you just hope. You can figure it out, but that's the thing you shouldn't have to figure out simple things. You didn't need to before.

I recently made a chat app all in plain js, all in one file, and it works wonderfully. I surprised myself how easy to understand it is despite there being some lack of isolation... i've expanded the code at least 8 times so far and speed of delivery is remarkable.

Turns out it's easy if there is no magic going and all code is simple, procedural, contained, and aptly named functions.

Best of all IDE actually helps a ton in refactoring.

Comments URL: https://news.ycombinator.com/item?id=40193914

Points: 30

# Comments: 32

Comments URL: https://news.ycombinator.com/item?id=39665217

Points: 1

# Comments: 1

Basically I find it annoying having to get a physical receipt and keep it around for 10 or so days in case I'd need it.

But If I could go somewhere and set my default preference (Print|Digital). Then it'd be in my mobile phone.

It'd use CC'd to keep track of receipts.

State of this idea: ------------------

> need of product (pretty sure yes)

> improve customer experience and speed of checkout (yes)

> technology complexity (easy)

> integration (Impossible)

How can I get all top companies to sign up for it...

Basically it'd go like this:

Walmart: does 1234 exist?

New_APP: yes

Walmart: 1234 bought 1xA@3.33, 1x33@1.59, ....

New APP: confirmed, great.

===========================

I dont want an app that gives me full overview of my spending habits, or sells my data, or shows me offers for credit cards, give me points, offer memberships or prompts me every time i buy something.

Basically i don't want to use the app, i just want my receipts to be there when I need the said reciept.

Comments URL: https://news.ycombinator.com/item?id=34384951

Points: 2

# Comments: 1

Ultimately, I think even the choice of naming something and using a single letter communicates your intentions. If you make something a single letter then you're telling the reader that do not even worry about this variable it is just passing through, but if you need something your communicating your intentions of using this variable in the future it is more permanent in a sense

// get users older than 90

a = data.results;

b = a.filter(u => u.dob > 123456)

seniorUsers = b.map(x => {name: x.name, age: x.age})

// self contained

// comes out with one final var that is named to be used later on

// other vars are obviously meant to be ignored and just placeholders

// comment explains what is happening so each var doesn't need sacrifice comprehension speed

- There are few variables in the whole code block < 5.

- Amount of lines is < 25.

- Code is very functional in nature. ie. no a.getObj()

Sometimes I appreciate good variable names and sometimes I hate descriptive variable names. Short var names might be better where extra effort required to parse long names is not worth in terms of utility gained.

One example: variables are not meant to be used for long term just exist for next two lines....

i.e. filteredData = arr.filter(...) , noDateFilteredData = filteredData.filter(...), noNameDateFiltered = noDateFilteredData.filter(..)....

this would be easier to read when it's written like this

a = arr.filter(...), b = a.filter(...), filteredData = b.filter(...)

another situation...

data = arr.filter(n => n.flag === true);

// it's completely obvious what's happening here, n is iterable. calling it obj|arr|users|etc... doesn't add much value for this piece of code as is. you probably already know we are getting users. It's like not using pronouns "he"/"she" and just keep using first name: Mike wanted to come in because Mike had said that Mike needed to talk to Aniqa, Aniqa knows about the insurance stuff. Aniqa has worked in insurance....

There is inverse correlation between length of a variable name and the speed of understanding logic of the code. But smaller the name the more you need to remember what it is, and the longer it's carried over the more difficult it's to continue remembering it. So in situations where it doesn't need to be carried for a long time I prefer smaller names.

I'm sure of it from my experiences. I prefer short names generally when is less data massaging and more algorithmic in nature, because sometimes it's hard to name a var in a way that captures vague concept in algo, without making it downright misleading. i.e. i call something a sliding_window but then later don't use it as one. Reader would be like um... wait what??

TLDR: I guess correct name matters more and more, the farther you are from its declaration.

Comments URL: https://news.ycombinator.com/item?id=34143802

Points: 17

# Comments: 50

you give investors equity

you use that money to pay for services, like a logo

you exchanged equity for logo, what's unclear there?

- distrust, how would I know I'm awarded fairly? who decides that? lets say I worked on something I was good at, i.e. I made a logo or I designed database schema. how much should I get?

- accountability, this company gave 50 people its shares, where are they now? are they just vesting? why should I bother with that baggage? is there mechanism to dilute inactive participants? how much? who decides that?

- fair accounting

it's a legal challenge but also more of a logistic challenge.

Imagine if there was crowd/democratic way to build companies:

- people can join and leave

- people shouldn't be able to game or take over the equity grants

- people should be awarded appropriately

- system should be able independently track cost and revenue

I wish it could be done in a non-centralized way but I think there is no avoiding it, unless some legal framework is created by the govt, an entity/org that will work for very broke startups too.

I dont know the right answer but here is what I propose:

Create a non-profit org who maintains and runs the system. Least involvement the better.

- anyone can start a project/company at this org.

- first person(s) create list of roles, they interview all of them and vet.

- once they have vetted and gotten 12 people interested, the org issues in-game currency of 1 million

- this 1 million gets divided to all 12 people equally

- lets say someone is working FT on project and requests higher %, they can propose dilution of others and 70% equity holders must agree.

- there is a task nobody knows how to do they create a public request, and people get paid in game currency and gain equity.

- if one day company starts generating money, the non-profit takes the revenue, distribute it according to equity.

- if company incurs loses then non-profit waits for the company to cover it

- company decides to sell shares/currency, remember it's 1:1, so they say we are selling $10k worth of equity/currency. And that gets deposited to company's bank.

ISSUES:

- how to address problem of formerly active members/shareholders...

  -- Maybe if someone was involved before company had revenue they get privileges that people who contributed after revenue don't.

  -- You can't track this with GIT commits or something, what about someone sharing the site to their 5M twitter followers, that's immense value.

  -- What about senior founders abusing system as a gang?

I think open source and MLM are inspiration for this model. MLM gets an army of people to work for common goal, although it's a scam.

Comments URL: https://news.ycombinator.com/item?id=33946752

Points: 2

# Comments: 3

I predict forums/QA/chats are going to become more dominant moving forward.

Comments URL: https://news.ycombinator.com/item?id=33848224

Points: 2

# Comments: 6