Including Innovation in your Web Design

This is a guest post by Junaid Ali Qureshi (a digital marketing specialist who has helped businesses gain traffic, outperform competition and generate profitable leads. His current ventures include Elephantation, eLabelz, Smart Leads.ae, Progos Tech and eCig).

Your website should reflect you

We live in an era of digitalization where the Internet has taken over our lives and woven itself into our everyday routine whether we like to believe it or not. We use it for our personal use or business growth. It is safe to say that all of us have access to the internet. Each and everything is connected to the internet or is either done on the internet. Nowadays, businesses are thriving and reaching new heights of prosperity, all thanks to the internet. The internet has been evolving and thus the digital marketing has changed, throughout the years. The thing is that it is rapidly turning into an essential part of our lives as well as, of the brand business. The digital marketers or anyone who works on or around the internet know how important it for your website to be unique as well as up-to-date. In the world of digitalization, you cannot simply go online, share, and be recognized by your targeted audience. It is rather hard to get where you want to than this, with your audience. One of the most powerful tools today is that your website should be the reflection of your work. We are all well aware that digital marketing moves hard and fast. One also needs to master the tricks and secrets of digital marketing that will surely mesmerize the audience advertising companies in Dubai help your website to reach its targeted audience and give you the desired results.

The thing is when it comes to innovative web design; it’s safe to say that the users are the greatest source of inspiration. Whether it is building off a fully customizable template, or creating their site from scratch. Statistically, about 40% of the people are just not going to be good at innovating whereas, the 5% are born with the instinct. There are things that they do and ways that they think that is intuitive. There are a few things one can do to help reach the place of experimentation and think out of the box; this article shares a few of the techniques by which you can bring innovation to your web design. Here goes:

Start with a blank canvas

You always need to start with a blank canvas always start with a blank slate. Don’t even set the background color to white, black or any neutral color; you may not know if that’s the color you want to go with yet, so you need to keep your ideas open. Try not to restrain yourself to starting at the top of the page layout or starting with a wireframe layout. In this way, your website will have a unique layout. You can always find sudden inspiration for a fantastic way to display the page. For a change, create the product and then challenge yourself to a new solution. So, instead of curbing your ideas around these restraints, build the idea and find a way to make it work around the problems.

Empathize

You need to make sure that you can empathize with your consumers and what they demand of your website. It all starts with empathy. Truthfully, strategic design thinking only has one single goal that is, to understand and solve a problem for its consumers and in order to understand and then solve the problem, one must start by empathizing with the people who are experiencing that problem. The essence of this evolution turns out to be the first principle of design thinking-empathy.

The thing is empathizing with your consumer allows you to better understand their needs; in turn giving you the tools to meet those needs and give them the desired results. These innovations are a direct result of the design thinking model one can follow. Taking the first step of empathizing with their customers gives the insight needed to serve the consumers in a new and unique way.

Provide unique constraints

The third most important thing to bring innovations to your web design is that you need to put innovation at the heart of your strategic plan, plus tout and convey it in every message possible.  However, if you are fighting a mental block or finding struggles then you need to take advantage of your newfound freedom because one of the best methods for generating some unique ideas is to bound yourself and give yourself some restraints but the thing is you do not want to slap on the same old limitations you always face; instead, you must give yourself some clever limitations and see how you can bend the rules in order to play with your design.

Another thing is that you should also consider the question of intellectual property. You can divide your knowledge between the projects you want to protect; the pieces on which you’ll build the value-capturing part of the business and the other one, the knowledge that you are going to put into the public domain.

Collaborate with others

The most important thing is to collaborate with others. You can share your ideas and hear others’ ideas in order to make a great design. Partnering up with another designer can be helpful, fun, and inspiring. The thing is working as a member of a team can be wonderful for you and a wonderfully frustrating experience. On one hand, when dedicated experts come into the specialized areas of a websites’ production, it will often yield better results in less time, especially if you are suffering from a block. On the other hand, communicating your own thoughts and ideas with another person can be a challenging as well as tiring. Designing based on another persons’ work and experience is a great way to force creative results based on the unpredictable efforts of a different designer with limited restrictions.

