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

Second-Guessing the Modern Web

macwright.org

Post reply on HN
Print view View original

451–460 of 467 posts

Re: Second-Guessing the Modern Web

#451

Post by chrischen »

ComputerGuru wrote: post #377
chrischen wrote: post #180

Earlier quoted context omitted.

I did address that it depends on your requirements. But my point is that it is highly unlikely that any requirements would be better served by vanilla JS + html than say writing your code with ES Next or React, unless you truly have some sort of limited use one-off thing. Tools like webpack, babel, and react are also orthogonal to whether or not you're doing an SPA. These new tools aren't just to make your app a SPA,…

> than say writing your code with ES Next or React Say again? One is a framework, the other is an updated version of the language that can be transpiled to ES3 for (non-mathematically) provably identical results.

React isn't a framework. It's a library for writing functional components which can, at the moment, target native mobile components and HTML components so that you are not writing the components manually in a platform specific way.

Re: Second-Guessing the Modern Web

#452

Post by tomaszs »

learc83 wrote: post #414
tomaszs wrote: post #395

Earlier quoted context omitted.

Virtual DOM actually has some efficiency benefits. So it is not as easy as no Vdom = better. Also React, Angular or Ember does not add a lots of code to the project. I am 100% sure real world app written in each of major frameworks including Svelte has almost exactly the same size. Svelte has the same problems like React or any othe framework.

>Virtual DOM actually has some efficiency benefits. Please explain these efficiency benefits. VDOM architecture can't be faster than native javascript updating the DOM because at the end of the day you still have to to use native javascript to update the DOM. > Also React, Angular or Ember does not add a lots of code to the project. They do to small apps. I tend to embed small svelte apps inside of a larger multi pag…

Touching DOM is an expensive operation. Think about the virtual DOM as a double buffer.

Re: Second-Guessing the Modern Web

#453

Post by robertoandred »

userbinator wrote: post #437
robertoandred wrote: post #384

Earlier quoted context omitted.

Not sure why you think SPAs can't have unique URLs or real links.

They can, but it requires additional work on the part of the developers, which in my experience is almost never done. Also, that's kind of what the SPA acronym stands for, no?

It does not require much work, and basically none of you use any standard libraries or frameworks, which handle it all for you.

And SPA doesn’t mean you can’t use real links or pages.

Re: Second-Guessing the Modern Web

#454

Post by gofreddygo »

burlesona wrote: post #72
luxphl wrote: post #47

I empathize with the author but client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. It's true that they are largely more complex than O.G.…

For the most part I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting. If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most. For the hipsters, the problems of SPAs are hard, and engineers like hacking on hard problems. Also the fact that the…

At work, I've been forced to use angular. It's just awfully complicated, breaks subtly, changes (not improves) constantly and has sucked in hundreds of developer hours that could have been better utilized.

I was appalled at the state of things in front end development till I realized my current project uses kubernetes (implies docker, helm), spring for implementing REST endpoints and ansible for deployments on the back end.

Now things are really fucked.

On both ends.

Re: Second-Guessing the Modern Web

#455

Post by learc83 »

tomaszs wrote: post #452
learc83 wrote: post #414

Earlier quoted context omitted.

>Virtual DOM actually has some efficiency benefits. Please explain these efficiency benefits. VDOM architecture can't be faster than native javascript updating the DOM because at the end of the day you still have to to use native javascript to update the DOM. > Also React, Angular or Ember does not add a lots of code to the project. They do to small apps. I tend to embed small svelte apps inside of a larger multi pag…

Touching DOM is an expensive operation. Think about the virtual DOM as a double buffer.

You don't need a VDOM to use a buffer to batch changes. A VDOM is a buffer that comes with a huge amount of overhead vs an ordinary sequential buffer of DOM manipulation commands.

VDOM is an optimization that allowed react to be fast enough to work, it can never be faster than direct dom manipulation.

Re: Second-Guessing the Modern Web

#456

Post by mnming »

amw-zero wrote: post #314
userbinator wrote: post #107

Earlier quoted context omitted.

Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static Exactly. As a bonus, you automatically get the behaviour associated with a link that browsers already implement: people can bookmark a link for later use, open it in a new window, etc. All of which would need extra effort (and thus also easily break) if it was just a clickable eleme…

“Let the page refresh” translates to a terrible UX. It devalues the application. It’s equivalent to buying a physical product, say a car, but the car jerks up and down whenever you hit the gas, and you hit your head on the roof every time. Yea, the web page _works_ but it’s ugly, and in poor taste. Users do not care about browser purity, they want an app that seems polished. You can’t get that experience by using sem…

