DEV Community

Cover image for What is the next big thing in frontend development?

What is the next big thing in frontend development?

stereobooster on September 13, 2018

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 ...
Collapse
 
tux0r profile image
tux0r

WebAssembly, hopefully.

Collapse
 
jacksonelfers profile image
Jackson Elfers

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. 😁

Collapse
 
johannesvollmer profile image
Johannes Vollmer

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.

Thread Thread
 
jacksonelfers profile image
Jackson Elfers

That'd be neat, the future sounds bright.

Collapse
 
stereobooster profile image
stereobooster

Any specific use case on your mind or generally?

Collapse
 
tux0r profile image
tux0r

Generally, it enables developers to write more front-end code in languages which are worth a second look. The current limitation to JavaScript is a sick joke. WebAssembly lacks native DOM support yet (at least without external libraries), but I seriously look forward to the day which lets me process button clicks in my browser with C code. It will be much easier to read and write and it will be incredibly fast.

Thread Thread
 
stereobooster profile image
stereobooster

There are gazillion languages which compile down to JS. Like Elm, Kotlin, PureScript. I do not see any innovation with WebAssembly here. There are for sure use cases for WebAssembly, like performant code for games (WebGL) maybe something else...

Thread Thread
 
tux0r profile image
tux0r

There is a difference between "writing code that will be JS" and "writing code that will be bytecode".

Thread Thread
 
rhymes profile image
rhymes

Well... Chrome's V8 JIT compiles JavaScript to machine code.

So you can write code that will be auto translated to JS that will be auto translated to machine code :D

Thread Thread
 
tux0r profile image
tux0r

But you can't write it in C!

Thread Thread
 
rhymes profile image
rhymes

Why do you need C to develop a frontend?

Have you seen the proof of concept Quake js ?

Thread Thread
 
tux0r profile image
tux0r

Of course I have.

Well, if I "have" to write client-side code, I want to have a strongly typed, blazing fast language for that.

Thread Thread
 
stereobooster profile image
stereobooster

ReasonML it is. But it is a bit raw (not ready for production) for my taste

Thread Thread
 
rhymes profile image
rhymes

But there already are strongly typed languages you can use to write frontend code and V8 (and other VMs are more or less on par) is fast.

You just need to give them a try instead of waiting for the "perfect" solution ;-)

Thread Thread
 
tux0r profile image
tux0r

I am evaluating Elm (which is not strongly typed AFAICS) as a JavaScript compiler, to be honest...

Thread Thread
 
stereobooster profile image
stereobooster • Edited

Strongly typed is ambigious term. Elm is statically typed and from ML family, so it most likely sound system (haven't seen formal proof).

Thread Thread
 
tux0r profile image
tux0r

Elm solves other problems than C, but - as of today - it is one of the least painful options to write client-side code.

Thread Thread
 
caseycole589 profile image
Casey Cole

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.

Thread Thread
 
moreurgentjest profile image
more-urgent-jest

what about elixir and phoenix? they claim some impressive performance.

Thread Thread
 
rhymes profile image
rhymes

@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...

Collapse
 
avalander profile image
Avalander

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.

body {
    color: #111;
    background: #fff;
}

body:dark {
    color: #eee;
    background: #333;
}

And then the browser would use the styles with :dark when the user has the dark mode enabled, but they would get a basic default dark theme even if the CSS doesn't provide any :dark configuration.

Collapse
 
niorad profile image
Antonio Radovcic

Seems like it's on the way twitter.com/keithamus/status/10075...

Collapse
 
yaser profile image
Yaser Al-Najjar

I dream about a replacement for HTML CSS JS all together, they just have lots of crap for the sake of compatibility... I hope one day we will have clean version of all these langs once and for all.

Collapse
 
stereobooster profile image
stereobooster

Try Elm or react-native-web

Collapse
 
gdotdesign profile image
Szikszai Gusztáv

Mint is like that ;)

Collapse
 
yaser profile image
Yaser Al-Najjar

Seems really nice... hope they reach a mature stage !

Collapse
 
johncarroll profile image
John Carroll • Edited

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.

Collapse
 
stereobooster profile image
stereobooster • Edited

Last time I checked this subject, the issue was with migrations. Did they already invent migrations for GraphQL?

Collapse
 
johncarroll profile image
John Carroll

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).

Collapse
 
ben profile image
Ben Halpern

I'm not sure whether I love or hate fully automatic code splitting.

I definitely see the edge being more and more powerful and custom, along with service workers.

Where code runs will be more and more important in this sense.

Collapse
 
stereobooster profile image
stereobooster

With suspense it will be seamless, you can split at any point and it will work. And bundler will decide how to pack modules together. And you can use github.com/guess-js/guess, to predict what to prefetch. It's like a magic

Collapse
 
ben profile image
Ben Halpern

Wow, that is incredibly cool.

Collapse
 
sergiodxa profile image
Sergio Daniel Xalambrí

fully automatic code splitting

That sounds a lot like [Require.js]requirejs.org), if you are loading all async then you will made the initial load slower.

But definitely having code splitting easier to do is awesome, if you can just add a single line and create a new splitting point that's is definitely useful.

Collapse
 
rhymes profile image
rhymes

HTTP/2 everywhere

Collapse
 
bgadrian profile image
Adrian B.G.

Probably someone will reinvent splitting the files, again, and in 5yrs a new webpack to glue them together again.

Meanwhile
My fav is CloudFlare Edge workers, they are a start to a new serverless revolution, but for front-end. I think more use cases will be found, for networking and backend services, and soon all CDN's providers will support this feature.

Modules in browsers - combined with TypeScript maybe the JS code will not look so bad.
PWA - after Apple joins the board, and hopefully market stores will have PWA apps too, it will open a new market.
WebAssembly ...

I hope for a Flutter web, Dart as a JS alternative sounds great.

Collapse
 
stereobooster profile image
stereobooster • Edited

What so special about "Modules in browsers - combined with TypeScript"? I mean I'm excited about each one standalone, but is there any additional benefit comes from the combo

PWA - after Apple joins

Yes waiting for it. They are polishing it

I hope for a Flutter web, Dart as a JS alternative sounds great.

Anything specific got you excited

Collapse
 
yawaramin profile image
Yawar Amin

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...

Collapse
 
niorad profile image
Antonio Radovcic

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.

Collapse
 
niorad profile image
Antonio Radovcic

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/

Collapse
 
rhymes profile image
rhymes

Frameworks based on progressive enhancement and not SPAs by default.

I think I'll take a look at Stimulus.js at some point...

Collapse
 
fnh profile image
Fabian Holzer

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.

Collapse
 
marvindanig profile image
Marvin Danig

Pure JavaScript apps -- lightweight, no frameworks or libraries.

Collapse
 
stereobooster profile image
stereobooster

Can you explain more? What so exciting about that? (or is it a response to another comment; seems not)

Collapse
 
notriddle profile image
Michael "notriddle" Howell • Edited

Not Marvin, but I can think of two reasons:

  1. The Web specs are a lot more stable than any libraries. Most of what's in the browser platform now will still be there ten years from now.

  2. If it's already in the browser, then it doesn't need to be downloaded, and it can be optimised for speed instead of optimised for size.

Collapse
 
jacksonelfers profile image
Jackson Elfers

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.

Collapse
 
stereobooster profile image
stereobooster