Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Get in zoomer, we're saving React

acko.net

Post reply on HN
Print view View original

231–240 of 251 posts

Re: Get in zoomer, we're saving React

#231

Post by pier25 »

klysm wrote: post #204
pier25 wrote: post #171

I've been doing front end since the late 90s and I disagree with many points here. One thing I do agree is the rant at the end about zoomers. We see stuff like tailwind popping up which really reflects the zoomer ethos of not wanting to learn fundamental stuff like CSS. "It's so easy to get started! Why would I learn anything else?" I think gen Xers and late boomers will be the most tech developped generations becaus…

People that learned CSS before tailwind was a thing tend to hate the concept. But clearly it has to have some value right? Why is it so popular? I argue that it solves a clear design deficit in CSS. You cannot have tight coupling with CSS and a lot of the time you want tight coupling. In-line styles are insufficient, so we have tailwind. It’s an API to css that lets you tightly couple your styles. The re-usability of…

> But clearly it has to have some value right? Why is it so popular?

Popularity doesn't mean much. I mean, look at React.

And Tailwind isn't that popular. From Twitter you might get the impression everyone is using it, but if you look at the State of CSS you'll see is not even close to something like Bootstrap or SASS.

https://2021.stateofcss.com/en-US/technologies

Re: Get in zoomer, we're saving React

#232

Post by [deleted] »

musingsole wrote: post #174
ourmandave wrote: post #150

Earlier quoted context omitted.

Today would you look for someone who grew up doing Rasberry Pi builds? I haunted Radio Shack back in the day, but would have loved to grow up doing single board computer stuff.

Raspberry Pi hobbyists are great in the IoT world. Almost an immediate hire if you can demonstrate an image recognition app.

[deleted]

Re: Get in zoomer, we're saving React

#233

Post by makeitdouble »

jasonjmcghee wrote: post #194
makeitdouble wrote: post #191

Earlier quoted context omitted.

On building the next Figma, my first reaction was that Figma should probably have been a compiled GUI application in a ideal world. Figma is a work tool where a designers are supposed to spend a decent amount of time, and when working on a specific project there is little navigation or moving to other pages. It being in the browser is a technical artifact to help the business model, but inherently there would be noth…

It being in the web means I can work on any computer without having to install anything, embed a Figma in a doc or wiki, and it’s super easy to write plugins (html/css/js).

The thing to me is...you are already dowloading the whole figma's client code base and running it in your browser. If it was a PWA it would even stay there.

Your point on installation is accurate in our current ecosystem, and I wonder how we could change that so "installing" isn't a hurdle. That's clearly not a simple problem to solve, but making the web "native" probably isn't either.

Re: Get in zoomer, we're saving React

#234

Post by LtWorf »

efdee wrote: post #145
LtWorf wrote: post #138

Earlier quoted context omitted.

You mean like download qt and make an app that compiles on everything and integrates much better than a webpage while also being much faster and smaller?

Don't expect me to download your .exe if you're solving a problem that can be solved using a web app.

Don't expect me to care if my exe solves your problem but you are too stubborn to use it.

Re: Get in zoomer, we're saving React

#235

Post by Too »

twodave wrote: post #149
ripe wrote: post #147

Earlier quoted context omitted.

Is there a back button? Honest question. I thought iPhones didn't have one. When I pick up my wife's iPhone I always feel a little lost.

Convention is to keep it in the top left. All the stock apps will use more or less the same navigation dock up top for back and other functions. Often apps will be rejected for not providing this kind of functionality predictability. This was the hardest thing for me to learn moving from Android to ios as well, but the smoothness of ios trumps all the hardship in my opinion.

Except in Safari, where it is now in the bottom left corner, after the move of url bar to the bottom of the screen.

Though there you can also swipe whole screen left to go back.

Re: Get in zoomer, we're saving React

#236

Post by DonHopkins »

CharlesW wrote: post #207
klysm wrote: post #201

Earlier quoted context omitted.

And calling the ARM transition seamless is also quite amusing.

Having been through it, it was as seamless as one can imagine. Remember that 99%+ of Mac users have no idea what this means from a technical POV, or understand the amount of magic that allows most Intel software to "just work" on Apple Silicon devices.

The only noticeable seam before the ARM transition was the terribly long and dreadful time between the PowerPC and the ARM when they were using hot ugly inefficient power hungry SpeedStep hobbled x86 and x64 processors jam packed into way too thin a case and hot glued next to swelling batteries without proper ventilation or cooling.

Re: Get in zoomer, we're saving React

#237

Post by StuckDuck »

georgyo wrote: post #164
StuckDuck wrote: post #118

Earlier quoted context omitted.

