Domain 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…
Web frameworks are transforming from runtime libraries into optimizing compilers
51–60 of 231 posts
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#52Domain 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…
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#53Domain 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…
It can already do this for some kinds of diffs, but it doesn't have a full VDOM yet. It basically allows you to build interactive pages without writing any javascript.
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#54Domain 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…
To achieve similar results, you could granularly partition the build so that scripts are lazy loaded as needed. This would be like sending diffs, except only once since the client can reuse them.
Having a server manage the DOM state of every client, and maintaining sockets between them, seems like a complex apparatus.
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#55"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/
It turns out that it basically supported "skip loading of unnecessary ES6 modules", so kind of like a "warn: unused import", but turned into a silence and no-op.
Now with Uglify getting the "pure" annotation, and libraries sprinkling that onto their code, it'll help a bit.
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#56Domain 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…
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#57OT, but this jumped out to me: > In the same way that a compiled Android binary bears little resemblance to the original Java source code From what I recall, Java binaries actually look a lot like their source code. They're not human-readable of course, but you can decompile them very easily and get fairly good code back out. This made Minecraft an easy game to mod: just decompile a class, change a line or two, recom…
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#58OT, but this jumped out to me: > In the same way that a compiled Android binary bears little resemblance to the original Java source code From what I recall, Java binaries actually look a lot like their source code. They're not human-readable of course, but you can decompile them very easily and get fairly good code back out. This made Minecraft an easy game to mod: just decompile a class, change a line or two, recom…
Many companies make use of bytecode obfuscators to make it harder to translate back.
In Adroid not only is obfuscation part of the build process (ProGuard), there is the additional step of converting from Java bytecodes into DalvikVM bytecodes.
So if you only have DalvikVM bytecodes, you might translate to something back that looks like Java, but it won't be the original code.
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#59OT, but this jumped out to me: > In the same way that a compiled Android binary bears little resemblance to the original Java source code From what I recall, Java binaries actually look a lot like their source code. They're not human-readable of course, but you can decompile them very easily and get fairly good code back out. This made Minecraft an easy game to mod: just decompile a class, change a line or two, recom…
Not really. The bytecode format (.dex) is different, but it's straightforward to convert dex files back to jar files, and then decompile the jar and get readable Java source.
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#60Domain 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…
Like an X Server for the DOM? While interesting, that means that every communication would need to be tranfered to the server and there'd be no instant one-frame actions. That fits a limited set of UIs. And would lag with substantial network latency