Second-Guessing the Modern Web • Hacker News Board

Re: Second-Guessing the Modern Web

#371

Post by unclebucknasty » Mon, May 11, 2020, 1:54 PM UTC

pbourke wrote: post #251

unclebucknasty wrote: post #231

Earlier quoted context omitted.

I'll take it a step further and say we shouldn't be using the Web paradigm at all. We've tried a million different ways now to essentially generate HTML. So many frameworks. So many libraries. Front end. Back end. Etc. But, we're still working within the paradigm of the stateless Web, designed to display documents and images. Trying to hammer an application in there (especially a SPA) really doesn't make sense. So, w…

> So, why do we just keep forcing it? Because hyperlinked documents are the whole ball game. Web technologies are a pain in the ass for developers but a boon for the advancement of human knowledge and connectedness. The great islands and continents of web space float in the same aether. They interconnect, despite being built at different times, in different styles, on different technologies. It all just, for the most…

My comment was WRT to a better model for developing SPAs and complex Webapps, not sunsetting the Web in general.

Re: Second-Guessing the Modern Web

#372

Post by deergomoo » Mon, May 11, 2020, 2:06 PM UTC

_630w wrote: post #216

runawaybottle wrote: post #139

I’m tempted to step back and evaluate this on another level. Our industry is very big, and any industry that gets that big will be able to house a lot of people just for the sake of it. If you think we have a large amount of fresh frontend people, understand they are hired almost with a one to one correspondence with fresh product/business people. Modern product development is essentially a polishing job on every com…

At this point, I am convinced the problem is not web frameworks but browsers. Someone needs to take all the legacy bloat away and put it in the side while starting from the scratch. Web doesn't need three different languages. It doesn't need freedom that costs accessibility. It doesn't need to be so primitive. It smells. Awful defaults. import "reset.css" import "reset.js"

I agree, I feel like all the points both for and against SPAs and frontend frameworks in this thread are just circling around the idea that browsers make an awful platform for building software. But the delivery mechanism is so much more compelling than anything else available, and the momentum so great, that we're all willing to put up with it.

It will never happen, but I wish there was a second stack that browsers understood, totally separate from the DOM, purpose built for developing _applications_, rather than abusing the fact that this document creation tool allows us to put styled boxes in different places.

This is not really a failing of HTML, CSS, or JavaScript, but if your platform SDK's total feature set for building UIs amounted to some basic form inputs, incredibly inflexible tables, and a handful of ways to add semantics to otherwise featureless blocks of text and boxes, you'd be laughed out of the room. The fact that anything remotely feature rich must be built from scratch is part of the reason the ecosystem has such a bad rap for over reliance on packages, and for constantly reinventing the wheel.

Re: Second-Guessing the Modern Web

#373

Post by unclebucknasty » Mon, May 11, 2020, 2:18 PM UTC

worble wrote: post #253

unclebucknasty wrote: post #231

Earlier quoted context omitted.

I'll take it a step further and say we shouldn't be using the Web paradigm at all. We've tried a million different ways now to essentially generate HTML. So many frameworks. So many libraries. Front end. Back end. Etc. But, we're still working within the paradigm of the stateless Web, designed to display documents and images. Trying to hammer an application in there (especially a SPA) really doesn't make sense. So, w…

I'm personally curious how far we could go with using just canvas and wasm. If we focused on making a browser that was just incredibly efficient and focused at using wasm and webgl, and had no other concerns, a lot of the cruft could be cut. Then any given "page" would essentially just expose the canvas for wasm to draw to, and GUI frameworks like Qt (which already can compile to wasm I believe) could just target thi…

Yes, the Web should stay what it is for static documents. In fact, what I advocated would continue to be based on Web standards (HTML, CSS, Javascript, and newer constructs like canvases, etc).

So, you would have a JS-based VM that runs in the browser. No Flash or other binary. Just pure Web standards for executing the code, rendering, etc. However, as an app developer, you wouldn't touch HTML or Web standards. Instead, they'd all be abstracted away and you'd work within a component/event driven model that's provided by the VM.

