loading...

re: The Future of "View Page Source" VIEW POST

FULL DISCUSSION
 

The browser application has become a compilation target. You are correct. I've worked with JS when jQuery was simply the best thing since sliced bread. I don't write JavaScript for work anymore, but do in personal projects and the ecosystem is dizzying. While I have my complaints, it's progress. I've opened "view source" maybe five times in the last five years because it is no longer approachable. I don't necessarily think this is a bad thing, though. Nobody really intends for source code to be read by the consumer of the end-product/service/client.

But let's step back for a moment -- despite this, JS is still many people's introduction to programming from a non-traditional CS background today, providing one of the tightest feedback loops there is -- write some code, refresh the browser, see something. There are more people learning JavaScript, HTML, CSS across the world than perhaps any other programming language. People don't learn JS starting with Node -- it's almost always from the browser first.

"View source" today is not meant for people to pop open and poke around anymore. Do this on Facebook and a scary warning pops up for those that aren't web devs. There is an argument to be made that perhaps view source shouldn't even be available -- because it's not like other UI clients like iOS or Android apps allow its users to do that.

From where I'm standing, JavaScript and browser-based development has more than a healthy dose of interest and people coming in despite the friction and dizzying array of constructs once one wants to actually get up to speed with modern JS development. Because of the influx of new developers, their voices almost drown out other ideas. SvelteJS is absolutely one of the simplest and fastest UI libraries out there, but people automatically side-step it because the React community is just outsized and smack down every opinion with disdain. Because people don't poke at new things with a healthy intrigue anymore, only few voices are heard. And everything that you've described simply falls by the wayside with newcomers, because it is just "accepted". They know no other way and probably don't even have anything else to compare it to if JS is the ecosystem they are first introduced to. It isn't until this same developer jumps into other languages and platforms and ask, "What's the build tool? What's the transpiler? What's the Webpack here? What's the package.json?" They are usually in for a surprise if stepping into something like Ruby, Elixir, Go, or Rust (if ever). The toolchain can be learned in a day and everything is typically bundled into a single utility (save for maybe Go) and things can be blazing fast with just as tight of a feedback loop, although not as animated as a browser can be.

But all-in-all, I think Web Assembly is paving a future where what is in the browser can be simple and approachable again -- treating it literally as a view layer. With Rust and WebAssembly, we can have our cake and eat it, too. It can write better JS and semantic HTML than we can: youtube.com/watch?v=ohuTy8MmbLc

 

So discounting the "dizzying ecosystem" of JavaScript tools and build systems, would you say that WebAssembly is the right direction for the Web, where the heavy lifting is done by "native" code, while the UI and view layer is managed by simple HTML and JS?

Once the browser support starts coming in, I'd say that's a sustainable future for the Web. Though, I can't help but feel strange about how far it is from its humble origins.

 

I think it’s one direction with some steam, but I hesitate to say that it is the right direction

Well, you see this idea of “humble origins” that you speak of while also true in my case is really a figment of our own imagination. Was this really the intent of its designers or even a goal? I’m not sure. I never looked that that history...

That said, though, I agree — once we’ve got all the browser support, it’s a sustainable future. I think we can finally get to semantic HTML without shoehorning application state into a document and we can again pop open the source and make sense of it again.

Code of Conduct Report abuse