I'd say macOS actually is a lot more polished than Windows, but I agree with you that it is damn confusing. Try "closing" an app for example and you'll find that half the time it will not have closed properly, or maybe it did, who knows? It depends on the app. If it's vanilla you can bet it will have to be closed with CMD+Q

This is actually more confusing then windows. The visual UI element to close does not close. Instead you must click File->Quit or CMD+q. These are not intuitive and must be learned.

Agree with it being weird but intuitive != commonly known. Just because windows does it a certain way doesn't mean it is intuitive. It's just widely known and assumed. If GNU developed to be the worldwide market leader then we'd all find the CDE drag and drop applet system 'intuitive'

Re: Get in zoomer, we're saving React

#238

Post by pas »

shepherdjerred wrote: post #230
pas wrote: post #223

Earlier quoted context omitted.

Hm, can you describe what do you mean by "can't do this with templating"? Do you mean that since React/JSX kind of a superset of JS you can do higher order stuff in it, whereas in a simple templating language like Jinja2 you can't? Isn't that a false equivalence? I mean I regularly use patterns similar to HOCs in Angular. It's easy to wrap components[0] and it's just as possible to project components into other compo…

I wrote this on my phone. Hopefully it makes sense. No templating language is going to beat a general purpose programming language as far as features go. There’s no technical limitation of templated languages that would bar them from having the same functionality as a general purpose language. Whoever is designing the templated language is probably not going to design something as powerful as a general purpose langua…

Hm. I find this kind of inconsistent, as you already have HTML in your JS, so it's not just JS. HTML is the templating. JSX is a super lightweight layer on HTML with its own weird rules.

I don't like Angular's default verbosity of separating the template from the logic, nor it's hijacking of the simple double quotes, but I disliked fighting with JSX and too too large files in React. Plus in my experience React projects grow their own verbosity too (in my last NextJS project every component had at least 2 files, one for wiring up the state and one for lowlevel view things, and it was awfully unclear what goes where). Plus the stringly typed state store :(

I don't think it's true that a general purpose language will be always better than a templating language. For one thing the template gets interpreted, there's already a context, it can be safer and more efficient. I mean JSX is great because it allows easy interpolation, in plain JS you would have to do backticks and ${} and the IDE/editor/linter would need to guess (or you would need to annotate the string like in Markdown) about the syntax and semantics of what you want to emit.

Of course making the jump from the host language to the target language too onerous leads to inefficient engineering, boundaries placed at convenient instead of optimal places, etc.

And it's very good that JSX allows stepping back to JS easily. Angular templates allow that too, but it's just not as fluid (probably because the syntax is just meh).

There are specific keywords to do things in template-land and there are non-template ways, that are more general and more messy. Because DSLs can be more effective for the things they were designed to express. The simple React HOC composition is similarly simple in Angular too, and that's it. What's less appealing is that it happens in template land, and for some reason the wrapping in pure JS feels more powerful (to me too, don't get me wrong), but the actual hierarchy of components is defined in template - in JSX - in React too. It just feels closer to JS. (Rightfully so.)

Re: Get in zoomer, we're saving React

#239

Post by llIIllIIllIIl »

klysm wrote: post #203
llIIllIIllIIl wrote: post #17

React now is as mature as PHP4. Wake me up when it gets to PHP7 at least.

I don’t understand arguments like this. PHP is fortunate enough to run on a real operating system with real APIs. React is running in the browser which is quite possibly the worst place to make anything stable. It will never be as stable.

The only reasonable argument is that react helps you write the code that you will throw away and rewrite in two weeks.

Re: Get in zoomer, we're saving React

#240

Post by shepherdjerred »

pas wrote: post #238
shepherdjerred wrote: post #230

Earlier quoted context omitted.

I wrote this on my phone. Hopefully it makes sense. No templating language is going to beat a general purpose programming language as far as features go. There’s no technical limitation of templated languages that would bar them from having the same functionality as a general purpose language. Whoever is designing the templated language is probably not going to design something as powerful as a general purpose langua…

Hm. I find this kind of inconsistent, as you already have HTML in your JS, so it's not just JS. HTML is the templating. JSX is a super lightweight layer on HTML with its own weird rules. I don't like Angular's default verbosity of separating the template from the logic, nor it's hijacking of the simple double quotes, but I disliked fighting with JSX and too too large files in React. Plus in my experience React projec…

> I find this kind of inconsistent, as you already have HTML in your JS, so it's not just JS.

You don’t write HTML in React. You write JSX that gets compiled down to function calls which at runtime becomes HTML. JSX is a nicer syntax to make function calls look like HTML. I know this sounds pedantic, but this is the exact thing that differentiates React from others.

Post reply on HN