Instead of CSS, you'd roll themes, allowing you to stylize components. They'd ultimately be applied via CSS, but ideally you'd have a GUI interface for creating these themes. CSS gives you ultimate flexibility, but why are we still fighting whitespace and these other low-level document layout constructs when we are really working at a UI component/control level? It's like designing in assembly.

Instinctively, people won't want to give up this granular control. But that's only because we've been thinking about apps in Web terms for so long.

For me, that's the problem with a lot of these frameworks. They do a great job of helping you to wrangle the impedance mismatch between the web and apps. But, they are all predicated on deference to the Web, so they keep us immersed in this world, essentially fighting the Web's ill-fittedness to the task: HTML templates, DOM management, render functions with HTML strings, CSS styling embedded in "components", etc.

Why go so far to create a framework only to hamstring it with the very problems it aims to solve?

Re: Second-Guessing the Modern Web

#374

Post by pier25 » Mon, May 11, 2020, 2:22 PM UTC

dbbk wrote: post #355

pier25 wrote: post #101

Earlier quoted context omitted.

Obviously Svelte can't do nothing about the misuse of Svelte (which is one the major points of the article) but: > The level of abstraction that React works on is too high, and the cost of using React - in payload, parse time, and so on - is too high for any company to include it as part of an SDK. Svelte is just a simple way for you to write vanilla instructions. There is no runtime and practically no framework. Oth…

> There is no runtime and practically no framework. Why is this a good thing? Surely most developers want a framework?

Svelte is a compiler, and yeah you have to structure your code to fit certain patterns, but there is no framework in the end result as you would expect from React/etc.

Re: Second-Guessing the Modern Web

#375

Post by FragrantRiver » Mon, May 11, 2020, 2:27 PM UTC

grey-area wrote: post #336

amw-zero wrote: post #332

Earlier quoted context omitted.

It's funny, your example actually shows the primary benefit of an SPA, and doesn't do anything to show any downsides. A progress bar is a perfect example. You can't show a progress bar with HTML. You would have clicked something, and a new page would be rendered entirely. In the time it took to create the new page on the backend, the user would be staring at either a white screen or the current page. If they're looki…

This is an amazing feature you simply don't need on the majority of web apps, because a) the browser has a loading indicator and b) most web apps are fast enough to not need to tell the user about it, they just load new pages in milliseconds instead. An in-page progress bar is in most cases a failure of UX, not a success.

I'm pretty sure I can find more pages that take more than 200 milliseconds to load than ones that are under.

Re: Second-Guessing the Modern Web

#376

Post by brlewis » Mon, May 11, 2020, 2:28 PM UTC

ksec wrote: post #363

burlesona wrote: post #72

Earlier quoted context omitted.

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…

>“wow, I didn’t realize you could actually do anything useful with just plain JavaScript in the browser. I thought it was like... assembly or something.” Wow. These two sentences completely capture modern day Web Development, Javascript as assembly. >I think there’s a lot of that in front end world today. In modern Web development, ( and in possibly all area of software development ), instead of making things simpler…

FWIW, the first conference where I heard speakers talk about learning JavaScript first before leaning on a framework, was jQuery 2008.

Frameworks are not inherently premature abstractions, but can be used that way.

Re: Second-Guessing the Modern Web

#377

Post by ComputerGuru » Mon, May 11, 2020, 2:34 PM UTC

chrischen wrote: post #180

zerkten wrote: post #160

Earlier quoted context omitted.

> A lot things can be easier if you do things the "wrong way". > It depends on your setup and use cases whether or not something is overkill, but for any reasonably large app just doing some HTML and javascript is not going to be enough to keep things maintainable... I don't think you are responding to the point that the previous comment is making. The point is that there is a spectrum from let's say, traditional, to…

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.

Re: Second-Guessing the Modern Web

#378

Post by m33k44 » Mon, May 11, 2020, 2:39 PM UTC

pjmlp wrote: post #213

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.…

