This was the first JavaScript conference for us at
Drawbotics. Not only was it a good occasion to
meet other passionate engineers, but also to travel to Austria where neither of
us had been before. This was the second ever edition of Script Conf, making it
one of the youngest JavaScript conferences.
To get there was a bit of a trek. As our company is based in Brussels we had to
take a plane to Vienna, a train to Linz and finally the tram to our hotel. Also
put a little extra plane in there on the way back. But it was all worth it in
the end!
The conference started at 12am with a drinks reception. We were given our tags
and made our way into the event hall. Greeted by a live performance of glitch
music by Tobi (which was awesome by the way),
we took our seats and soon after, the first of 10 talks began.
The Journey to Full Time Open Source
by Evan You
Essentially overviewing his career as a developer, Evan shared his experience
making a living from Open Source while working on VueJS.
He pointed out some of the difficulties that come with being a developer who
essentially works “out of passion”, such as finding the motivation to work on a
project once it is public. It is hard to overcome the wave of issues posted
every day, and needing to solve them to make your users happy. Money is also an
issue, since no one is paying you to work on your project. Nevertheless, a
source of income is achievable through various methods, the most common one seen
nowadays being OpenCollective, of which contributors to Webpack, Babel and more
are part of. Choosing between developing for Open Source full-time or as a
side-project is still difficult. Most developers that today dedicate their full
time to Open Source were once working for a company and had the security of a
stable income. At Drawbotics we attach great importance Open Source
contributions, not only because it benefits whoever is using that piece of
software, but also because Open Source code is being tested by *everyone. *Bugs
can be found faster, improvements are suggested continuously, and that way your
software matures at a higher rate than if all of those processes were kept
internally.
Radically Accessible Internet Applications
by Marcy Sutton
One thing that many front end developers neglect is accessibility. We often give
precedence to visual fidelity (e.g. from a design) than accessible interfaces.
Expedia.com
Marcy showed some examples of websites with good accessibility such as
Expedia, that enable full content navigation without
a mouse and with voice assistant. However making a complex web page usable
without a mouse does mean greater time and effort are required, and as a result
for companies, higher cost. Companies would rather save time and money by
ignoring that small portion of users that cannot use a mouse or read content
(e.g. the visually impaired). Millions of users rely on internet applications to
get on with their daily life, thus big and small companies should make time to
develop better interfaces and give everyone the ability to use their software.
Hop on the serverless adventure with NodeJS
by Simona Cotin
In today’s world, everything is split into microservices: want to make an API
call for authentication? You got it. Want to call a Babel function to compile
your JavaScript code before deployment? You got that too.
Simona works for Microsoft and is involved in their Azure suite. She
demonstrated the possibilities that come with serverless services: performance
monitoring, ease of expansion and reliability. While we don’t currently use
external serverless services such as Azure, we have been working on internal
microservices which are shared between multiple applications and tools at
Drawbotics. The current trend shows that more and more companies are starting to
rely on external microservices, cutting down the cost of re-creating them
internally, with the added benefit of not needing to manage them.
Cycle.js on pen and paper
by Andre Staltz
We at Drawbotics currently use React for all our front-end applications, so it
was interesting to dive into a different framework, demonstrated here by its
creator. Cycle.js is known for its… unusual paradigm: Cycle revolves around
the fact that the whole application is built with pure functions without side
effects. Thus, data (which includes events, fetched data, etc.) is given as
input and the application returns an output, which itself is used as the input
in the next application run-cycle. Andre used an app to visualise the flow of
data in an application built with Cycle.js:
While reactivity is something we embrace in our front-end applications to manage
state changes, we try to use it only where appropriate (e.g. RxJS).
Next wave infrastructure — do far more with much less
This talk was focussed on process automation, with an emphasis on
deployment: how do you ensure that the next version of your application is
going to behave as expected in a production environment?
Phil showed a great example of the “perfect timeline”, visualising the different
steps that most engineers have probably gone through at least once when
deploying a new iteration of their project.
From Phil’s presentation
There are two main lessons to be learnt here:
- Always use atomic deployments, that is, create a new instance of your
application and push that, instead of making granular changes to the code
directly in the production code (looking at you, Github UI edits). - While you often can’t avoid failure, you can prepare for it. Thus always figure
out the deployment flow before even starting to work on the new feature. In
addition, constantly deploy to a production environment to ensure nothing breaks
the deployment.
At Drawbotics we already embrace these two concepts. Webpack helps us create a
new bundle at every compilation, ensuring atomicity, while Heroku Review
Apps give
us access to a production environment created for every active pull request. We
were glad to see that we are using processes considered “new wave” in our
current development flow. This process didn’t appear out of thin air, though: we
went through that “perfect timeline” more than once before taking action…
Creating Augmented Reality Apps with Web Technology
VR, and more recently AR, have been the topic of hot discussion in the last
few years. Especially after the release of Pokemon Go, many companies have dived
into the development of AR apps. Most of these apps are native, meaning they are
written in the device’s native code, making them much more performant than a web
application. However given the huge impact web applications have today (pretty
much every major company uses some sort of web framework to power their website)
people are now trying to get AR working through the web.
Currently the most popular web framework to create 3D interactions on the web
is Three.js. Using WebGL under the hood, it allows
developers to make full blown 3D games with physics and particle simulations on
the browser. Thanks to ever improving device APIs, people have started creating
augmented reality interactions with code that runs on the browser (e.g. with
AR.js). Obviously as the code is not
running natively on the device, performance is not at the same level as native
code, but cool things can still be achieved with it.
Web-based AR, and AR in general, is still in its very early stages, though we’re
certain it has massive potential to grow, especially in the professional market,
both for businesses and customers. Just imagine configuring your brand new car
with your phone in a showroom, with your options being mapped onto the original
car or a blank model. Could be pretty awesome.
Look mum, no hands!
The last talk at Script Conf 2018 was about human-computer interactions… with
the brain. Using a new and sort of futuristing looking device, the
EPOC, Charlie demonstrated this innovative
medium. Originally built to work with C++, you can now develop code in
JavaScript to interact with it thanks to
Epoc.js.
EPOC from Emotiv
It’s still unclear what the use cases will be for this sort of device, though it
naturally seems to fall towards accessibility; someone that may have lost the
use of their hands could use this to send commands to their computer instead of
needing to speak. In addition, in a future world of VR or AR interfaces,
brain-wave interaction could prove to be very immersive as opposed to the
current point-and-click method.
Wrapping it up
Script Conf was a great experience for us. We met lots of interesting people,
and got to discuss with many of the speakers during the afterparty, sharing
professional experiences as well as funny stories. Overall, it was awesome and
we would like to thank the organisers as well as everyone that participated. We
can’t wait to see what next year’s edition will bring!
