Earlier quoted context omitted.
So are you saying that reverse engineering javascript is easy? Or that it's easier than reverse engineering wasm? I don't know much about web assembly, but x86, which is much more complicated with thousands of instructions, has been successfully reverse engineered basically since forever. There are decompilers that can automatically reconstruct source code in C or C++ from a binary blob. Compared to javascript, the b…
But if the WASM was compiled from javascript or some other language that isn't very C-like then the de-compiled C or C++ code is going to be very difficult to follow. At the very least with obfuscated javascript you are going from js => js => js. Rather then from js => WASM => C++.
W3C recommends WebAssembly
201–210 of 350 posts
Re: W3C recommends WebAssembly
#202Earlier quoted context omitted.
Even if we don't lose the HTML-centered model, we are probably going to lose control of our browsers. Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser. The "inner browser" won't have content filtering, privacy controls, DOM inspector, or a Javascript debugger (for the Javascript engine running on the "inner browser") that you can inter…
Smart phone apps already do this.
All it will take is for ADK to a have button that produces a wasm version of your app.
Re: W3C recommends WebAssembly
#203Earlier quoted context omitted.
Even if we don't lose the HTML-centered model, we are probably going to lose control of our browsers. Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser. The "inner browser" won't have content filtering, privacy controls, DOM inspector, or a Javascript debugger (for the Javascript engine running on the "inner browser") that you can inter…
It makes no sense to me. You are saying, that instead a 5 kB webpage, you would load 50 MB code, which emulates a browser, just to show you the same webpage? Every webpage pays for the traffic in some way, and everybody tries to save web traffic as much as possible (optimizing images, videos, minifying JS, CSS ...). It makes no sense to expect, that websites would turn the opposite way just for fun. I would be very g…
Re: W3C recommends WebAssembly
#204Earlier quoted context omitted.
> Would it blow your mind if I told you that you can create a complex treeview without having to use third-party libraries No, not any more than C#'s giant standard library blows my mind. Keeping the web small is a strategic decision -- it may look like chaos, but it's really just that we realized that embracing 3rd-party libraries is a better architectural decision than polluting the core spec with features that wil…
I'd argue that the problem isn't so much backward compatibility than being opinionated vs not. Qt knows what it's doing, knows what it isn't doing and then from there defines the perimeter of its APIs. For better or worse the web never did that work, HTML+CSS+JS is meant to be both a way to make static websites, but also interactive e-shops, but also mail clients, but also videogames, but also ultra-heavy single-page…
Re: W3C recommends WebAssembly
#205Earlier quoted context omitted.
> Could we ever lose the HTML centered model? This is what people should be worried about, not replacing JS. It became a kind of popular hot-take for a while to say that separation of concerns was a mistake, and that's not how apps get built in the real world, and what we really need is a way to encapsulate all of our DOM and CSS in JS. We need to start pushing back against that idea and keep emphasizing that separat…
Frontend Engineer here. That “popular hot-take” is my career, and I happily combine HTML and CSS into my JS every day. React.js has been the most significant JavaScript library in the past decade. Over 50% of JS developers on the web are writing HTML inside JavaScript. In recent years, CSS-in-JS libraries like Styled-components are becoming standard. We’re killing HTML templates and writing JSX. We’re killing CSS cla…
Re: W3C recommends WebAssembly
#206Earlier quoted context omitted.
> Could we ever lose the HTML centered model? This is what people should be worried about, not replacing JS. It became a kind of popular hot-take for a while to say that separation of concerns was a mistake, and that's not how apps get built in the real world, and what we really need is a way to encapsulate all of our DOM and CSS in JS. We need to start pushing back against that idea and keep emphasizing that separat…
Frontend Engineer here. That “popular hot-take” is my career, and I happily combine HTML and CSS into my JS every day. React.js has been the most significant JavaScript library in the past decade. Over 50% of JS developers on the web are writing HTML inside JavaScript. In recent years, CSS-in-JS libraries like Styled-components are becoming standard. We’re killing HTML templates and writing JSX. We’re killing CSS cla…
I don't generally have a problem with this. I use JSX at work too. My take is it's just another templating system, I don't think it's special. I don't have anything against templating. To a certain extent, my point is that template systems are good -- put your two-way data bindings and special components in them.
When I write JSX though, I make sure it renders out as semantic HTML. If your approach to JSX is, "I'm going to write my render code in JS and output HTML", I don't have a problem with you, you're doing great. If your approach to JSX is, "my interface is just Javascript, so it's fine to spit out poorly organized divs that are absolute-positioned everywhere", then I think you've missed the point of HTML.
React isn't an antipattern. But React doesn't remove your need to think about the final HTML that your app is going to spit out. Apps like Youtube and Twitter are particularly bad at this -- Youtube's DOM is a horrifying mess, it's completely unreadable and way too difficult to work with or style. It's not because they're using a component system to build it, it's because they're fine treating the HTML as a non-readable render target. They don't care about HTML as a user interface.
The broad mistake people make on the web is to look at HTML and say, "because I can't build a scalable app on JQuery and hand-coded HTML, therefore HTML is bad." Google's hot-take with HTML custom components is not that you could put your template logic inside your other component logic -- it's that the HTML layer shouldn't matter at all and you should stop thinking about it.
Separation of concerns is for users, not for you. It's not about where you organize your logic, or even if you mix up your languages into the same file. It's about what gets spit out onto the final page.
> We’re killing CSS classes and building styled-components.
I would caution a bit against doing styles in JS -- not because adding a template layer or JS layer that generates CSS is bad, but because many codebases that I've worked with use CSS-in-JS as an excuse to rewrite basic CSS controls like hover effects in Javascript and inline the remaining styles. That doesn't mean you shouldn't do CSS in JS, it just means you should take the time to use a library that spits out actual CSS and that allows you to take advantage of native selectors and pseudo-elements. React does itself a disservice by using tutorials that teach people to apply styles directly to elements instead of pointing people towards any of the more decent companion libraries that will let you do styling correctly.
Unless your engineering team is the size of Facebook's and you can't communicate about your components at all, you probably should still be using classes. Of course that doesn't mean you can't use JS to restrict class scope or template that CSS. I personally tend to be more of a proponent of BEM than I am of JS styles, but I'm not going to fight someone over that.
Re: W3C recommends WebAssembly
#207Earlier quoted context omitted.
If you look at the history of the web it's clear that the tendency has always been towards "shinier things". This "historic separation" was the result of technical limitations, see how popular Flash used to be for instance. HTML and CSS standards were always at least 10 years too late. If you wanted something that looked modern you've always had to use browser-specific extensions, plugins or, at best, "beta" features…
The change in dev culture worries me more than the change in technology. At least Flash sites used to be considered bad taste. Dare to grumble about something unnecessarily requiring gratuitous JS now, and you'll get berated as an out-of-touch Luddite who needs to shut up and get with the times.
Re: W3C recommends WebAssembly
#208Earlier quoted context omitted.
> Indeed, HTML = World Wide Web The WWW is a network built on a set of protocols. HTML is a markup language that allows for (indeed, that is is designed to facilitate) embedding and linking binary and executable content, including javascript, flash, java, audio, video, as well as marking up text. HTML is one, but not the only, content-type which can be distributed across the WWW. This is fundamental to the design of…
Why do you find this stance ridiculous ? Yes, one could say that the Web has "jumped the shark" sometimes after 1997 (took some years), remember the mess when Flash and Java applets were everywhere ? (WebAssembly might be more sleek, but the issue is likely to be the same...) I guess that multimedia could be part of the Web, but support for basic features like audio/video search is (still!) sorely lacking... (Though…
I can guarantee that no one was looking at a Java applet or a Flash site in the 1990s and thinking "I don't know what this is, but it definitely isn't part of the World Wide Web."
>Yes, one could say that the Web has "jumped the shark" sometimes after 1997 (took some years), remember the mess when Flash and Java applets were everywhere ?
On the other hand, Flash allowed animators and game developers an outlet for creative expression and distribution and led to an explosion of content, and launch more than a few professional careers. And Java applets... existed.
At the very least, I think it's controversial to say the web jumped the shark at that point.
>you might have noticed that you hardly see search engines pulling up results for supposedly "Web"Sites like Facebook or Discord or Twitter ?
I do see those results in search engines. Visibility in a search engine is a result of SEO and those sites' indexing rules, it has nothing to do with whether or not a site is part of the web - if I can reach it in a browser, it's part of the web by definition.
Re: W3C recommends WebAssembly
#209Earlier quoted context omitted.
I'd argue that the problem isn't so much backward compatibility than being opinionated vs not. Qt knows what it's doing, knows what it isn't doing and then from there defines the perimeter of its APIs. For better or worse the web never did that work, HTML+CSS+JS is meant to be both a way to make static websites, but also interactive e-shops, but also mail clients, but also videogames, but also ultra-heavy single-page…
The fancy stuff can go live in apps, it has nothing to do in a browser designed for webpages first. I mean, just compare the GUIs of VLC and YouTube!
It shouldn't be necessary to toss out the cookie jar, the HTTP connection handler, the XSS protection just because one wants to do something a bit different with the final rendering stage.
Re: W3C recommends WebAssembly
#210Earlier quoted context omitted.
Frontend Engineer here. That “popular hot-take” is my career, and I happily combine HTML and CSS into my JS every day. React.js has been the most significant JavaScript library in the past decade. Over 50% of JS developers on the web are writing HTML inside JavaScript. In recent years, CSS-in-JS libraries like Styled-components are becoming standard. We’re killing HTML templates and writing JSX. We’re killing CSS cla…
As another react developer. The separation goes deeper than just having styles, logic and the dom in separate files. It's the underlying data structures that are important in the end. And in that regard react doesn't change the field. We still have the same essential structure and building blocks. Just a different way to reason and interact with it. Perhaps webassembly doesn't change this either?
I hate the sheer number of files people create in projects. The worst one I've seen is a ".types.ts" file. Everywhere.