Can't agree more. It's a very simple point but I am surprised that people couldn't realize it and even downvoted your view.

IMO, discussing this further will just yield a negative returns as I think there are some fundamental issues/gap between two parties in this thread.

No matter how much ppl kick and scream, the SPA is gonna make the web a much more user friendly place in general. When we fade away and the next generation of us come, they will take this as the new norm easily and happily.

Re: Second-Guessing the Modern Web

#457

Post by ng12 »

okareaman wrote: post #241
ng12 wrote: post #224

Earlier quoted context omitted.

That's not why hooks were invented. Hooks are by definition component local.

I'm not a React expert, but I wonder how do you interpret this by Dan Abramov? This is where I got my information about hooks before trying them out: React doesn’t offer a way to “attach” reusable behavior to a component (for example, connecting it to a store). If you’ve worked with React for a while, you may be familiar with patterns like render props and higher-order components that try to solve this. But these pat…

Right, it's not that managing state was hard it's that sharing the logic to manage it was hard. Hooks are additive in that way -- it's offering you the ability to re-use your stateful React logic in the same way you can re-use your declarative JSX.

Re: Second-Guessing the Modern Web

#458

Post by ratww »

chrischen wrote: post #450
ratww wrote: post #282

Earlier quoted context omitted.

> Tools like webpack, babel [...] but are meant to decouple the maintainability of your code from the implementation details. Let's be real, the only reason we really need WebPack and Babel at this point is for IE11 compatibility and JSX. Currently >90% of the browsers (that depends on the country) are evergreen, and have support for most ES6 features, including ES6 modules. As soon as we're able to drop IE11 (when w…

Babel is there so you can write your code with the latest Javascript features and separate your written code from what is actually deployed. JSX and IE11 are a subset of problems that this type of abstraction can solve. This is miles better than the previous alternative: manually importing shims or adding in css prefixes. Babel and webpack also enable macros and static code analysis tools so you can write code in "in…

Nope. You're the one advocating targeting a specific platform, and it's called Babel.

What I'm advocating is targeting evergreen browsers whenever possible: Chrome, Safari, Firefox, Edge, and their forks. They already have most ES6 features. Even Safari has great ES6 support. iOS is known for being very up to date. Fragmentation in Javascript is a thing of the past, as long as you only use features available for +90% of the people on caniuse.com.

If you're targeting evergreen browsers you can already write the latest Javascript, and would only need Babel for something like JSX. All those browsers have async/await, ES6 modules (aka import), arrow functions, and destructuring.

To separate your written code from what is actually deployed is much more of a con than a pro. I'd rather not need a compilation step if possible. My time is valuable. Babel and Webpack are slow as a dog for non-toy projects.

Manually importing shims are a thing of the past when you're targeting evergreen browsers. You can use something like Polyfill.io for edge cases, and it will cover the small number of

CSS prefixes have nothing to do with Babel or Webpack, they're normally handled by tools like PostCSS. Nothing to do with Javascript. Static Analysis is normally handled by tools like ESLint that can use Babel but can be completely decoupled from the compilation step. Or Typescript, which actually brings a lot to the table compared to Babel.

Again, this might be hard: maybe you need to handle customers with IE11. But to not need Babel is something we should aim for.

I honestly can't wait for Babel to be 100% unnecessary and to die. It is valuable in a world where Internet Explorer exists, but there is zero advantage in using it when it's unnecessary.

Re: Second-Guessing the Modern Web

#459

Post by luord »

While I largely agree with most of the points made, I strongly disagree with the objections made about APIs. In general, that section seems to have been written with the assumption that the web application is the only client an API can have.

This ignores mobile applications, desktop applications, third party services, webhooks, SDKs and maybe even command line interfaces. The more standardized the API, the easier it is to create multiple clients for it; it's one of the principles of the clean architecture even.

Re: Second-Guessing the Modern Web

#460

Post by tomaszs »

learc83 wrote: post #455
tomaszs wrote: post #452

Earlier quoted context omitted.

Touching DOM is an expensive operation. Think about the virtual DOM as a double buffer.

You don't need a VDOM to use a buffer to batch changes. A VDOM is a buffer that comes with a huge amount of overhead vs an ordinary sequential buffer of DOM manipulation commands. VDOM is an optimization that allowed react to be fast enough to work, it can never be faster than direct dom manipulation.

Yes. You are right. Vdom is useless.
Post reply on HN