Category: web developing

The web last year

This year it seemed right to do some review of the last year. A year in which I learned a lot, gained new insights and even more questions..

Direction of the web

A lot have been written about the web by a lot of people with more influence than me. Hence I also don’t like the direction where the web is heading. 60-70 percent of the internet is owned well known large corporations. And the gap to publish something totally by yourself is getting larger and larger.

I like to compare it with houses, not many people can build a brick house by themselves, nevertheless if needed anyone can build a functional shelter. This shelter is something you get, know instantly how to build one all by yourself and own it. The digital equivalent of a shelter is a online publication or a post which unfortunately is owned directly by a large company. I would love to see people own the internet again publish completely on their own.

Online marketing

This year the divide between online marketing and engineering became more clear and present. I am even on the verge of diving deep into the world of online marketing because I do not understand it anymore. I always had a vision that when an online product solved a genuine problem for people that you should never hinder people.

Nevertheless it seems necessary to add bigdata, popovers, slide-ins, conversion footers eg. to increase the revenue.
Next year I really want to learn more about this balance. An hope to find answers in big data and measurements.
I still have the feeling that online products should be free of annoyances. Hence if allowed, lots of people would possibly prefer to drive a car with ad banners on the windscreen.

Front-end

This year we took some big steps to out vision to remove jQuery the next year. Unfortunately we still see IE11 sticking at 4 percent of our users. Which sometimes makes me sad. I prefer programming over implementing or finding fixes for browser inconsistencies for IE and sometimes IOS. Nevertheless it is part of the job might fall in the same category as emptying queues for backenders.

Learning goals

My main learning focus will be the same as last year; keep up with front-end, learn more on software architecture and get deeper in to linux/shell scripting.
To broaden my knowledge I want to extend my Node.js skills and dive deeper in Python.
Smaller topics I want to spend time on are:

  • Gain more insights in the balance between Online marketing and UX as a business goal
  • Building teams and motivating people
  • Typescript
  • Webassembly
  • Variable fonts
  • Service workers
  • Ethics and technology

Conclusion

Next will be again full of exciting things in technology, but I also predict a shift in balance. I hope that that more people will walk up straight instead of bent down on their phone (myself included).
For myself I am keen on learning a lot and keeping the nice life/work balance…

Lessons learned modernizing Frontend

Lessons learned modernizing Frontend

tldr; Strategy taken on rebuilding our main website

The past years few year we gradually began to change out main application from a gigantic jQuery monolithic structure to a more modular and service oriented application. The current application was not bad, it did share code with our other sites by composer and separation of code was in place. But we wanted es6 and more modularity and also to remove the dependency of jQuery in the future. In this document I will discuss the strategy we have taken and the hurdles we had to overcome.

Since we could replace the whole site we needed to have a gradual approach, which settled on the final strategy:

1 – keep the LAMP stack for the SEO important parts of the site, might one day migrate to a SSR react solution if the services in the backend are ready

2- migrate the JavaScript needed for the LAMP stack frontend from JQuery and Composer to ES6 and NPM/Webppack

3- Replace the dynamic parts of the site, filters, search results, price grids etc with React.

4- Keep everything in the Frontend in sync with a global frontend application state with the help of Redux, this state should only store information needed for the business logic. This step really made it possible to slowly migrate to a newer stack in the frontend.

5- create a event dispatcher which uses native javaScript to replace the jQuery event system. On difficulty we had was to replace The Jquery Ajax Complete event, Mostly in IE11

build sytem

The build system we previously had was heavily dependent on Assetic by symfony and composer. We replaced this with NPM and Webpack. In webpack we created 3 main build roads for the JavaScript

1- legacy code: we import the legacy scripts with ‘script-loader’, the best way would be to rewrite all to es6 modules, unfortunately we have literally hundreds and hundreds of legacy files tightly connected to jQuery.

2- modern js: es6 code new code is written here en sometimes legacy code is migrated to this section, shared code is moved to a jest unit tested repo, shared with npm instead of composer vendor module

3- react: we decided to make the dynamic parts (filtering and result listings) of out website with react

Styling

Our website was based on compass, which provided us with a lot of magic, but also a lot of breaking code when we tried to remove the dependency on Compass

First step we replace all the styling which depended on Ruby functions of Compass and we include all the uses scss compass mixins our self.

Second step was to remove file per file the dependency on the Compass mixins this also took some time

Replacing jQuery modules

we had lots and lots of jQuery modules, which sometimes caused problems and fixing sometimes was hard because of the size of some of the modules. For the future we decided to replace all the modules ourselves. In the end a basic Modal, Slider eg. are actually very simple. Currently out newly written modules are living in a separate repo, the modules only change css classes and styling is not available. Styling is the responsibility of the site which is implementing the module.

testing

Testing was also added to the stack, we used some testing in the past with Jasmine, since Jest looks a lot like Jasmine and has a lot of momentum we made sure that the new shared repos we tested with Jest. Jest proved a really nice experience. We use it for React as well as for regular es6 modules. A lot of things worked seamlessly even integrating locale and formatting libraries.

Prevent regression brought us to cypress.io a brilliant suite. The one drawback of cypress is that it only works with chrome, but luckily the functional changes and features between browser do not differ as much as they did in the past. The advantages however are enormous, in half a day I had several integration tests running on my machine. And one day later we had cypress integrated in Jenkins. Cypress also helps with keeping the tests clean by checking  and testing on the fly. Elements not found result in an test error for example.

Lessons learned

Always stick as close as you can to the W3C standards, to future proof you site. Be hesitant to use plugins and pick them wisely, for sliders for example we chose the excellent Siema slider (https://github.com/pawelgrzybek/siema) which is a perfect es6 minimal slider which makes it easy to build complex sliders with. like the example below.

Another standard is NPM this is the starting point for our front-end scripts, and it will be even when the new Webpack arives. Composer also hooks into npm scripts to have a single update command.

Also make sure you create a system for “Single source of truth”. This really helps with keeping things clear,and keeping the decreasing “old” in sync with the increasing “new”. We picked redux for this, but there are several options.

When you choose (or are forced) to slowly migrate legacy to modern frontend, then it is no shame to use some global variables. As long as you can remove it when the full migration has been fulfilled. For example we use globals for: the state, the event systems and the error logging.