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

A tale of webpage speed, or throwing away React

solovyov.net

Post reply on HN
Print view View original

311–319 of 319 posts

Re: A tale of webpage speed, or throwing away React

#311

Post by deergomoo »

pattycakes wrote: post #310
deergomoo wrote: post #284

Earlier quoted context omitted.

Yes. HTML is a terrible platform for applications. It provides basically nothing and I am continually surprised that it doesn’t seem to be a major focus for improvement like JS and CSS. I don’t need more types of semantic rectangle, I need actual real UI controls that are efficiently rendered and accessible by default, so I don’t have to build everything from scratch. The fact that there’s no built-in element for thi…

>The fact that there’s no built-in element for things like dropdown menus is mind boggling to me. You mean the select tag?

No, I mean like a pull down menu. Like when you click “File” or “Edit” on $desktopOS

Re: A tale of webpage speed, or throwing away React

#312

Post by schwartzworld »

madeofpalk wrote: post #303
schwartzworld wrote: post #277

Earlier quoted context omitted.

It is actually in the react documentation. https://reactjs.org/docs/dom-elements.html#style I'm not saying that's how it should be done. I'm just clarifying what the author of the article was referring to.

Correct, it is documented. That's what documentation is - to list out and describe the API surface. The entire documentation block for that is prefixed with a big yellow-box warning: > using the style attribute as the primary means of styling elements is generally not recommended. And then it links to https://reactjs.org/docs/faq-styling.html which just says over and over again "use class names"

So just to be clear A) it didn't always have that warning and B) I wasn't defending the practice. Did you read the article?

Re: A tale of webpage speed, or throwing away React

#313

Post by crooked-v »

krzepah wrote: post #300
crooked-v wrote: post #247

Earlier quoted context omitted.

Being able to dynamically supply theming is a big one. For example: const Header = styled('header')` font-family: ${({ theme }) => theme.fonts.header}; color: ${({ theme }) => theme.colors.primary}; backgroundColor: ${({ theme }) => theme.colors.primaryBackground}; ` ...where the theme object can be swapped out on the fly for different sections of a web app.

Thanks i haven't thought about that one. But i'd definitely try to stick up to css even if I'd have to dev that feature. Maybe by trying to change the var(--color) i've setup in my colors.css ; I'd note out that this feature is also so edgy that the pushed argument shouldn't even occur that much. It would be like "Oh hei, I need to dig up that super edgy star shaped hole using that shovel so I'm using it that way. Oh…

It's only an edge case until you handle white-labeling services for other companies, at which point you immediately need a way to conveniently tweak the styling of everything in your web app per white-label client, preferably in a database-supplied way so that your support team doesn't have to handle every adjustment said client wants to make.

Re: A tale of webpage speed, or throwing away React

#314

Post by krzepah »

Kuinox wrote: post #306
krzepah wrote: post #304

Earlier quoted context omitted.

What are you talking about ? Are you saying a search feature is not necessary in my specs because you like using f3 or ctrl-f ? "On mobile, using menu to search in browser menus" -> This is not a sentence. I do add a "few bytes" to "reimplement" a "browser feature" ; but the reality is that i HAVE to implement search because it is hitting on 730000 per year records; How is you ctr-f or f-1 feature is gonna search on…

""On mobile, using menu to search in browser menus" -> This is not a sentence. " -> Sorry, I meant using the browser search feature by invoking it from the contextual menu of your browser, which is the only way to spawn the search toolbar on mobile. " but the reality is that i HAVE to implement search because it is hitting on 730000 per year records;" -> True, there should be a search feature with a backend API. "Aga…

Thanks for the read ! I didn't know svelt and it seems like it has solid motivations. I should definitely check it out.

I'm actually more of a preact fan and the community Jason Miller has created, their work have inspired me a lot in concern of front-end and javascript dev.

ctrl-f hook is effectively something that has to be considered when implementing such feature.

I'd argue that the list & search feature it self is hard, not as something to put on and program and get working, but as a user-experience and design perspective (I'd like to thank you about pointing that out by the way, I will definitely spend some time making sure it's there for my app)

The reason I can think of, is that we do actually take control over parts of the applications in a way that was not imagined when browsers implemented search function.

It almost feels like the "With big power comes big responsibility", but i don't like the word "power" in our case, so I'd change it to something alike to "With features that have extra consequences we need to have an equal amount of extra care to even considering them." as if it was hidden and we needed to understand the tool better to have it properly done.

I guess front-end dev is easy to get in and understand, but hard to master, and that could be why we end up with these rampant "half-done" apps that do not take those extra steps.

In the end, the rushed dev will probably just look to have it's app working and will not check these kind of "bugs" that have been caused by his decisions,

Tbh, without this discussion i'd probably have missed it too

Re: A tale of webpage speed, or throwing away React

#315

Post by tluyben2 »

