Fagdag with Kraftlauget
We had an amazing time at "fagdag" with Kraftlauget which was a great forum for knowledge sharing! Our friends at Kraftlauget held a session on Svelte and also arranged an interactive competition to see which team could best optimize a DevOps pipeline using GitHub actions. Our team members Stein Børre and Eugene contributed to the learning seminar too.
Some of the benefits to Virtuoso that we discovered:
Easy to use, even for non-technical team members
Provides real-time quantitative insights
Offers satisfactory support through webinars, documentation, etc.
Supports cross-platform compatibility testing
Can meet custom requirements
Can be used for API integration tests and/or include API calls in test cases
Can be easily integrated into a CI/CD pipeline
Integrates with Slack and TestRail
Some of the downsides to Virtuoso:
Live authoring always starts from the beginning of a journey (a series of features tested in an end-to-end flow)
Cost per journey execution, which may lead to very large journeys that can be more difficult to maintain than smaller journeys
No conditions (e.g. “If button A is not there, click on button B”)
Hard to make journeys robust on all platforms
No integration with Atlassian’s Jira software
For Instech, the benefits outweighed the downsides. We are pleased with the pilot test and will continue to use Virtuoso.
Some identifiable positives:
Exciting tech which opens opportunities for back-end developers trying their hand on front-end development
Good in scenarios where there is tight integration with back-end as it enables the developer to reuse a great deal of code sitting on the boundaries of the solution
Ability to use familiar tooling and development libraries
Not having to use the universally loved JavaScript 🙂
A few points where Blazor fell short:
The troubleshooting and debugging experience was not optimal due to the relative immaturity of the platform
It’s probably not feasible for mobile-first due to the relatively large download size, but could work well with a progressive web app
While it promises near native execution speeds, there are many scenarios where JavaScript outperforms Blazor
There are still cases where one has to resort to writing plain JavaScript, especially when trying to interact with external libraries
When Eugene demonstrated the final product, he pointed out that the entire game had only 7 lines of JavaScript code (pertaining to authentication). This is quite impressive for a single-page application heavily focused on front-end logic. While probably not viable for most projects, it is possible for a back-end developer to build a front-end application without too much difficulty, although some changes in development mentality would have to be adopted.