Once your website is unique and stands out from the rest. Advertising agencies in Dubai advertise amazing websites in return you need more consumers and more exposure. The thing is to go from idea to a successful innovation. It requires a great deal of support, hard work, and collaborations. When people are surrounded by positivism, constant communication, and encouragement, they can find it in themselves to try, fail, rise and then try again.

The post Including Innovation in your Web Design appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Web Truths: the web is broken and backwards compatibility is holding us back

This is part of the web truths series of posts. A series where we look at true sounding statements that we keep using to have endless discussions instead of moving on. Today I want to tackle the issue of the web not moving fast enough for people and clinging on to seemingly terrible ideas from the past.

The web is broken and backwards compatibility is holding us back

This is the counter-argument to the one I discussed in the last post. Much like the exaggurated praise for the web and its distributed nature it has been around for as long as I can remember online discussions.

There is no doubt that many things about the web are sub-optimal. It is also true that carrying the burden of never blocking out old content can slow us down. Yes there are many features of CSS and JavaScript that in hindsight are terrible ideas. And it is true that by sticking to the bleeding edge, you have a lot more fun as a developer. First, there are more things to play with. And, more modern environments also come with better tooling and deeper insights.

There is a problem with this though: as Calvin said it, the problem with the future is that it always turns into the present.

calvin and hobbes strip

So, whenever we embrace new and bleeding edge technology and damn the consequences we create debt. Often arguments against backwards compatibility stem from actions like these. Some standards we have to keep adding to browsers have been rash decisions or based on a need of one player in the W3C at the time.

Breaking changes in any new version of software aren’t ever fun for users and maintainers. This gets worse with how popular your software becomes and how many people use it. And I’d argue that the web is the most used piece of software out there.

Back in the day the argument against the web stack was always Flash. It seemed to be the right thing to use. There was 99% coverage in browsers. It had far advanced tooling in comparison to Firebug (RIP). And there was a sort of built-in code protection. People couldn’t look at and steal your code without jumping any barriers.

Turns out, Flash wasn’t the amazing platform these arguments made it out to be. In the Flash Games Post Mortem keynote at GDC. John Cooney of Kongegrate talks about the story of Indie gaming and Flash.

I love this talk. It shows that Flash and Web developers weren’t that different. Except Flash developers were more pragmatic about wanting to make money. And they had less delusions about their code lasting forever but knew that they had a short window of opportunity.

And this is what this argument boils down to. When it comes to betting on the web, there’s a lot of good faith and wanting to create something lasting involved. If that is your thing it will make you more understanding for the failures of the web as a software platform. And it makes backwards compatibility a no-brainer as this is what ensures the longevity of the web. When Flash changed and the support from the one company that owned it faded, a lot of developers felt forgotten. We now have the problem that a lot of creativity and a lot of work will go away as the platform to execute it is gone. Backwards compatibility ensures that isn’t the case.

If your thing is to release something quick, make some money and know it will go away, the web isn’t as interesting. Even worse, those defending it can come across as evangelical or condescending. But there is nothing wrong with what you want to do. A lot of innovation stems from this approach, and the web can learn from its successes and failures. Much like HTML5 learned a lot from Flash. But that doesn’t mean your approach is better or that the web is broken – it just doesn’t fit your goals. Without the web, Flash wouldn’t have happened the way it has either. Air proved that. The distribution model of the web works. And you can benefit from that without having to replace it.

There are of course some valid arguments for the abandonment of older ideas and non-support of broken platforms. Seeing how fast JavaScript moves, it seems detrimental to the cause to support older browsers. And some of the new ideas we have now solve important performance and security issues.

But all in all, the backwards compatibility of the web is what made it survive all the other platforms set out to replace it. And there will not be a time where we need to run the web in emulators because of it. That is what makes the argument of the web as broken and backwards compatibility holding us back invalid. Of course we can do better, but are we also 100% sure that what we think is amazing now really stands the test of time?

There are more pressing matters to consider:

  • How can we ensure that despite backwards compatibility we get people to upgrade their environments? Seeing that a malware targeted at Windows XP is a huge success in 2017 is more than worrying.
  • How can we enhance older solutions to become better without breaking them? Chrome’s passive Event Listener extension to addEventListener seems to break backwards compatibility . Arrow functions are arguably only syntactic sugar (despite fixing “this”) but will always be just a syntax error for older browsers.
  • How can we make developers embrace newer solutions to old problems that have less side effects? It seems there is a certain point where we stop caring to keep up-to-date and use whatever worked in the past instead.
  • How can we make newer developers embrace the idea of the web as a platform without overloading them with borderline evangelical and philosophical messages? How can we make the web speak for itself?

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Web Truths: The web is better than any other platform as it is backwards compatible and fault tolerant

