I'm a web designer 100% confident with my tech stack of choice, certain that the future is static and JS-powered and Serverless and PWA and AMP and GraphQL and (insert flashy buzzword here)
That was true, until I started questioning this vision.
Today I got a bit sad and lost about the future of the web... Everywhere I look there are plenty of hurdles and foul stuff just waiting around the corner to jump on me, my clients or their users, so I figured I'd raise this discussion here:
- The "traditional" web is slow, can be insecure and full of trashy stuff, of which WordPress, Wix and the likes are a big source
- A possible solution is AMP, but it's clearly Google's attempt to dominate the web even further
- Then we have the Javascript bloat provided by the whole framework tycoon
- There are big proponents of "let's talk about the javascript cost", like Addy Osmani, but I don't feel like there's any expressive movement to steer the web dev community farther from its current reliance on JS
- The amazing developer experience provided by Gatsby (which has been my tool of choice) is also helping to make this bloat a default on the web. Just look at their own website: "Fast in every way that matters" and, yet, it loads 6 megabytes of uncompressed Javascript in a single blog post. Hm... how fast 🤔
- Compiler frameworks like Svelte, Imba and Stencil attempt to reduce this bloat by reducing the number of abstractions in client-side runtime...
- And static site generators such as Hugo and Eleventy make it easier to build complex websites without the need of runtime JS...
- However, these abstractions pulls us farther from being able to just
view source, which, as Kyle Simpson rightly put, could be a downfall to the web as it would make it harder for new developers to get in. - And, yet, it's still impossible to do complex work that doesn't rely on any type of external tools other than browser-supported technology. I don't know what to do 😔
- Clients need to be able to edit content visually, and for that we need a CMS.
- This CMS can't inject the data directly in the HTML, there's no
<link rel="content" />we could use, so we need to either - Pull in the data client-side with Javascript and then render it, but... javascript bloat (and SEO, of course)
- Work with the data in the server at runtime, but... bad performance (and high costs / maintenance)
- Generate the website on build time, but... abstractions (and lock-in, might not be very future proof, etc.)
- And, honestly, the idea of just building
.html,.cssand (very few).jsfiles doesn't feel like a productive workflow. It might be that we became spoiled with so many tools, but going full vanilla truly can be a problem if working on big projects / with big teams.
So, yeah, I'm lost, please show me the way. Oh, I was super over simplistic with my approach to each of these topics, but even so I believe the main point hits home. If you want to evangelize your new gameChangingThing.js or fight me on my views, please don't comment below, this is supposed to be an open conversation about the future of the web and of our trade as developers 😉
Top comments (18)
I love the ideas you talked about with the solutions we are building for clients. I’ve also noticed the world of NPM and NodeJS over complicate websites we are building to the point at which if you build a website for a client using that tech, it will be out of date within 6 months to the point where source code is an entire rewrite to update functionality.
One way to solve this problem is build everything yourself. Not sure how practical that is for most businesses, but is the only way to guarantee the future of what you are building.
The npm fatigue is true hahaha
I feel like building for scratch is a solid option for teams building stuff for the long term, but if you want to hand your code after the service is over, this has some problems... But anywho, do you see any middle ground between this rapid cycle of npm packages and having to build everything from scratch, Joshua?
Strategy is different for every company. That’s why tools like WP are so widely used. To solve the problem you’re talking about, you need a platform to build on that delivers the abstraction you’re looking for. Headless CMSs seem to be middle compromise. It really depends on how much you want to build yourself.
It feels like we are in another pivotal time for web development. Static site generators that abstract JS libraries seem like a very postmodern solution to a rather fundamental problem. It’s easy to overarchitect the web. Browser API have come a long way and I think JS frameworks and libraries tend to over complicate things but can bring much needed software development paradigms to an application.
I’d suggest figuring out your ideal way of working or figuring out how you would architect a JS library that makes common web development tasks easier. Then see what JS library is closest and run with it.
You mentioned Stencil. I love Stencil.
Vanilla JS doesn’t prohibit apps from scaling. Lack of architectural design, software development paradigms or development style guide prohibit apps from scaling. An application could scale nicely with just HTML, CSS and JS.
When HTML and CSS modules land in all browsers it will make web development a lot easier with vanilla JS.
Thanks for the answer, Steve! Like Michael said in one of the comments below, your idea is to find what suits your way of working and then rocking with it, right? Will do, I've been rethinking React and part of it is due to the overarchitecting it relies on, like you said, so I might as well look somewhere else.
I've tried Stencil by building the Conduit "Real World" app, and I loved some of its idea, but I'm still not sold on it... However, I sure am interested in this future of vanilla web development 🙌
Have you considered Angular? The community is amazing and the architectural patterns you may be searching for have largely been solved by others. You can compile Angular components down to autonomous custom elements if you need to and developing an Angular app uses a lot of vanilla JS.
Let's first separate fundamentals from incidental complexity. You have to have:
~/public_html/?Beyond that, it depends heavily on what you are trying to accomplish. There are a lot of projects where writing HTML and CSS by hand is the simplest, most effective path. There are projects where building a system like React to handle multiple teams all putting stuff into the page makes sense, which is why Facebook built it. Part of a the maturation of the platform is a diversification of what it is used for. In the early days of computers, they were for calculation of ballistics and other numerical problems. As the field matured that has blossomed into the range we have today, and the tools have blossomed with it. We don't turn to MATLAB/Simulink to build Myst. We don't turn to HyperCard to model combustion. We don't write first person shooters in Perl and we don't rename a bunch of files according to some pattern in C++.
A few particulars:
Not really. Static site generators produce HTML like anything else. We used various forms of them back in the 1990's. View source flourished. JavaScript is the real worry here.
I think you may be overstating both of these. Any website that persists state changes to the server has to generate a view of the data in the server at runtime. You can generate it as a JSON blob and send it to the browser or as HTML directly and send it to the browser. You're still going to generate some text and send it. Bad performance here is a red herring. Yes, you can write an HTTP endpoint that takes tens of seconds to respond. You can also write one that will respond in a time negligible compared to the network latency. Likewise, abstractions? Future-proof? Lock-in? Look at all the JavaScript stuff you're talking about in your list.
I can say from experience that for many projects it is a very productive workflow, especially with web components to replace server side includes or other simple templating system. If your project's purpose it convey information, not to let someone edit state on remote machines, this is a great workflow for a dozen or fewer pages.
The conversation you want to have really needs to begin with what you are working on.
And perhaps the heavy JavaScript path isn't even the right direction. Go look at Seaside for a completely different, very productive approach to web development.
There will always be a tool(s) that excel at a certain job, and part of the nature of web development is that the best tools are somewhat situational/a moving target. I think you raise good questions, but I think we as devs have to make sure we dont get overwhelmed by the myriad of options, full stop. At least, that's the impression I get from your post.
You're absolutely right, Michael! It was a moment of despair and being overwhelmed, but we have to move on with our work as developers, choosing the best tools, as you said... However, I feel like the discussion on the future of the web is still quite relevante, because we often get trapped in our short-term challenges and leave the future planning for "industry experts".
I'm thinking if there isn't any sort of middle ground here 🤔
If you think you're lost(not a defeat). Just learn the best tool you can be productive. I don't really like the web we're facing today due to same problem trying to fix and creates another problem. Likewise, the job market is your go-to living and just prepare for the next tool to arrive(depending on the product they're trying to promote).
Just don't learn everything just because its the new thing. Rather wait for its job market, community and how companies will adopt it.
Yup, the job market does provide an awesome proxy for defining where to go next, but I'm not sure always choosing that is sustainable for the web in the long term... In fact, this pattern seems to repeat over and over again with capitalism: we create a strong economic incentive that drives tons of people to a certain activity, but eventually this becomes detrimental to the environment and/or our social structures.
Vince, if you were to point to where the job market for web dev is right now, where would it be? Probably around JS frameworks such as React, Vue and Angular, right? My problem is, even though I've specialized in React + Gatsby and this brought tons of economic benefits to my career, I don't think it's a healthy way forward for the web 😅
For me, I've never really invested on the mobile up until I found Flutter. Sure, I know android a little and my machine gave up due to bloated IDE. Flutter doesn't have a job market, but it gives me more in-depth and eager to learn more because of the adaptive language called Dart. Now I can transition from one language to another, if the syntax are familiar to begin with(C#,JavaScript,Java,TypeScript,Python,Go). In fact, I'd invest more time in learning and coding with Flutter not because of its new, because of developer experience.
I think React+Gatsby is totally fine depending on the client's needs. It's still a great market for creating headless CMS and good for freelancing.
There might be contenders like WordPress and the likes.
While I feel overwhelmed with React's documentation and overly used
this.state.myStateandthis.props.myPropsthing. I'm really eager to learn it, not that it values my time and the job market today(not declining, but rather having to manage npm dependencies.)For now, I've been using Nuxtjs for my own portfolio and my very first corporate job. I'm lucky that this kind of job exist in my country. Or I'll have to learn PHP frameworks and Django. Nothing's wrong with these frameworks, I just don't think its the right tech stack for me to put effort into it.
Just keep doing what you love. If in doubt, talk to the rubber ducky.
Some of your concerns focus on both back-end and front-end development. I think a big decision a developer should make in his career is whether he wants to dive into back or front-end, since they are both HUGE fields of knowledge. You can always be full-stack, but your time and energy are one, and you will split that between both and not get too deep in both. It seems however, that you also raise a philosophical discussion about which way the web should go, which is not related to a developer skillset, but to the future of the web overall.
I'm a enterprise WordPress developer. I specialized in building multi-million dollar websites in WordPress. Yes, it's possible, even with WordPress. If WordPress can do it, think about other tools such as Laravel, NodeJs, Python, Spring, C#, Go, etc - I think that the software field is reaching a minimal level of maturity. Tests are starting to become the norm. Software architecture is starting to make sense as a business point of view for companies, and we have a great deal of things going on, and some old developers with lots of experience to share their experiences of a lifetime, each day more experienced developers arrive with accumulated experiences of past ones, and so we go.
Hahahha I didn't mean to say WordPress can't do amazing stuff 🤣 Just to clarify, I feel like it's easier to create bad performing websites with WP, but it's also easier to create websites in general, so I don't devalue its strength and relevance!
About specializing and the field's maturity, I 100% agree with you, and we sure have tons of things to rejoice for - we've come a long way! However, like you said, what's bothering me the most is this philosophical discussion about the future of the web: are we excluding devs and users and risking the openness of the web with some of our current set of choices?
Wouldn't hurt loooking into WebComponents. I created an GitHub org specifically for devs looking to build/use vanilla WebComponents.
That means: native support; no unnecessary abstractions; ES for everything; view source just works; minimal or no build tooling necessary. They also work with most/all frameworks.
For the element you mentioned, there's a WC called .
Here's the link:
github.com/vanillawc
I understand the feeling. I think it becomes even more obvious when you try to teach someone web development. If it were 2012 I would hand them Ruby on Rails and heavy handed server side rendering would be assumed without question. If it were 2015 I would hand them some pick of equally heavy handed client side rendering JavaScript framework.
But what about in 2019? It took me quite some time to come to the decisions I have come to, but I feel like I again have a defacto answer like I did in those previous years.
Of course there are many other variations to this, but this is how I have been able to create scalable, maximally performant web apps that fully utilize the web platform while at the same time removing the bloat.
Different projects require different stacks. There is no one perfect stack. There are online-shops, blogs, social-media-platforms, marketing-pages, web-apps (like game-editors, graphics-software), news-sites, gallery-sites and so on, which all require their own solutions and approaches. That's why I don't think it makes sense to define "my" stack on spec.
Other than that I do hope that fewer external tooling will be needed in future, and we can use more native things like web-components and JS-Modules.
I see a huge part of the problem coming from a culture of rapidity around new tech adoption. Most craft oriented occupations are able to sit on a very stable base of technique, however the environment and culture among software devs seems to be constant wheel re-invention. This is due in large part to a very real market for novel meta-solutions: a market that is made relevant through the articulation of problems that, while real, are inflated to hype a new product. Enter Twitter and the blogosphere and you have ricochet engine that crowns rising stars and declares viable technology obsolete at a breathless pace.
In many ways we are falling victim to a postmodernist ideology where most of our internally facing energies are dedicating to dismantling and critiquing the existing paradigms. I would challenge that the solution here is to return to the kitsch classics, to exercise the skills we know and love, and to find joy in ancestral craftsmanship (vanilla JS?) rather than cutting our teeth on the newest thing and getting lost in a forest of meta-solutions.
Which is also to say, Ruby on Rails isn't dead like Nietzsche's God.