krzepah wrote: post #305
tluyben2 wrote: post #301

Earlier quoted context omitted.

> Stop crying around on HN and go dev your feature Not reddit here, people like to talk about and ponder eachother's opinions.

Honestly I like HN but the constant talk about PWA vs pure HTML apps has became tiresome and unproductive. I haven't seen a single argument that's properly stated about why we shouldn't do them. Having argument alike "Oh I have to dev that feature therefor X sucks" is not a good enough opinion that i would like to read here neither.

People implement different ways of doing things all the time; they have to get ideas somewhere and they also have to see their work is worthwhile for others. You might or not like the current state; you just suck it up, I get that, we all do. We also can complain and try to do something about the things we do not like. Every new software is created for some reason; money opportunity, interest, scratching an itch or trying to get rid of pet peeves. Nothing wrong with that and personally I like to read about people’s issues with software; it keeps me confident that ‘this’ is not ‘it’, because if it was, I would become a full-time pizza chef. In the meanwhile, obviously I suck it up and build things; I can still hope for better. For me personally, Phoenix and Blazor(server and maybe client) show that I am not the only one annoyed by the stuff ‘everyone uses’.

Noone (well...) sits behind HN crying while doing nothing; but it is a platform where people go who actually make the changes or at least talk about them without dismissing them with ‘just use node/react and stfu’ or, almost the opposite, ‘just use wordpress and stfu’ like much of reddit and other programming forums (as far as there are).

Re: A tale of webpage speed, or throwing away React

#316

Post by ksec »

JohnBooty wrote: post #258
recursivedoubts wrote: post #189

Earlier quoted context omitted.

Yep. The problem is that HTML was never completed as a hypertext, they just kinda stopped at anchor tags and forms. There isn't a good reason that only anchors and forms should be able to specify HTTP requests. There isn't a good reason that only clicks or form submits should be able to trigger HTTP requests. There isn't a good reason that only POST and GET should be readily available (and POST only for forms.) And t…

There isn't a good reason that only anchors and forms should be able to specify HTTP requests. There isn't a good reason that only clicks or form submits should be able to trigger HTTP requests. There isn't a good reason that only POST and GET should be readily available (and POST only for forms.) That's an excellent and thought-provoking way to think about it. I'd always been mentally locked into HTML's basic "the w…

Yes. Unfortunately none of the Standard and Browser Vendor has any interest in improving it.

Re: A tale of webpage speed, or throwing away React

#317

Post by heavenlyblue »

mattmanser wrote: post #191
heavenlyblue wrote: post #106

Earlier quoted context omitted.

I would say that what JS animations are even better at is justifying inflated budgets of the projects made for people who are not very familiar with tech. Is there ever a real reason for animations that doesn't make the interface feel sluggish and unresponsive? In the other hand if you actually set the animation delay to something incredibly low, all of your animation needs could be easily solved by animating the tra…

Animations are effective, and I say that as someone who really hate slow ones. If you start paying more attention to the apps you use, especially ones made by bigger companies, and you'll notice how effective some of them can be.

Is the latest version of Google Calendar web interface a good example?

I don't think it is. And it's from a company which can afford a lot of development resources for that.

Re: A tale of webpage speed, or throwing away React

#318

Post by AtlasBarfed »

collyw wrote: post #239
AtlasBarfed wrote: post #109

Earlier quoted context omitted.

It's almost like all "modern JS" are written by new programmers hired on the cheap by companies to work on their new hip UI frontends. IMO UI is generally something new programmers like because of the visual/visceral "I built that", but once you get exposed to the sheer annoyance of UIs, programmers will migrate to backend. So the most experienced people don't want to be constantly undercut in price by the incoming "…

The JavaScript world changes so fast that no one is ever going to be very experienced in the the they are using. I imagine that is partially to blame for all the crap we see in the front end.

I agree, the JS ecosystem is reflective of constant new programmers redoing the UI every couple years, although I need to grit my teeth and admit that React did at least standardize/structure the ecosystem for the last few years.

Re: A tale of webpage speed, or throwing away React

#319

Post by PretzelFisch »

tomc1985 wrote: post #209
aphextron wrote: post #126

Earlier quoted context omitted.

It's just apples and oranges. Web pages should never even consider using React. Maybe a bit of vanilla JS/jQuery here and there for whatever interactivity you need, and then server side rendering for the content. Building web applications on the other hand, has been revolutionized by the use of React. I would never seriously consider any other UI rendering library right now because of the sheer volume of support and…

> The alternative of doing things old school with server side templates is ok, but it massively slows down your iteration speed through reliance on tight coupling between backend and frontend. Huh? Something like Rails lets you iterate on server-side stuff extremely quickly. There is a lot of functionality you can implement that doesn't need JS at all

At this point, I think we'll start to see an electron shell that you can install apps/extensions into. The main thing that will prevent this from gaining traction is ios.
Post reply on HN