This is part of the web truths series of posts. A series where we look at true sounding statements that we keep using to have endless discussions instead of moving on. Today I want to tackle the issue of the web as a publication platform and how we keep repeating its virtues that may not apply to a publisher audience.

The web is better than any other platform as it is backwards compatible and fault tolerant

This has been the mantra of any web standards fan for a very long time. The web gets a lot of praise as it is to a degree the only platform that has future-proofing built in. This isn’t a grandiose statement. We have proof. Web sites older than many of today’s engineers still work in the newest browsers and devices. Many are still available, whilst those gone are often still available in cached form. Both search engines and the fabulous wayback machine take care of that – whether you want it or not. Betting on the web and standards means you have a product consumable now and in the future.

This longevity of the web stems from a few basic principles. Openness, standardisation, fault tolerance and backwards compatibility.

Openness

Openness is the thing that makes the web great. You publish in the open. How your product is consumed depends on what the user can afford – both on a technical and a physical level. You don’t expect your users to have a certain device or browser. You can’t force your users to be able to see or overcome other physical barriers. But as you published in an open format, they can, for example, translate your web site with an online system to read it. They can also zoom into it or even use a screenreader to hear it when they can’t see.

One person’s benefit can be another’s annoyance, though. Not everybody wants to allow others to access and change their content to their needs. Even worse – be able to see and use their code. Clients have always asked us to “protect their content”. But they also wanted to reap the rewards of an open platform. It is our job to make both possible and often this means we need to find a consensus. If you want to dive into a messy debate about this, follow what’s happening around DRM and online video.

Standardisation

Standardisation gave us predictability. Before browsers agreed on standards, web development was a mess. Standards allowed us to predict how something should display. Thus we knew when it was the browser’s fault or ours when things went wrong. Strictly speaking standards weren’t necessary for the web to work. Font tags, center tags, table layouts and all kind of other horrible ideas did an OK job. What standards allow us to do is to write quality code and make our lives easier. We don’t paint with HTML. Instead, we structure documents. We embed extra information and thus enable conversion into other formats. We use CSS to define the look and feel in one central location for thousands of documents.

The biggest benefactors of standards driven development are developers. It is a matter of code quality. Standards-compliant code is easier to read, makes more sense and has predictable outcome.

It also comes with lots of user benefits. A button element is keyboard, touch and mouse accessible and is available even to blind users. A DIV needs a lot of developer love to become an interactive element.

But that doesn’t mean we need to have everything follow standards. If we had enforced that, the web wouldn’t be where it is now. Again, for better or worse. XHTML died because it was too restrictive. HTML5 and lenient parsers were necessary to compete with Flash and to move the web forward.

Backwards compatibility

Backwards compatibilty is another big part of the web platform. We subscribed to the idea of older products being available in the future. That means we need to cater for old technology in newer browsers. Table layouts from long ago need to render as intended. There are even sites these days publishing in that format, like Hacker News. For browser makers, this is a real problem as it means we need to maintain a lot of old code. Code that not only has a diminishing use on the web, but often even is a security or performance issue. Still, we can’t break the web. Anything that goes into a “de facto standard” of web usage becomes a maintenance item. For a horror story on that, just look at all the things that can go in the head of a document. Most of these are non-standard, but people do rely on them.

Fault tolerance

Fault tolerance is a big one, too. From the very beginning web standards like HTML and CSS allow for developer errors. In the design principles of the language the “Priority of Constituencies” states it as such:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity

This idea is there to protect the user. A mistake made by a developer or a third party piece of code like and ad causing a problem should not block out users. The worrying part is that in a world where we’re asked to deliver more in a shorter amount of time it makes developers sloppy.

The web is great, but not simple to measure or monetise

What we have with the web is an open, distributed platform that grants the users all the rights to convert content to their needs. It makes it easy to publish content as it is forgiving to developer and publisher errors. This is the reason why it grew so fast.

