I was asked to do a little session on this the other day. I’d say I’m underqualified to answer the question, as is any single person. If you really needed hard answers to this question, you’d probably look to aggregate data of survey results from lots of developers.
I am a little qualified though. Aside from running this site which requires me to think about front end development every day and exposes me to lots of conversations about front end development, I am an active developer myself. I work on CodePen, which is quite a hive of front end developers. I also talk about it every week on ShopTalk Show with a wide variety of guests, and I get to travel all around going to conferences largely focused on front end development.
So let me take a stab at it.
- This is non-comprehensive
- These are just loose guesses
- I’m just one dude
User expectations on the rise.
This sets the stage:
What websites are being asked to do is rising. Developers are being asked to build very complicated things very quickly and have them work very well and very fast.
As fabulous as jQuery was for us, it’s over for new development. And I don’t just mean ES6+ has us covered now, but that’s true. We got ourselves into trouble by working with the DOM too directly and treating it like like a state store. As I opened with, user expectations, and thus complexity, are on the rise. We need to manage that complexity.
State is the big concept, as we talked about. Websites will be built by thinking of what state needs to be managed, then building the right stores for that state.
The new frameworks are here. Ember, React, Vue, Angular, Svelte, whatever. They accommodate the idea of working with state, components, and handling the DOM for us.
Now they can compete on speed, features, and API niceity.
TypeScript also seems like a long-term winner because it can work with whatever and brings stability and a better editor experience for developers.
We’re not building pages, we’re building systems.
Style guides. Design systems. Pattern libraries. These things are becoming a standard part of the process for web projects. They will probably become the main deliverable. A system can build whatever is needed. The concept of “pages” is going away. Components are pieced together to build what users see. That piecing together can be done by UX folks, interaction designers, even marketing.
The line between native and web is blurring.
Which is better, Sketch or Figma? We judge them by their features, not by the fact that one is a native app and one is a web app. Should I use the Slack or TweetDeck native app, or just open a tab? It’s identical either way. Sometimes a web app is so good, I wish it was native just so it could be an icon in my dock and have persistent login, so I use things like Mailplane for Gmail and Paws for Trello.
I regularly use apps that seem like they would need to be native apps, but turn to be just as good or better on the web. Just looking at audio/video apps, Skype has a full-featured app, Lightstream is a full-on livestreaming studio, and Zencaster can record multi-track high-quality audio. All of those are right in the browser.
Those are just examples of doing a good job on the web. Web technology itself is stepping up hugely here as well. Service workers give us important things like offline ability and push notifications. Web Audio API. Web Payments API. The web should become the dominant platform for building apps.
Users will use things that are good, and not consider or care how it was built.
URLs are still a killer feature.
The web really got this one right. Having a universal way to jump right to looking at a specific thing is incredible. URLs make search engines possible, potentially one of the most important human innovations ever. URLs makes sharing and bookmarking possible. URLs are a level playing field for marketing. Anybody can visit a URL, there is no gatekeeper.
Performance is a key player.
Tolerance for poorly performing websites is going to go down. Everyone will expect everything to be near-instant. Sites that aren’t will be embarrassing.
CSS will get much more modular.
When we write styles, we will always make a choice. Is this a global style? Am I, on purpose, leaking this style across the entire site? Or, am I writing CSS that is specific to this component? CSS will be split in half between these two. Component-specific styles will be scoped and bundled with the component and used as needed.
CSS preprocessing will slowly fade away.
Many of the killer features of preprocessors have already made it into CSS (variables), or can be handled better by more advanced build processes (imports). The tools that we’ll ultimately use to modularize and scope our CSS are still, in a sense, CSS preprocessors, so they may take over the job of whatever is left of preprocessing necessity. Of the standard set of current preprocessors, I would think the main one we will miss is mixins. If native CSS stepped up to implement mixins (maybe @apply) and extends (maybe @extend), that would quicken the deprecation of today’s crop of preprocessors.
Being good at HTML and CSS remains vital.
The way HTML is constructed and how it ends up in the DOM will continue to change. But you’ll still need to know what good HTML looks like. You’ll need to know how to structure HTML in such a way that is useful for you, accessible for users, and accomodating to styling.
The way CSS lands in the browser and how it is applied will continue to change, but you’ll still need to how to use it. You’ll need to know how to accomplish layouts, manage spacing, adjust typography, and be tasteful, as we always have.
Build processes will get competitive.
Because performance matters so much and there is so much opportunity to get clever with performance, we’ll see innovation in getting our code bases to production. Tools like webpack (tree shaking, code splitting) are already doing a lot here, but there is plenty of room to let automated tools work magic on how our code ultimately gets shipped to browsers. Optimizing first payloads. Shipping assets in order of how critical they are. Deciding what gets sent where and how. Shipping nothing whatsoever that isn’t used.
As the web platform evolves (e.g. Client Hints), build processes will adjust and best practices will evolve with it, like they always have.
The concept of “pages” is going away.
then you said, re: URLs:
Having a universal way to jump right to looking at a specific thing is incredible.
if pages are going away we jump into what?
Some composition of components. If you want to call that a “page”, fine, but I think you know what I mean. Any given view isn’t some locked in place photoshop comp brought to the web (and billed that way) so much anymore, especially looking forward.
Extending this idea a bit, you can see how URL could become an identifier for state. If state defines the composition of components and URLs, on principle, have to point us to a specific piece of information.
In abstraction, you may refer to it as “node” (as per Elements of UX by JJG) or “view”.
I believe the fundamental goal of the web is to share information.
I find that people in their phones mostly consume the information ( other than sharing pictures and small comments )
People at their desk mostly create content.
Depending your context you may change your terminology between pages and views.
Still by definition a page is searchable whereas searching a view makes no sense. Hence the HTML/CSS code that you tend to produce for each is different.
I think most of the points you mentioned above apply to web applications.
You jump to a particular state of the experience. Should it be a static page-like interface or a state of an on-line application. The point is you do not bookmark a thing (=== page), you bookmark information (=== state) you want to recreate in your browser later.
We will jump into a resource. The resource does not have to be a page. I guess that is what it means. :)
I think Chris is talking about a RESTful URL structure where the state of a system is represented in the URL. That’s actually a very good practise.
Check out https://www.slideshare.net/landlessness/teach-a-dog-to-rest for some very interesting insights and heuristics.
goot point! thanks for the tips
The “systems” obsession hurts a lot of projects / people, I think. It’s fun to play with toys but at some point you have to be realistic about what you’re shipping.
If you’re building one viewable web page you probably don’t need a system. You probably need an HTML file and a CSS file.
I think the point is you shouldn’t build a system every time you build a page. Thats like reinventing the wheel every time you want to build a bike.
The ‘systems’ should be there to be used everything you need to ship one viewable web page and for however many times you or someone else re-ships that webpage with amends, changes, updates etc.
It is the ultimate democratisation of the web for everyone and has been happening for years (see every CMS, GUI or site builder ever).
In much the way Squarespace and similar companies are managing the design and development of basic websites through templating, there will be new products that do it for more complex Saas products. I think we are headed to a future where there are designers and UI engineers that work in a GUI and software engineers who build the things that build the things.
So I guess I disagree with the conclusion that HTML and CSS knowledge will be vital (thinking in the very long term) but design sense will be. There will probably be less need for hybrid designer/devs as there will be less need for that type of skillset as the UI layer gets abstracted. Engineers will have to be more specialized to understand complexities of working on things like AI and massive interconnected infrastructures at scale.
“User expectations on the rise.”, and
“What websites are being asked to do is rising. Developers are being asked to build very complicated things very quickly and have them work very well and very fast.”
I don’t think users are asking for all this. Clients might think users what script-heavy multi-function “systems” but I’m skeptical this is based on empirical evidence.
I just want to read a news story or look up some info. I don’t want slick fly-out menus, shape-shifting video windows, and a several dozen script-based tracking widgets. I bet people do.
Gah! I meant “I bet FEW people do.”
You’re thinking of the wrong things.
Years ago, if looking at a site to buy concert tickets, for example, you might find info to call into the box office. Now, however, you expect to see seating charts, real-time data about what seats are available, and be able to check out on the web site.
Years ago, your bank might let you log in and see your balance, but now you want to search through the items and filter by date, or do immediate balance transfers between your savings & checking account, order a new debit card, chat in real time with someone who can tell you why a give charge was denied, etc.
That’s the kind of complexity Chris was thinking of, I imagine. And it’s not just the UI that gets complex, but all of the back-end services and data that’s needed to even power such things.
That’s a fair point provided that the context is limited to informational websites.
The growth of application development on the web is, I think, what Chris is mostly talking about here — not just UI gimmicks.
The desire to incorporate user-generated content is growing, and the ability to use the front-end of the stack to completely power sophisticated PWAs is an approach that is growing in popularity.
People, whether admitting it or not, expect these things. People expect instant loading. People expect applications to behave a specific way. That is real data. That is real evidence. Conversions increase (or decrease) based on the speed of your website alone. UI/UX becomes more and more important. YOU may want to just read a news story but most people want more than that. They want real time. They want AR/VR in the browser. They want fast and instant. If you don’t think that’s the case, you have researched the topic enough.
“As fabulous as jQuery was for us, it’s over for new development.”
jQuery may have been more popular than it deserved to be or has been used when it wasn’t the best tool, but that doesn’t mean it will or should be “over”. As you said at the start, data is always better.
There’s definitely a decline from it’s early dominance, but my interpretation is the future will be a mix of frameworks/libraries. I think jQuery will have a place at that table, and that’s not a bad thing.
As much as I love jQuery, what Chris is saying is that the future involves adopting development patterns that are fundamentally incompatible with jQuery.
jQuery is like a trust old VCR: it might still be the best VCR money can buy, but these days people use Blurays. And even the best VCR can’t play those. (note: this analogy may be lost on people too young to remember VCRs… or jQuery ;)
“jQuery is like a trust old VCR: it might still be the best VCR money can buy, but these days people use Blurays.”
According to google trends and SO insights, jQuery is still currently very dominant. I don’t think the suggestion that jQuery will be as comparable in size to as vue or ember in 10 years time is that risky of a statement. If anything, it’s more optimistic of vue and ember than it is of jQuery. Outside of conference and podcasts circles, great things are still being made with jQuery.
Also, I haven’t used a Bluray in nearly 10 years, streaming might be a better metaphor at this point ;)
You’re spot-on when it comes to URLs.
And that’s one of the (several) reasons I find things like Google AMP so frustrating and regressive. In the pursuit of a worthy goal, they’re breaking things that work already — and with my tinfoil hat on, it looks transparently like it’s being motivated by wanting to more thoroughly control access to and flow within the web.
No gatekeepers FTW. URLs4eva!
Chris, I know you’re just one dude: but I think you’re absolutely right. Especially about user expectations, state and modularity.
I’m curious if you’re worried about React, Vue, etc. becoming one of those things 10 years later we regret we built on?
…and I say that as someone who is really enjoying working with those systems.
Like in the sense of “Resilient Web Design” ala Jermey Keith?
I sorta doubt it. It’s forcing us to think and work in JSON-based state, which it seems to me should last. It also encourages getting that data from API’s, which also feels like a good plan that should last.
React, Vue, and the likes are only a fast entry into what web development should become natively even without frameworks. With the shadow dom and every part of web components properly implemented on the web platform you can say those systems are the future of web development.
I think it’s important to distinguish between building web apps and web sites. Obviously there’s a lot of overlap between the two but if you’re building marketing sites for companies then your toolset becomes much smaller. For example, build tools and preprocessors are still very important and useful but things like state management become less of a priority, if not completely unnecessary in many cases.
It seems like most of the innovation is driven by web app developers (which is great) while web site developers need to pick and choose any new technologies and methodologies more carefully so that they don’t end up with an over-engineered final product.
The argument that “over engineering” is bad just doesn’t fly with me. If “over engineering” a project takes me 2 hours, and provides me with so many nice features (that over time speed up development), why not over engineer?
Once you have learned to work in React et al. and learn how webpack works, implementing the toolchain becomes trivial.
So I say continue to over engineer.
But over-engineering will never just cost you two hours. You’ll need the initial time to get everything set up (the original stuff that makes it possible to do things in just two hours).
And if you ever hire new developers, there’s extra onboarding time, a steeper learning curve, more hurdles to even finding the right candidates, etc. This of course will vary based on your company (do you work as a sole freelancer? An agency or startup with a few to a dozen engineers? A corporate company with hundreds to several thousands of engineers?)
At my current job, we have around 20 engineers that share components. Even something as trivial as an extra hour of work to do something gets a 20x multiplier, so tradeoffs always have to be balanced.
Having said all that, I’m not arguing that tooling is bad. (We personally traded a very complicated build system in favor of a very easy development life cycle, and that works wonders … until the build system runs into an issue and it takes a few developers several days to figure out, and then have to share the results with all of the other UI engineers).
I’m just saying that you can’t naively take the approach that more tooling and systems are always good, and thinking that something is always just 2-hours is a bad mindset. :)
I don’t believe I insinuated that. I think you make an incorrect assumption that modern tooling will “never just cost 2 hours.” Of course there is training and onboarding. I’ve been working with react and Webpack for a while now and I can have a static site up and running in 30 minutes.
Certainly you have training budgets for your team? We have regular meetings to discuss our stack and hear input. That’s a cost of development for sure.
Conflating “new and more complicated than I currently am OK with” with “over engineering” is wrong.
Certainly a shop can still run a SASS backed Gulp/Grunt system and churn out great product, but it’s not bad to stop for a little bit and ask if the tooling could be improved.
And once you wrap your head around it get a taste of Webpack and HMR you will feel like a new developer.
Even though the web is changing quickly everyday, it’s reassuring to know that fundamental HTML and CSS is still vital in producing websites today and keeping up with those two lanaguges is so important.
I think build processing is disappearing. ES6 classes works plain.
CSS has vars.
Things that don’t get to SSR.
all this sounds strange for me. i have learnt html goes in the html file css in the css file. class names shall describe the element and not the properties. well with all this frontend frameworks looks like it is not like this anymore. even when you use css classes like p50 for a padding of 50 pixel. that is why many people go back to the roots or just use susy.
i think all this should go backword to the roots where it comes frome. yes, people whouse the finally product do not care how it is done but people who will continue working on the product care. and when this people who have made this high end bullshit have left a company or this technic is out of time – explain the client the situation.
just because something is feshioned at the moment – think a little.
I think Ben hit the nail on the head. Web apps are one thing, and web sites are a different thing. I think most of this article is spot-on for web apps, and not so accurate for web sites. For example, a clean, nearly plugin-free WordPress site, with a sprinkle of jQuery for some sliders and other interactive components, is still one of the easiest ways to build a simple brochure site for a non-technical client. React, Angular, Vue, and every other “current” web app technology is rarely applicable to a site like this (and when it is, it can be loaded solely in a specific area of the site, like using Angular to build some sort of visualizer app on an otherwise static site).
I agree. This article needs to have a big clarification at the top that these comments are for web apps, not web sites.
I find that after building websites for about 18 years now, that I have to do less work, and I want things less complicated than in the past.
I use frameworks that make HTML/CSS/JS more easily editable, more accessible, not less. React, Anglular, etc… are for apps. I can literally have an entirely new site up in running at a click of a button. I don’t need to compile anything. A website is just content on URLs. They are just pages.
A webapp is an entirely different animal than a website and the future of websites is certainly not the same as webapps.
SASS will get replaced, jQuery will get replaced by a smaller library that does the same simple stuff (or jQuery will get trimmed down). And sliders and galleries will not need a dedicated React programmer to be built. But most likely, a components will used.
I will be the party pooper and predict that React will box itself into a corner to fulfill the needs of Facebook to the detriment of everyone else, and it will then become the Prototype.js of frameworks. Google will crap all over Angular the same way.
But, websites will still be html, css and some JS to spice things up for a long time to come. Maybe something new will come along, but I doubt it will change the fundamentals.
A page is still a URL for a website… maybe not a webapp though.
I find myself agreeing with you on most of your acute observations except for two:
The line between native and web will only blur from the user perspective. For the developer, it won’t make sense to ship a 40+MB runtime (taking electron as an example) in order to run 2MB of code instead of a 5MB native app which will be more performant than the web app. Only if mobile and desktop operating systems would all agree on a common format for webapps that allowed the simple installation everywhere, then webapps will replace native apps.
Where does frameworks like Foundation and Bootstrap fit in to all this? Are they thrown out with jQuery or will they adobt to these frameworks?
I have found that because of things like flexbox, grid, CSS3 in general, and mobile taking over (with modern browsers) and auto-updating browsers (evergreen) that these frameworks are less useful than before.
Bootstrap is to CSS like jQuery is to JS? Not a perfect analogy. But I certainly see many sites using Bootstrap and think it’s a useful skill, but where I work, we scrapped normalize, almost all shims/shivs and made our own compliant CSS framework that works on all modern browsers.
It’s clean, light, easy to work with, and we can grow and trim it as the times change. The other frameworks are a huge overhead by comparison now.
But what I have found is that dev teams that only have to focus on one site (like a huge coporate site) are more likely to use and get value from Bootstrap/Foundation, than if you are a web designer building new sites on a regular basis.
Mainly because if you hire/fire people, it’s easy for HR to say “do you know bootstrap?”
…but you’ll still need to (know) how to use it.
What part does WebAssembly play in front-end development in the coming future.
A huge part, I believe. Check out what TJ has to say about it below. Keep in mind, TJ was a core contributor to Node.js and created a bunch of the libraries/tools that we use today. The guy is just a genius. Also, just ignore the Go vs Node stuff. He talks about WebAssembly in this post.
“Extending this idea a bit, you can see how URL could become an identifier for state. If state defines the composition of components and URLs, on principle, have to point us to a specific piece of information.”
If you think about it, that exactly what URLs/URIs are. They are a Uniform Resource Locator/Identifier.
Jokes aside: It often seems to me that web developers and their immediate customers live in some alternate universe bubble where really everybody has high speed connections and is upgrading to a new high end computer once a year. (Thereby contributing to global electronic waste.) Meanwhile, average Joe and Jane complain about all those slow, unresponsive web-sites out there.
Is it really necessary that simply posting an image to a so-called state-of-the-art website requires more system ressources in terms of processor time and memory consumption than running Photoshop?
I agree that we are building systems, though. But those systems should put together modules at compile time. So the result is a fast and lean and smooth beautiful web page. Sass (or an even more powerful successor) is here to stay. In the future, it will be used to write full-fledged CSS-compilers. Libraries like True will help with that.
Yes, please. How can people accept 1.5MB JS for a page as simple as a paragraph of text? Mind-boggling. The “Back to the Web!” movement is a part of my https://radogado.github.io/natuive/#showcase
You really nailed a lot of these! Design systems, client expectations – I’ve been thinking deeply about these two recently. Design is falling under the realm of engineering and could to some extent be semi-automated. This is both frightening and actually very liberating as it allows designers to focus more on the holistic design of the system rather than the interface.
One thing that really concerns me in the design space is that most design is focussed on products and applications now rather than I guess what we think of as traditional “store-front” websites. Are we complicating the process for a traditional website. I don’t think so, but it’s worth considering.
this is like ‘pop music’, rarely gets a long time of life. Few years ago the Lazy Load “only load what you need”. Now webpack (and others) “get everything in one load”. Also THEN you need only download manually a css and JS file and put it file, NOW initialize a project, install dependencies, download dependencies, transpile-compile-
minify-inject-etc… dependencies. Think about it :) “React” is now popular, like “Angular” few years ago like jquery few years… well sometimes (like Phil Nelson answer) you only need an HTML file with CSS.
A gentle reminder:
This is a motherf*cking website.
As a designer I have been part of a big Webproject which was made with react.
What I still don’t get about this framework hype is this:
Why is suddenly everybody hyping these frameworks when the do a horribly job at separating markup/content/styling. For years all the web-gurus have preached that separation is key. But now not anymore?
I agree with your comments about React, as much as it will infuriate other developers. I enjoy working with it and some of the stuff you can achieve is way cool, but to me it feels so dirty having all the markup, content and styling in one place…
One argument in this area is that when you split your codebase along HTML/CSS/JS lines you aren’t actually de-coupling anything, the CSS you’re writing is still dependent on the HTML, and the JS could be affecting both the HTML and CSS. So even though your code is split into different files, it’s all tightly coupled together functionally and interdependent.
React throws out this paradigm for a new concept where all the code for one ‘component’ lives in the same file, and those components are small and re-usable, so the separation of concerns idea is still kind of there, but the ‘concerns’ aren’t necessarily markup, style, behaviour, so much as they are individual pieces of fully-fledged UI and functionality.
I get the idea, and it feels really gross for a while when you start using React, but once you get used to it, it starts to make a lot of sense.
Saying that, I think this idea has more space to evolve over the next few years, we may see some more sensible paradigms emerging.
I’d also add:
The HTML/CSS/JS split is essentially relevant only to making it simple to maintain and add to a codebase over time, (because they are all still functionally dependent on each other).
React’s way of composing components looks and feels pretty weird, but it could be argued that it make this job even simpler, since we don’t need to jump between 3 different places to write one thing, and we don’t need to cross-reference class names etc across three files since everything related to what we’re working on is in one place.
Thanks for your answer, what you say about correlation of the different files is absolutely correct.
It’s just a logical separation; when i build html or js i don’t care about the style, just about the names.
When i build js logic i don’t care about html structure and so on.
I have under my hands just what i need in that moment.
I still have knockout projects built as you describe React logic (which i admit don’t know that much), all in one files, two way binding mixed with html; At first was strange, then it became so clean and so short; then, it became more and more hard to mantain.
Oh, and a nightmare to debug.
I might try again in a later time, at least when one of the libraries will be the clear market winner, as happened years ago with jQuery/MooTools/Yui/etc.
At the moment looks like Angular has the dominance but things change very fast.
That is why you need progressive design.
Each is a layer that enriches the user experience but is not a must.
Splitting code into different files certainly adds some overhead but then you will also be splitting components into its own files.
I find the component hierarchy more rigid than the HTML/CSS organization you may come up with.
Yeah 100% agree it’s very rigid. Don’t get me wrong the react way of doing things is very prescriptive and not a replacement for anything, it just approaches the separation of concerns problem in a different way which seems interesting. I’m more into the idea at the moment of using react or vue for smaller, less consequential things like ‘widgets’ in traditional or WordPress sites.
Calling jQuery the past to me is really wrong.
It’s a tool, and in mayn contexts is the best tool.
Oh, and Less/Sass for Css.
I found this typo: “but you’ll still need to know how to use it”