Hacker News Reader

Comment by KaiserPro | Hacker News Reader

I 100% feel your pain.

I used to work for a very large financial news company. They were all javascript. I though to my self: I learnt JS in 2008, this should be easy (it was 2014). Apparently very hard.

HTML isn't HTML anymore JS is forced everywhere, and everything has a different name.

Anyway, I disappeared back into HPC/VFX/machinelearning, to re-appear into webdev in 2020.

I was forced to do some front end work as part of a bootcamp. It took the best part of a week to make a bit of text a link.

The template library was so far removed from anything googleable, there was no documentation, worse still no style guide or example style guide.

I am glad I don't do web GUIs, they are hard and nasty.

View on HN

It took the best part of a week to make a bit of text a link.

This highlights the problem with web dev quite nicely. Not doubt you weren't really just making some text in to a link. I know the sort of thing bootcamps do, so you were probably installing and learning React, displaying a set of components, implementing React Router, and figuring out how to update app state based on the browser's History API. All with a template library that was a terrible choice for learning (because it didn't have docs). You could summarize that as "making a bit of text a link", but that's glossing over the details.

What you were really doing was learning component orchestration, reactive state management, and a browser API. Why wouldn't that take a week?

So the problem with web dev is actually that it's really, really easy to trivialize. You can make hard things sound like they should be very straightforward because they look a lot like something simple from the past. And when people find that they're not really doing the simple thing any more they complain because the new, harder way of doing something (which is actually doing something completely different eg reactive state management and in-browser routing vs asking the browser to do a GET) is hard.

And there's the problem...

"...component orchestration, reactive state management..."

Webdev tool makers are sadists, and many of the 'thought leaders' in the field have Stockholm syndrome.

Some aspects of web development certainly are hard (security especially).

Frontend development however, does not need to be as hard as it currently is. At the very least, I think there's an opportunity to simplify that layer of the stack, and give the control back to design professionals.

Dreamweaver to my mind, represented a more productive direction than React currently does.

Sure there's lots of reasons to not use React and many places don't. Bad management/decision making is more to blame in this case than anything.

On the contrary, front end isn't good enough yet, and getting to the point where it's ideal will require more complexity. Users want things to work fast. If you're including a roundtrip to a server your app will never be good enough for a user on a rural 1Mbps satellite connection with 500ms latency. That's the goal - your app has to work well for that guy. You can't get it to be fast if you're using the network a lot. We need concurrent rendering, async background processing, and as much work shifted on to worker threads as we can manage. All the things that native apps do to crank up the performance need to happen on the web too.

Also, don't forget that the web is fantastically backwards compatible. You can write web apps without the complexity if you want to. You can use Dreamweaver! You can server-side render every page. It works. If that's what you want to serve your users then you should do that. Just don't complain when they use the competitor's app that's faster, more responsive, and does fun things like working offline.

More than any framework, what most market leading applications need to provide a competitive service, is greater access to creator resource (developers / designers / content creators, whatever) and / or innovation in pre-production and design.

The problem with current development trends is in how the complexity found in the tools, makes the pool of available creators (at a want for a better term) a tiny, exclusive club. This has a detrimental effect on efforts to innovate at design / pre-production stage, because the designers are near enough held hostage by us developers.

It also has an overall effect on project velocity, because work that could possibly be covered by techically competent designers (namely HTML/CSS development), can only be addressed by expensive and exclusive 'framework specialists'.

I strongly believe this can change by rethinking where the complexity lies.

The culture built around over-complicated tooling is possibly analogous to placing the responsibility for the production of a feature film in the hands of the VFX and lighting teams, or perhaps only deeming a mechanic as having the aptitude to drive a car.

I'm not rigidly stuck to this idea, I'm just musing here.

perhaps only deeming a mechanic as having the aptitude to drive a car

This analogy is a really good one, but you've got it slightly wrong. The website user is the person driving the car. The developer is the equivalent of the person building the car. Saying the development process is "too complicated" is like saying developers should only ever build compact family cars like a Ford, but some of us want to be building BMWs and Teslas and Porsches and F1 cars and monster trucks and semi-trucks, etc. Sure, it's more complex and difficult, but the end result suits the user better, fulfils their needs better, and often just makes them a lot happier.

> If you're including a roundtrip to a server your app will never be good enough for a user on a rural 1Mbps satellite connection with 500ms latency.

That's a tiny minority of users. And that sort of user probably has an old, slow computer which is crushed under the weight of your vast javascript framework, anyway.

Whatever about a _better_ experience (some subjectivity there, though I don't really buy it) I'm pretty sure the modern web isn't a _faster_ experience for most users than it was a decade ago.

That's a tiny minority of users. And that sort of user probably has an old, slow computer which is crushed under the weight of your vast javascript framework, anyway.

React isn't vast. React and ReactDOM together are about 40Kb over the wire of total download size if they're gzipped (https://bundlephobia.com/result?p=react@16.13.1 && https://bundlephobia.com/result?p=react-dom@16.13.1). For reference, the latest version of jQuery is 30Kb. Personally, I test all my production builds on a Chromebook that has 2GB of RAM, and they usually hit 60fps even on relatively complex pages. This is what the standard should be for building for the web - small, fast web apps that work well on slow computers and slow, high latency internet connections.

You can decide not to support everyone if you want, but that's a decision. The technology already works quite well if you put the effort in to building things properly. Build complexity is not a good excuse for serving slow apps.

It's rarely just react, though.

It's possible in principle to build small fast SPAs, but they're vanishingly rare in real life. And even where code size is small, CPU usage and latency are often bizarrely high; even that 500ms latency user might find a roundtrip to the server faster than waiting on some SPAs.

I do a lot of my personal browsing on an elderly (six year old) iPad. It's totally fine for normal web pages, but every year the number of websites which are painful on it rises, due to (usually largely unnecessary) javascript.

If a simple link to another page requires component orchestration and reactive state management I'd say it is a bit over-engineered.

The actual task was this:

There is an Icon, and some text that reads: "you are on a trail find out more" The find out more is a link, make sure all the text _and_ the icon are included in the link.

So its not creating a new state or widget. its literally moving a href tag.

Well it would have been, if it wasn't for the template engine, and what ever the state engine was/is.

Now, if this was QT creator, I'm pretty sure I could have done this task in about 4 hours (I don't know C++ very well and I've used QT about 3 times before, each for less than a day.)

Which leads me onto the next gripe

As this is all templateable and composable. why in living fuck isnt there a GUI to do this sort of thing?

I mean, on a large website you need to make widgets, then you need to compose those widgets into screens. Those screens maintain state (basically flash, but with 100x worse performance)

the people that are styling the widgets are not always the same as those adding the logic, so why not make a tool where a visual artist can actually work visually?

So why on earth is it not drag and drop? Yes some things are auto generated based on context, but a lot of things are static screens where the widgets update the state.

the people that are styling the widgets are not always the same as those adding the logic, so why not make a tool where a visual artist can actually work visually?

Framer X. Sketch. Adobe Xd. etc

I mean, on a large website you need to make widgets, then you need to compose those widgets into screens.

Storybook (sort of).

So why on earth is it not drag and drop?

Dreamweaver.

The tools you want all exist. Those are just a few examples. There's hundreds more. You just didn't look very hard.

> JS is forced everywhere

I think this has a lot to do with it, interestingly. The web has become so ubiquitous, and the major players are so resourced, that the barrier to entry can seem really high. Maybe I'm wrong, but my perception is that potential customers wouldn't take a second glance at my sight if it were plain html with minimal CSS and didn't render perfectly on mobile.

> I am glad I don't do web GUIs

Same.

You can make a very lovely site with just HTML and CSS! CSS is extremely powerful by itself. As long as you don’t need any dynamic content or dynamic UI, you can likely avoid JS entirely :)

You can, but if you’re doing any sort of non-static website then you still have complexities in the backend to deal with. (For static sites, I fully agree that HTML and CSS are more than enough most of the time; at least, they’re good enough for my website!)

> As long as you don’t need any dynamic content or dynamic UI

People seem to be ordering more of that, not less. Look at Reddit. They have all manner of stupid animations now.

You can do all kinds of stupid animations with pure CSS.

Honestly, they're only hard and nasty if you make them hard and nasty. A text link is as easy as <a href="">...</a>.

You can of course use React with 2 different libraries to achieve the same goal, but why would you do that.

React by itself isn't difficult either. Anyone who has an hour or so to spare can go through the tutorial https://reactjs.org/tutorial/tutorial.html.

They need to rewrite it to use hooks at some point, but it's still a pretty good intro.

> They need to rewrite it to use hooks at some point

What is the reason that not using hooks is so frowned upon? When I took my first steps with React, I didn't know hooks, so I write component classes and it immediately "clicked" with me because it behaves like most other GUI frameworks do, from Win32-based (1) to X-based to Android to iOS to macOS to Java, and tons of higher-level frameworks in between. It also feels obvious to write a component class because you are describing the behavior of a stateful thing, that is, exactly what classes are made for.

With hooks, OTOH, we have a stateful "function", but all state is implicit, which describes behavior other than its main behavior (rendering) but that is implicit too... I can see why developers outside the React world don't "get" hooks, because I can't even remember seeing this idiom outside the React world. (BTW, I've seen the claim that hooks are easier to reason about, for which I found the opposite to be true, and the claim that this makes the main function stateless, which is absurd since the state just becomes implicit).

(1) the raw system-level APIs are often not class-based, but nearly all frameworks above it are.

edit: the footnote broke formatting

Classes look familiar, but that's misleading because they don't actually work like one would expect.

Hooks are actually much closer to what react does internally, and therefore behave much less surprisingly once you get into advanced things. Think of hooks like a missing primitive (similar to functions, classes and closures) that are critical to the react language, but don't actually exist in JavaScript and thus have to be approximated.

> Classes look familiar, but that's misleading because they don't actually work like one would expect.

Can you give an example for that? So far, they worked pretty much as I expected. (Coming from a mostly Java background, which is relevant for what I expect).

Regardless of how you feel about hooks, they are, or are quickly becoming, the new standard for most React code, so a React tutorial obviously needs to familiarize people with them. The current tutorial is good at explaining React concepts though, so making the jump to hooks after reading it and doing a few simple playground projects should be trivial.

As for why people like them so much as opposed to classes, my guess would be that they let people more easily write reusable behaviors for common tasks (e.g. look at this one for integrating with RxJS Observables for projects using RxJS https://github.com/LeetCode-OpenSource/rxjs-hooks#examples - with classes you would have to put code in several lifecycle methods, sometimes duplicate code, for each individual component).

Hooks are a fair bit easier to manage than classes in React. It won't change what you do with React much, but from file to file, it's more pleasant to read a hook based component, when compared to a class based component, once you're used to it.

Hooks also simplify working with React context a great deal. If that's your option for state management.

As a frontend developer with a great deal of React experience, I respectfully disagree.

React is unnecessarily hard, and this fact probably keeps the UI development out of the hands of the people who could potentially do the best work (graphic designers).

If you want, there are APIs and frameworks that will allow programmers to configure print layouts and typography by hand.

As you can imagine, they're not as well known or as popular as the Adobe tools used for this work.

I'm not saying that web based UI development isn't without its unique challenges (state management), but I will say that things could stand to change, and we should move towards simplifying stacks, for what will ultimately be the user's sake.

Reply on news.ycombinator.com