Does this make it better than any other platform or does it make it different? Is longevity always the goal? Do we have to publish everything in the open?

There is no doubt that the web is great and was good for us. But I am getting less and less excited about what’s happening to it right now. Banging on and on about how great the web as a platform is doesn’t help with its problems.

It is hard to monetise something on the web when people either don’t want to pay or block your ads. And the fact that highly intrusive ads and trackers exist is not an excuse for that but a result of it. The more we block, the more aggressive advertising gets. I don’t know anyone who enjoys interstitials and popups. But they must work – or people wouldn’t use them.

The web is not in a good way. Sure, there is an artisinal, indie movement that creates great new and open ways to use it. But the mainstream web is terrible. It is bloated, boringly predictable and seems to try very hard to stay relevant whilst publishers get excited about snapchat and other, more ephemeral platforms.

Even the father of the WWW is worried: Tim Berners-Lee on the future of the web: The system is failing .

If we love the web the way we are happy to say all the time we need to find a solution for that. We can’t pretend everything is great because the platform is sturdy and people could publish in an accessible way. We need to ensure that the output of any way to publish on the web results in a great user experience.

The web isn’t the main target for publishers any longer and not the cool kid on the block. Social media lives on the web, but locks people in a very cleverly woven web of addiction and deceit. We need to concentrate more on what people publish on the web and how publishers manipulate content and users.

Parimal Satyal’s excellent Against a User Hostile Web is a great example how you can convey this message and think further.

In a world of big numbers and fast turnaround longevity isn’t a goal, it is a nice to have. We need to bring the web back to being the first publishing target, not a place to advertise your app or redirect to a social platform.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

TemplateMonster Digital Marketplace

The following material was provided by Helen Miller (TemplateMonster). We thought Web Professionals should be aware of this new marketplace.

TemplateMonster has over 15 years of experience, and offers a ‘boundless ocean’ of wordpress themes and 60,000 templates holding the promise of making users’ lives easier and more enjoyable. Having the right business wordpress theme can jump start any project and save you a tremendous amount of time and effort. As of now, TemplateMonster has become a digital marketplace and welcomes talented vendors from all over the world.

So, what’s the idea behind the digital marketplace? That’s simple as that. This marketplace is the right place where even a beginner can start earning their first $1,000 with the focus on what matters. Starting a business is challenging, but the digital marketplace opens a new world of possibilities. For more experienced web developers this means a way to a more recognizable and reputable business with an income up to $10,000. It still makes sense if you’re looking for opportunities to increase your revenue streams and to earn extra money. How about earning up to 70% commission from each sale of your digital product?

Welcome to TemplateMonster Digital Marketplace

Why is This Important to Web Professionals?

Important thing is that both beginners and professional web developers can benefit from becoming a vendor on TemplateMonster digital marketplace. Simply put, this marketplace is a huge platform that gathers together the most skilled and talented professionals from the web development industry in a single place. What’s more, depending on the earnings a vendor wishes to get, he can sell either exclusive or non-exclusive products. So, if you’re a professional web developer willing to go any length to achieve your goal, get up to 70% commission from each sale for your exclusive products. Here’s a head’s up for you – it’s worth doing it for the long run.

Top Reasons to Become a Vendor on TemplateMonster Digital Marketplace

Everything in this world has a reason and that reason has a purpose. With a great purpose to help gifted web developers to succeed, there’s a number of reasons why to join the digital marketplace. Since it offers a leeway for gaining the attention, getting a wider customer reach, and making your name more recognizable for the audience, don’t waste your valuable time and become a vendor today.

So, what’s the cut for a vendor?

  • Once you become a vendor, you get one account for selling both exclusive and non-exclusive products. (In comparison, on Theme Forest vendors can sell either exclusive or non-exclusive products.)
  • It takes 12 hours for a digital product to be reviewed, 1-3 days for more complex digital works. (2 weeks is an average time on ThemeForest.)
  • No limitations on the number of products to upload or send for review at once. (On ThemeForest, a vendor can upload 1 product to one category at once.)
  • With a ’Quick Start’ a vendor can earn higher commission from each sale faster.
  • With the ’Ticket System’ a vendor can get quick responses from the Review Team.
  • The ability to assign more than 1 category to the digital products.
  • No location restrictions. Net15 payments should be enough.

