Check Svelte out (https://svelte.technology/). From the docs: "... rather than interpreting your application code at run time, your app is converted into ideal JavaScript at build time. That means you don't pay the performance cost of the framework's abstractions, or incur a penalty when your app first loads."
Web frameworks are transforming from runtime libraries into optimizing compilers
41–50 of 231 posts
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#42> a small 40MB iOS app What a sad, sad world we find ourselves to live in.
Indeed, we no longer worry about food, safety and survival and instead our sadness is directed at irrelevant application binary file sizes.
It becomes relevant when one doesn't intentionally interpret it in the wrong level of Maslow's hierarchy.
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#43> a small 40MB iOS app What a sad, sad world we find ourselves to live in.
Indeed, we no longer worry about food, safety and survival and instead our sadness is directed at irrelevant application binary file sizes.
We can be sad at more than one thing at a time. I am not overly sad about binary file sizes myself, but I wouldn't say they are irrelevant just because other issues exist, and the original comment is just using a turn of phrase. I doubt they really think this is cause for great concern.
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#44Domain specific languages I suppose are the next cool aid. Or languages with a comprehensive macro system (like Elixir) can bridge the gap between these ways of thinking. This feels very frontend focused though - I'm wondering if there is a more holistic approach. I have an idea for a framework/project, that over web sockets, views the browser as a thin client for a server side representation; commands would be sent…
I made a proof of concept for such a framework. There are some really cool benefits (like automatic server side rendering, really small js bundle, all code on the backend etc.) but falls short for things that require immediate response, such as drag/drop, or text input.
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#45"The trend started by minifiers like UglifyJS and continued by transpilers like Babel will only accelerate." Those were predated by Closure Compiler, which was started with Gmail, and Closure Compiler in some ways still doesn't have an equal. Besides being a fully optimizing compiler, it also has a module system for code splitting, and optimization passes designed to move code at the method/property level from initia…
Those features are supported in Webpack and other bundlers. Code splitting: https://webpack.js.org/guides/code-splitting/ Tree shaking: https://webpack.js.org/guides/tree-shaking/
Only in a very primitive way.
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#46Earlier quoted context omitted.
Indeed, we no longer worry about food, safety and survival and instead our sadness is directed at irrelevant application binary file sizes.
We can be sad at more than one thing at a time. I am not overly sad about binary file sizes myself, but I wouldn't say they are irrelevant just because other issues exist, and the original comment is just using a turn of phrase. I doubt they really think this is cause for great concern.
>We can be sad at more than one thing at a time.
Only if it makes sense as a concern. Else we're just being grumpy.
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#47Earlier quoted context omitted.
I think the effort going into browsers is a double-edged sword. It's nice that we've got so much work going on, pushing new standards, etc. but it's also making browsers more bloated and making it less viable to bring out new browsers. As more stuff gets done in Javascript, and Javascript gains more APIs, browsers like Lynx, Dillo, Netsurf, and umpteen yet-to-be-written ones are becoming less able to browse the Web.…
While I agree with the overall sentiment, browsers like Dillon and Lynx don't even implement HTTP caching correctly (they cache everything regardless of the headers). JavaScript is not their biggest problem, as they can plug in one of the existing engines (in fact one of the links forks does just that).
> as they can plug in one of the existing engines
As someone who attempted this for Lynx back in the [~late 90s~] early 00s with the Mozilla JS engine of the time, no, they can't.
Lynx has no DOM. It parses and renders the HTML to a fixed textual pane without any intermediate format - even `document.write()` is nigh-on impossible to implement because it required keeping a copy of the HTML around, jiggering it with the output, reparsing, and going through the layout again. And that only covers the most trivial uses of `document.write()`.
To add Javascript to Lynx would require rewriting the entire internals of Lynx - not going to happen.
[Edited to correct the time period]
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#48I don't think so. Browsers will catch up with what developers want. We have seen that with ActiveX, Flash, Java applets, jQuery etc. Every time tech was needed because "The browser alone is not good enough" the browser became better and made the additional tech obsolete.
> the browser became better and made the additional tech obsolete.
And almost every time, a separate browser codebase died and a vendor switched to WebKit. Because with all this cruft, maintaining a browser codebase has become a nightmare only few can afford.
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#49Earlier quoted context omitted.
> Browsers will catch up with what developers want. Developers want everything from JavaScript to C++, Python and Haskell. There's no way a browser can specifically address all what developers want. Therefore browsers should become better virtual machines. Edit: yup, WASM is a good start.
Sounds like you need to read up just a little bit on Web Assembly which is compiled from anything including C, C++, Rust and just about any language. Including Python and others. Web Assembly will make syntax irrelevant for web scripting and JavaScript entirely optional depending on how much WebASM is allowed to access.
>Web Assembly will make syntax irrelevant for web scripting and JavaScript entirely optional
That's what many think, but that's not what WASM is for though. It's still a foreign world to the DOM, and not a first class citizen like JS.
It's more about driving canvas games or offloading some expensive computations than actually writing your app in WASM as opposed to JS.
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#50Domain specific languages I suppose are the next cool aid. Or languages with a comprehensive macro system (like Elixir) can bridge the gap between these ways of thinking. This feels very frontend focused though - I'm wondering if there is a more holistic approach. I have an idea for a framework/project, that over web sockets, views the browser as a thin client for a server side representation; commands would be sent…
Meteor is a little that way although it doesn't DOM diff on the server. It kind of diffs the Mongo database on the server and then updates mini Mongos in the clients where appropriate. Js in the clients then update the DOMs.