Hacker News new | ask | show | jobs
by smarkov 1254 days ago
> with no CI/build/deploy issues

I miss those days.

I think the amount of front end building we do for the web nowadays is absurd. We transpile everything - JS, CSS HTML, and then we bundle them in odd ways to circumvent all kinds of issues. The way we make webpages is so disconnected from the technologies that browsers offer us.

Makes you wonder when people are going to realize that we're way past serving static pages and don't need the next big front end tool, we just need a better way to run actual applications in the browser.
2 comments
oblio 1254 days ago
> we just need a better way to run actual applications in the browser.

That's not going to happen. It's been tried, and it's almost always proprietary.

So it isn't really adopted.

WASM might be "it", but in that case, you're still compiling/building stuff :-)

link
nawgz 1254 days ago
> The way we make webpages is so disconnected from the technologies that browsers offer us.

Can you say more about this? I don't really see how "actual applications" differ from a React app in a meaningful way; React apps almost always leverage the capabilities of of course HTML/CSS/JS, history, AJAX/HTTP, cookies, and so on. As the JS distributions evolve, the build systems do too in terms of output.

Maybe I misunderstand something, but in general the idea that just writing vanillaJS or some analogue would be sufficient to deliver the quality of apps enabled by frameworks (and talented devs) seems a bit naive to me.

link
smarkov 1254 days ago
> Can you say more about this? I don't really see how "actual applications" differ from a React app in a meaningful way;

React is everything the web (in its initial conception) was never meant to be.

HTML was meant to be used for static documents. CSS (single file, linked to by all documents) was meant to add styling to all those documents. JS was meant to add simple interactivity to documents. Navigating between documents reloads everything and no state is kept (other than user sessions of course). We broke every single one of those concepts and the way they were meant to be used.

Now, our HTML consists of a single index.html with a div#app and primarily content in the <head>. Elements are entirely generated by JS. Most of the time you just load a single big JS file that contains everything and navigating just replaces elements, state-wise you're still on the same document. We want all kinds of fancy CSS features that won't be implemented for another 25 years so instead we use transpilers. That is, if we don't include our CSS in the JS. Did I say JS? I meant JSX, because we don't even write HTML directly anymore. The point is, we don't use any of the 3 the way they were meant to be used.

We've built layers on top of layers of abstraction to be able to add a level of interactivity that was never meant to exist on the web. Instead of coming up with a new way of building actual applications that meet all our needs, we keep (poorly) patching old technology to get it to play nicely with our modern needs. It's a constant fight and a gigantic waste of everyone's time. We can do better.

link
graypegg 1254 days ago
Sometimes the best platform is the one you have though. It’s not conceptually good, but its ubiquity is good. Slowly we creep towards HTML/CSS/JS as solely a compile target haha.

Also, just because of tone-death in text, I’ll say I agree with you! The web as an application platform is a bodge. Humanity loves bodging though!

link
nawgz 1252 days ago
> HTML was meant to be used for static documents

So? What does that have to do with "technologies the browser offers us"? The browser now offers a thorough set of DOM bindings in JS, which is definitely not meant to be used for static documents. Quite the opposite.

> CSS (single file, linked to by all documents) was meant to add styling to all those documents.

That's still how it works?

> JS was meant to add simple interactivity to documents

Before the DOM, sure

> Navigating between documents reloads everything and no state is kept (other than user sessions of course)

Which was horrible UX

Everything you go on to say seems to be some puritanical bend on never evolving software. The platform and its usage have co-evolved, and now we have a complete app distribution platform where a 1MB bundle can deliver equivalent functionality to an app taking hundreds of megabytes on the phone platform, except this 1MB bundle can support screen sizes from the smallest phones to the largest desktops.

I genuinely don't understand what kind of complaint this is:

> We've built layers on top of layers of abstraction

Should we go back to writing Assembly? Wait, isn't this a higher level than machine code? Wait, isn't that still interpreted by the CPU into microcode? ...

> Instead of coming up with a new way of building actual applications

Honestly, I don't get it. We did come up with a way of building actual applications, it's called the browser, using HTML/CSS/JS. I don't care that some people write it in a file called .jsx or .tsx - is using TypeScript also offensive to you? - I still deliver a static HTML/CSS/JS bundle to users. That seems like the ultimate validation of the original concepts in those technologies, they are so expressive that we're able to circumvent the need to start from scratch yet again, instead evolving themselves to be a performant, compact app delivery platform.

> It's a constant fight and a gigantic waste of everyone's time

The gigantic waste of everyone's time is thinking that starting from scratch will solve more issues than it will introduce. Good luck writing a new platform that supports not only many classes of devices and small packages, but also doesn't kill accessibility features, screen readers, and billions of man-hours of development that still works today.

This is better than it was. Not sure what kind of person simultaneously argues "we can do better" and then rails against the evolution of usage of technologies that... made them better

link
graypegg 1252 days ago
> > HTML was meant to be used for static documents

> So? What does that have to do with "technologies the browser offers us"? The browser now offers a thorough set of DOM bindings in JS, which is definitely not meant to be used for static documents. Quite the opposite.

I think they mean that syntactically, HTML is best suited to static documents, since that was the original design consideration. While the DOM has had things added to it to make it work as a declaritive UI language, that doesn't change the fact that the HTML spec at it's core is very focused on information hierarchy, typography and print-style layouts.

--

> > CSS (single file, linked to by all documents) was meant to add styling to all those documents.

> That's still how it works?

Yep! <link rel="stylesheet" href="./style.css" /> on every document, and you just keep adding to that file. (Not advisable but possible)

--

I could totally see us building a BETTER target platform; imagine a declaritive UI language that allows binding nativly? No "JS Main Thread" blocking weirdness, and frameworks would all use it making views/templates/components intercompatible. HTML is a weak solution to the problems modern web development faces...

BUT it's also a globally available solution making the annoynaces that come along with it just acceptable enough that we'll take the extra step to emulate a better platform with frameworks. It's available everywhere, and global change is hard or even impossible. It's working with what we have and I think that's good. But pushing for something better is also good. :)

link