How to Become a Vendor on TemplateMonster Digital Marketplace

Here are 4 basic steps needed to become a vendor on this digital marketplace.

  • Sign in the author application. Here, you need to specify what types of digital products you create and whether you’d like them to be sold on the marketplace.
  • Get in touch with the personal manager. No worries, the personal manager will take care of all the organizational issues, clarify the details about the files you submit and the way you’d like to cash your earnings.
  • Once the product page is designed, you’ll receive an email notification.
  • Start earning money. Receive earnings from the themes sod on a monthly basis.

Why Does It Matter Now?

Start with the experience and interests you can’t get enough. Become a vendor on the digital marketplace to make more money and receive top rankings from the clients. However, it’s important to note, your earnings directly depend on the quality of the themes you sell. That’s right. The better the product you sell, the bigger the chance to earn more income. What’s more, each item can be rated and commented by a client. This may leave the more positive feedback and higher ratings.

Don’t waste your valuable time and promote your themes. Here’s a head’s up for you – TemplateMonster is known for its seasonal promo campaigns and discounts. Thus, if you’re really serious about making money as a professional web developer, decide whether you want those discounts to be applied to your digital products or let them stay available at the regular price. Still, you can promote your digital products through multiple venues like a personal blog, social media, affiliate program, or site. Choose your way to winning the battle for attention.

Weighing Exclusive Vis-à-vis Non-Exclusive Products

Welcome to TemplateMonster Digital Marketplace

Since TemplateMonster digital market accepts both exclusive and non-exclusive digital products, the vendor is responsible to decide whether to sell it exclusively at TemplateMonster and get up to 70% commission from each sale, or on other sites also and get 40% commission maximum. That’s an issue worth thinking about, isn’t it?

Besides, take time to learn the types of digital products allowed submit to the digital marketplace.

Welcome to TemplateMonster Digital Marketplace

Why Should a Web Professional Take Advantage of These Offers/Opportunities?

If you’re a professional web developer, you have no room for error. Take a chance to expand your client base and boost your earnings. Once you become a vendor on the digital marketplace, a team of marketers, designers, and coders will review your digital product. If built properly in accordance with the requirements explained in the ’Vendor Agreement’, you’ll be suggested with the lowest and the highest cost of the digital product. However, as a vendor, you can adjust it within a 15% price range.

Welcome to TemplateMonster Digital Marketplace

The best part is that in case you face any hurdles, your personal advisor will never leave you alone. With your personal advisor, you can get rid of all that worries.

If you’re passionate about what you do and excited about how you do it, get involved and become a vendor. With the human desire to grow, there’s always room for improvement. Taking advantage of the opportunities the digital marketplace offers can enhance your career and achieve your leadership goals.

The bottom line is that you have a choice. Grab the moment to get involved in TemplateMonster’s staggeringly powerful collection of beautiful website templates. Take your business to new heights.

 Free ebook

The post TemplateMonster Digital Marketplace appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Web Truths: We need granular control over web APIs, not abstractions

This is part of the web truths series of posts. A series where we look at true sounding statements that we keep using to have endless discussions instead of moving on. Today I want to tackle the issue of offering new functionality to the web. Should we deliver low-level APIs to functionality to offer granular control? Or should we have abstractions that get people started faster? Or both?

In a perfect scenario, both is the obvious answer. We should have low-level APIs for those working “close to the metal”. And we should offer abstractions based on those APIs that allow for easier access and use.

In reality there is quite a disconnect between the two. There is no question that newer web standards learned a lot from abstractions. For example, jQuery influenced many additions to the DOM specification. When browsers finally got querySelector and classList we expected this to be the end of the need for abstractions. Except, it wasn’t and still isn’t. What abstractions also managed to do is to even out implementation bugs and offer terser syntax. Both of these things resonate well with developers. That’s why we have a whole group of developers that are happy to use an abstraction and trust it to do the right thing for them.