I have been developing all sorts of native and Web applications for a couple of decades now, and SPAs is something I avoid as much as possible. And yes, I also implemented interactive desktop like applications as Web applications. Server side rendering frameworks, with support for components and just enough JavaScript go a very long way, and best of all, they are faster than SPAs in every kind of device that customer…

What frameworks do you use?

Re: Second-Guessing the Modern Web

#379

Post by pier25 » Mon, May 11, 2020, 2:43 PM UTC

lhorie wrote: post #198

pier25 wrote: post #101

Earlier quoted context omitted.

Obviously Svelte can't do nothing about the misuse of Svelte (which is one the major points of the article) but: > The level of abstraction that React works on is too high, and the cost of using React - in payload, parse time, and so on - is too high for any company to include it as part of an SDK. Svelte is just a simple way for you to write vanilla instructions. There is no runtime and practically no framework. Oth…

> There is no runtime and practically no framework As a fan of Svelte, I really wish people would stop repeating this. There _is_ a runtime in the form of repeating patterns of code, which are objectively less ideal than the not-so-revolutionary approach of just having a runtime. Newer libraries do have centralized runtimes (e.g. Solid.js) and perform better, so there's no real correlation between "no runtime" and ha…

> There _is_ a runtime in the form of repeating patterns of code

Obviously there has to be some running code at the end, and technically you are right, but I think you're splitting hairs and for a brief introduction it makes more sense to say that there is no runtime.

Also I think I implied your point with "Svelte is just a simple way for you to write vanilla instructions".

> Newer libraries do have centralized runtimes (e.g. Solid.js) and perform better, so there's no real correlation between "no runtime" and having best-in-class perf

I'm not sure about this point.

I do agree Solid is currently faster than Svelte, at least on synthetic benchmarks.

OTOH compilers can optimize hand written code which a runtime cannot do. We see this in assembly written by C compilers for example which have been optimized for decades and will beat the vast majority of hand written assembly. Svelte is very young and, while I could be wrong, I believe we will see performance improvements over the years. I also think this would be completely unnecessary.

> On the other hand, the question of how the Svelte repetition scales as an app grows is a constant worry that drives away would-be newcomers.

If you're doing a SPA this can be solved with code splitting which is trivial to implement [1]. If not then Svelte will ship comparatively less JS than any other framework that needs a runtime[2].

BTW, big fan of Mithril here, are you still working on it?

[1] https://github.com/PierBover/svelte-rollup-code-splitting-ex...

[2] https://krausest.github.io/js-framework-benchmark/current.ht...

Re: Second-Guessing the Modern Web

#380

Post by TeMPOraL » Mon, May 11, 2020, 2:43 PM UTC

mavhc wrote: post #357

TeMPOraL wrote: post #333

Earlier quoted context omitted.

Those crazy users who then cry, "what do you mean I've lost 10 years of e-mails forever, becuase my daugher commented with an emoji on a YouTube livestream, and Google decided to go nuclear everything associated with that account?". Cloud services aren't more reliable than owning your data. They're just unreliable in a different way. You need backups anyway.

That happens less often than people's computers dying. Which emoji did she use?

The green one.

I'm of course referring to the Markiplier drama of last year, where a streamer asked people to vote on his stream by typing in red/green emojis. This resulted in hundreds of people losing their Google accounts due to an oversensitive spam filter. The matter fortunately got sorted out (somewhat, not all accounts were unbanned), but essentially only because it involved a fairly well-known youtuber.

https://www.engadget.com/2019-11-10-youtube-reinstates-banne...?

And random automated bans (which happen on all big social networks) are only one fairly common failure mode of cloud services. Smaller services shut down or get acquired, taking your data with them, or they just shutter the products you depended on (and even if you can export data, there often isn't anything you can import that data back into). Governments may randomly make whole populations lose access to service (c.f. Adobe's Creative Suite and trade sanctions on Venezuela, earlier this year). And, of course, no Internet access = no access to service = no access to data.

In general, owning your data makes you vulnerable to physical world problems - floods, fires, etc. Using cloud services makes you vulnerable to relationships between you and third parties, as well as between these third parties themselves.