Photo by Joshua Earle on Unsplash
I had some thoughts about this post quite some time but wasn't sure how to frame it. This tweet helped me
What could we take away from frontend development that would make you more happy?08:56 AM - 13 Sep 2018
Subseconds build time
Did you see OCaml (you may know it as ResonML or BuckleScript) compiler in action? It caches everything as binary, so consequent builds are like 20 milliseconds. This is totally astonishing. Can not wait to see something like this for JS.
Maybe https://pax.js.org/? Who knows...
Automatic code splitting
The big experiment we're going to run in Parcel 2 is giving you no power to manually define your code splitting. You just write your code.
Instead the bundler will make all the decisions for you through a plugin system.
We'll see if the community can make computers beat humans.17:44 PM - 06 Jul 2018
This will pair nicely with React Suspense
@wycats @TheLarkInn @slightlylate @AdamRackis @sincerely_tegan This means that you can code split more at any point in time — for example to load ModalHeader — without worrying about changing design. You already have a Placeholder. It will wait for both ModalHeader and Autocomplete as it tries to render Modal.01:55 AM - 13 Sep 2018
Per browser builds
@sitnikcode started this crusade called browserslist (correct me if I'm wrong). Imagine you specify which browser you want to support and compiler (transpiler) will provide builds for each browser in the list with all required polyfills with all required changes to CSS and you can use small script in Lambda@Edge or Cloudflare-Worker to serve appropriate assets at the edge of CDN. Or compiler will fail if your code is not compilable (transpilable) for given browsers.
Also, it would be nice if it would compile it down to ES6
Rich Harris@rich_harris
Explanation: ESM lets us ship a lot less code (switching from webpack to Rollup reduced JS payload by **25%**), and 70% of users can use modules (including dynamic import()) natively according to caniuse. For the remaining 30% we're using Shimport — github.com/Rich-Harris/sh…15:58 PM - 08 Sep 2018
For the reference, here is how builds per browse can look like preact-hn webpack config
What do you dream about?
What is the most expected thing for you?
Latest comments (39)
We're always beating around the JavaScript bush unfortunately. That would really be something to run any language you want. Still need a way to interface with the DOM, haven't heard if WebAssembly can do that yet. 😁
Well, not necessarily. Using WebAssembly, you could use any UI library you want, if it runs on OpenGL, because WebAssembly can access WebGL already. This means that the DOM may finally be replaced by something that was made for interactive graphics from the ground up, and not in retrospective.
That'd be neat, the future sounds bright.
We all tend to beat around the javascript bush it seems. I'd dream of a day when we could get past it completely instead of using it as a build target. Like being able to build binaries that could run in a vm on the client's machine.
Webapps and sites with dynamic features almost totally driven by the backend and a websocket connection, with minimal JavaScript. Think React but running on the server. shift.infinite.red/phoenixs-livevi...
Two more ideas (React related):
A stricter separation of sites and apps.
Usage of less JS on websites, and if necessary, by progressive enhancement, so the pages work fine without it. Make the client work as little as possible. It's the most inclusive thing to do.
All while enabling a broader choice of technologies for more interactive non-vital web-applications and games, which I guess WASM is heading to. So Flash I guess, just not so battery-hungry and more secure.
Oh and while we're in this mess, I'd love some faster build times. I don't know what my webpack does for 10 seconds every time I change a comma. I can't wait until I don't have to support non ES6-Browsers and can develop with native modules. All the Webpack/Babel-Stuff gone \o/
The web components APIs seem to have stabilized and are deployed in most of the evergreen browsers (Edge seems also to be commited, but they don't act as if it were in a hurry) - a sound and stable basis for framework-agnostic UI widgets is overdue.
This is more of a full-stack response, but I'm very much looking forward to the time when GraphQL-as-a-service matures and you can code a SPA without ever configuring a database or a server.
At the moment, you can already do this in limited cases (AWS AppSync, Prisma, Hasura), but all the services have some glaring weak spots around relations. Somewhat surprisingly, the best one I've found is neo4j-graphql, which is only held back by a few bugs and the need to manage your own neo4j instance. Still, the ability to have a graphql api generated for you if you just define the models is very nice.
Last time I checked this subject, the issue was with migrations. Did they already invent migrations for GraphQL?
If you're referring to migrations of the database, one of Hasura's touted features is its "rails like" migration system. In neo4j-graphql's case, neo4j is schema-optional so migration's are generally unnecessary. I think the same applies to AppSync backed by DynamoDB. Prisma seems to have the most attention (over 10,000 github stars), but looking at the various options, it seems the least mature by a fair margin (not sure if I'm missing something or if they just do a better job marketing).
If you're referring to migrating a graphql api itself, I would argue that this is, inherently, not an issue as the structure of the spec makes API changes straightforward (just create a new field and mark the old one as deprecated).
I love javascript, but there have been so many times I wanted to have c to write some custom performant code hacks. I could care less about the types. Having pointers however and not dealing with all these deep cloning hacks and different things would be amazing. Plus would be able to roll my own data structures that are way better that whats built in.
what about elixir and phoenix? they claim some impressive performance.
@moreurgentjest well, you can't use them on the frontend. The browsers only understand JavaScript. You might be able to compile some Elixir to WebAssembly but I'm not sure...
BTW Phoenix is a server side framework...
HTTP/2 everywhere
I dream of browsers that have a setting to browse in "dark mode", i.e., if the user chooses so, the browser would provide by default dark background colours and white text colours for all websites. And CSS selectors that make it easy for web developers to configure the colours for dark and light modes.
Right now, it's up to every site to provide a dark theme, most don't bother, it's not straightforward to implement both, a light and a dark theme (even though CSS variables make it easier nowadays), and many times when the website provides a dark theme and the user selects it, the choice is stored in a cookie, which is far from ideal if you set your browser to remove all cookies on exit.
What I dream is that my browser has a setting that I can enable and will present all websites with a dark theme. The websites could use CSS to override the defaults for the dark mode, with something like this.
And then the browser would use the styles with
:darkwhen the user has the dark mode enabled, but they would get a basic default dark theme even if the CSS doesn't provide any:darkconfiguration.Seems like it's on the way twitter.com/keithamus/status/10075...