Before we had a standardised web, we had to develop to the whims of browser makers. With the emergence of standards this changed. Web standards were our safeguard. By following them we had a predictable way of debugging. We knew what browsers were supposed to do. Thus we knew when we made a mistake and when it was a bug in the platform. This worked well for a textual and forms driven web. When HTML5 broke into the application space web standards became much more complex. Add the larger browers and platform fragmentation and working towards standards and on the web became much harder. It doesn’t help when some of the standards felt rushed. An API that returns empty string, “possibly” or “maybe” when asked if the current browser can play a video doesn’t fill you with confidence. For outsiders and beginners, web standards are not considered any more the “use this and it will work” approach. They seem convoluted in comparison with other offers and a lot of changes seem to be a lot of work for developers to keep up. Maybe too much work.

Here’s what it boils down to:

  • Abstractions shield developers from a lot of implementation quirks and help them work on what they want to achieve instead
  • Low-level APIs allow for leaner solutions, but expect developers to know them, keep track of changes and to deal in a sensible way with non-supporting environments (see: Progressive Enhancement)

What do developers want?

As web developers in the know, you want to have granular control. We’ve been burnt too often by “magical” abstractions. We want to know what we use and see where it comes from. That way we can create a lot of different solutions and ensure that what we want to standardise works. We also want to be able to fix and replace parts of our solutions when a part becomes problematic. What we don’t want is to be unable to trace back where a certain issue comes from. We also want to ensure that new functionality of the web stays transparent and secure. We achieve this by creating smaller, specialised components that can get mixed and matched.

As new developers who haven’t gone through the pains of the browser wars or don’t need to know how browsers work, things look different. We want to code and reach our goal instead of learning about all the different parts along the way. We want to re-use what works and worry about our product instead. We’re not that bothered about the web as a platform and its future. For us, it is only one form factor to build against and to release products on. Much like iOS is or gaming plaforms are.

This is also where our market is going: we’re not paid to understand what we do – we’re expected to already know. We’re paid to create a viable product in the shortest amount of time and with the least effort.

The problems is that the track record of the web shows that we often have to start over whenever there is a new technology. And that instead of creating web specific functionality we got caught up trying to emulate what other platforms did.

The best case in point here is offline functionality. When HTML5 became the thing and Flash was declared dead we needed a fast solution to offer offline content. AppCache was born, and it looked like a simple solution to the issue. As it turns out, once again what looked too good to be true wasn’t that great at all. A lot of functionality of AppCache was unreliable. In retrospect it also turned out to be more of a security issue than we anticipated.

There was too much “magic” going on that browsers did for us and we didn’t have enough insight as implementers. That’s how Service Workers came about. We wanted to do the right thing and offer a much more granular way of defnining what browsers cache where and when. And we wanted to give developers a chance to intercept network requests and act on them. This is a huge endeavour. In essence we replicate the networking stack of a browser with an API. By now, Service Workers are doing much more than just offline functionality. They also should deal with push notifications and app updates in the background.

This makes Service Workers tougher to work with as they seemed complex. Add to that the lack of support in Safari (which is now changing) and you lost a lot of developer enthusiasm.

There is more use in abstractions like Workbox as they promise you to keep up-to-date whilst the changes in the spec are ironed out. Instead of getting a “here are all the lego bricks, build your own car”, it has a “so you want to build a car, here are some ways to do so” approach.

This is a good thing. Of course we need to define more granular and transparent standards and solutions to build the web on. But there is a reluctance in developers to take part in the definition phase and keep an eye on changes. We can not expect everybody who wants to build for the web to care that much. That is not how the web grew – not everybody had to be a low level engineer or know JavaScript. We should consider that the web outgrew the time where everyone was deeply involved with the standards world.

We need to face the fact that the web has become much more complex than it used to be. We demand a lot from developers if we want them all to keep up to date with standards. Work that often isn’t as appreciated by employers or clients than shipping products is.

This isn’t good. This isn’t maintainable or future facing. And it shouldn’t have come to this. But it is a way of development we allowed to take over. Development has become a pretty exhausting and competitive environment. Deliver fast and in a short cadence. Move fast and break things. If you can re-use something, do it, don’t worry too much if you don’t know what it does or if it is secure to do so. If you don’t deliver it first to market someone else will.

This attitude is not healthy and we’re rubbing ourselves raw following it. It also ensures that diversity in our market it tough to achieve. It is an aggressive game that demands a lot of our time and an unhealthy amount of competitiveness.

We need to find a way to define what’s next on the web and make it available as soon as possible. Waiting for all players to support a new feature makes it hard for developers to use things in production.

Relying on abstractions seems to be the way things are going anyways. That means as standards creators and browser makers we need to work more with abstraction developers. It seems less and less likely that people are ready to give up their time to follow specs as they change and work with functionality behind flags. Sure, at conferences and in our talks everyone gets excited. The hardware and OS configurations we have support all the cool and new. But we need to get faster to market and reach those who aren’t already sold on our ideas.

So, the question isn’t about granular definition of specifications, small parts that work together or abstractions. It is about getting new and sensible, more secure and better performing solutions into production code quicker. And this means we need both. And abstractions should have a faster update cycle to incorporate new APIs under the hood. We should work on abstractions using standards, not patching them.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Web Truths: JavaScript can’t be trusted

This is part of the web truths series of posts. A series where we look at true sounding statements that we keep using to have endless discussions instead of moving on. Today I want to tackle the issue of JavaScript and how much we should rely on it.

Good vs. eval()

JavaScript is the love/hate topic of the “modern web”. People who have been around for a long time have learned the hard way not to blindly rely on it. People who just started don’t even know how you could turn it off or why it could be a problem.

This gives us an endless opportunity to rant in one direction or the other. The old guard points out that the new builds fragile products that demand too much of the users. The new guard points out that a web without JavaScript is neither fun for users nor easy to maintain. A lot of times, this argument is about developer convenience trumping sturdiness of the web. And we keep going in circles viewing it from both ends of the spectrum.

When we got JavaScript, it ran in the browser and made a lot of things possible that HTML and CSS alone could not do yet. We could react to things our users were doing without reloading the page. We could read out and react to the environment the script was running in. JavaScript was the interactive glue of the web. We could make less able browsers do things others could. We could create interaction models that HTML forms didn’t provide. And we could create a consistent experience across browsers and platforms.

And this is where the main issue came up: for many, the web isn’t meant to look and work the same everywhere. Instead it should give a working experience for all users and get fancier the more able the user agent is. By relying on JavaScript in our solutions we put up a barrier for the sake of control. This was especially bad when we didn’t deliver any functionality when JavaScript failed.

And JavaScript can fail in many ways. From non supporting environments to coding errors and connectivity issues – anything can break.

JavaScript isn’t like CSS or HTML. Both these building blocks of the web are fault-tolerant. This means when you write invalid HTML, the browser tries to fix it. If you use bleeding edge CSS in an old browser, it ignores it. Not so with JavaScript. Syntax errors or accessing an unknown object cause the interpreter to give up and say no. Even the most capable environments don’t support JavaScript until the first script loaded and ran without a problem.

Stuart Langridge explains what can go wrong until your script does what you wanted it to do in his Everyone has JavaScript, right? site.

The main power of JavaScript was that it executes on the fly and in the browser. It didn’t need any compilation, it didn’t need any fancy development environment. That was a huge part of its success. Compared to other languages that have similar power, it is much more approachable. And it seems easy to fix a problem you have with JavaScript that seems complex in CSS if you’re not used to its syntax. JavaScript can do everything: it can load extra information, it can create HTML and it can change styles and images. It is the jack-of-all-trades of the web.

When something is easy to apply there is always a danger that people over-use it. It is tempting to see your well-connected development device as the world. And to expect the same speeds and computing powers of your users. In this scenario loading a few megabyte of JavaScript is not a high price to pay to allow for easy maintenance. When you’re on a metered, slow or unreliable connection or on a low-end device this convenience can soon turn into frustration. This is an even bigger problem as it is hard – if not impossible – to detect these conditions.

So, yes, JavaScript is a fair-weather friend and can break in many ways. You may also block out a lot of users because you crave more control over things you aren’t meant to control.

There is a flip-side to this truth though. JavaScript has evolved from a scripting language in the browser to a development environment in its own right. The rise of Node and other server-side and embedded systems put JavaScript on the map as a key skill of our market.

JavaScript isn’t a client-side problem, it is a whole bigger set of offers these days. I talked about this beginning of the year at ScriptConf in Austria

Universal, isomorphic JavaScript – or whatever other buzzword we come up with – is the answer to the lack of fault tolerance of the language. We can run the JavaScript in a space we control like the server or a build process and we render out plain HTML. We can use client-side JavaScript in a fair weather situation. If that fails, we can rely on a JS based API and routing mechanism to still give the user the content they came for.

The real, pragmatic approach to the flimsiness of JavaScript though is much easier: people use it anyways, let’s concentrate on keeping it safe and reliable.

Whilst we still complain that JavaScript breaks in the client, we have a huge group of developers who use JavaScript in everything. While we worry about support for a certain new browser feature, people rely on hundreds of package dependencies to build very basic functionality. Whilst we worry about DOM bugs, people use libraries with virtual DOMs and scripted routing instead of HTTP.

JavaScript is a given and a language that empowers and inspires hundreds of new developers each day. Our job as lovers of the web is not to tell people that they are wrong using it in the first place. Our job is to allow these developers to be as creative with this new use of it. Much like we were when a standardised DOM was still a dream to come.

We’re not here to call the shots. We’re here to embrace a new use of a valid technology and help with our knowledge to not repeat age-old mistakes. But we need to make sure that we learn in that process, too. It is far too easy to find glaring mistakes in new applications of old technology. It is much harder to help people solve new problems they face with guidance of past experience. But it is much more rewarding as it doesn’t create a “us old sages vs. those new cowboy-coders” world.

With more defined and controlled environments, JavaScript becomes much easier to trust. The thing we need to worry more about now is to ensure that it doesn’t get too complex.

Instead of worrying about the non-fault-tolerance of JavaScript, here are some other things to worry about:

  • How safe is it to rely on a loosely curated package repository for our projects? How can we make sure that in the dozens of NPM modules we use none of them is malware? How can we ensure people use packages safely, keep them up-to-date and not face disaster when one of them breaks?
  • How can we reap the rewards of abstractions without creating an unhealthy dependency? The vue.js of tomorrow may well be the jQuery UI of today. Yes, we create faster and more with an abstraction. But we miss out on understanding how what we create works. We don’t want to have a lot of developers and products that become ineffective once an abstraction is out of fashion.
  • How can we create a professional development environment for JavaScript without overwhelming new developers? Back in the days we needed a text editor and a browser. Now we need to have command-line knowledge, toolchains, unit tests, continuous integration and heavily customised editors. Each of these things make sense, but can look daunting to a new developer.
  • How can we move the language itself ahead without relying on transpilation? JavaScript is finally standardised and new functionality should be used by anyone, not only in a compilation step.
  • How can we still reap the rewards of the just-in-time compilation of JavaScript when we use it like a compiled language?
  • How can our tooling help new and experienced developers without overwhelming one group and boring the other? Is linting the answer or is it expecting developers to be experts in browser tools?

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Web truths that cause infinite loops

Every few months there is a drama happening in the blogging and social media scene. We seem to need that to keep ourselves occupied. It allows us to get distracted from the feeling that the people who pay us have no idea what we do. And keep praising us for things we are not proud of, cementing our impostor syndrome.

For an upcoming talk, I analysed the recurring themes that we get fired up about. I will post one on each of these over the next few weeks.

  • CSS is not real programming and broken
  • JavaScript can’t be trusted
  • We need granular control over web APIs, not abstractions
  • The web is better than any other platform as it is backwards compatible and fault tolerant
  • The web is broken and backwards compatibility is holding us back
  • Publishing on the web using web standards is easy and amazing
  • The web is world-wide and needs to be more inclusive
  • Mobile is the present and future

Each of these topics can spark thousands of reactions, dozens of blog posts. Many will get you a speaking slot at an event. They are all true, but they are also all not necessarily yielding the amazing insight we expect them to. I’ll try to explain why they are endless loops and what we could do to get past discussing these over and over again. Maybe it is a good time to concentrate on solving other, new, problems instead. And recognise that a new generation of makers and developers may not be as excited about them as we are.

Yes, these will be my opinions and they may spark some discourse. That’s fine. You can disagree with me, and I promise to keep this to the point and civil. I’ve done this for a very long time, I’ve heard many people talk and discuss these. Hopefully my insights will hit a mark with some of you and make us reconsider rehashing the same old discussions over and over again.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)