|
Content Developer II at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
|
You can add Vivaldi to the growing list of companies that will offer a native version of their web browsers on Windows on Arm. It's still early days, but it's happening.
The post Vivaldi is Bringing Its Browser to Windows on Arm Too appeared first on Thurrott.com.
Electron 30.0.0 has been released! It includes upgrades to Chromium 124.0.6367.49, V8 12.4, and Node.js 20.11.1.
The Electron team is excited to announce the release of Electron 30.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.
If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.
Log in
@electron/packager@18.3.1 or @electron/forge@7.4.0.WebContentsView and BaseWindow main process modules, deprecating & replacing BrowserView (#35658)BrowserView is now a shim over WebContentsView and the old implementation has been removed.WebContentsView API to other similar APIs.124.0.6367.4920.11.112.4Electron 30 upgrades Chromium from 122.0.6261.39 to 124.0.6367.49, Node from 20.9.0 to 20.11.1, and V8 from 12.2 to 12.4.
transparent webpreference to webviews. (#40301)navigationHistory on webContents API with navigationHistory.getEntryAtIndex method, enabling applications to retrieve the URL and title of any navigation entry within the browsing history. (#41662)BrowserWindow.isOccluded() method to allow apps to check occlusion status. (#38982)net module from the utility process. (#41417)navigator.serial. (#41734)NODE_EXTRA_CA_CERTS CLI flag. (#41822)Cross-origin iframes must now specify features available to a given iframe via the allow
attribute in order to access them.
See documentation for more information.
--disable-color-correct-rendering command line switchThis switch was never formally documented but its removal is being noted here regardless. Chromium itself now has better support for color spaces so this flag should not be needed.
BrowserView.setAutoResize behavior on macOSIn Electron 30, BrowserView is now a wrapper around the new WebContentsView API.
Previously, the setAutoResize function of the BrowserView API was backed by autoresizing on macOS, and by a custom algorithm on Windows and Linux.
For simple use cases such as making a BrowserView fill the entire window, the behavior of these two approaches was identical.
However, in more advanced cases, BrowserViews would be autoresized differently on macOS than they would be on other platforms, as the custom resizing algorithm for Windows and Linux did not perfectly match the behavior of macOS's autoresizing API.
The autoresizing behavior is now standardized across all platforms.
If your app uses BrowserView.setAutoResize to do anything more complex than making a BrowserView fill the entire window, it's likely you already had custom logic in place to handle this difference in behavior on macOS.
If so, that logic will no longer be needed in Electron 30 as autoresizing behavior is consistent.
params.inputFormType property on context-menu on WebContentsThe inputFormType property of the params object in the context-menu
event from WebContents has been removed. Use the new formControlType
property instead.
process.getIOCounters()Chromium has removed access to this information.
Electron 27.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.
| E30 (Apr'24) | E31 (Jun'24) | E32 (Aug'24) |
|---|---|---|
| 30.x.y | 31.x.y | 32.x.y |
| 29.x.y | 30.x.y | 31.x.y |
| 28.x.y | 29.x.y | 30.x.y |
In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8.
You can find Electron's public timeline here.
More information about future changes can be found on the Planned Breaking Changes page.
S02E15 (#325). Ellen Lupton, designer, educator and author, helps us stock up our toolbox of design principles and methods, starting off with storytelling in visual design, and the “rule of three” before we move on to linear and non-linear experiences. Will we follow the rule of three and have a third topic?
We talk about IKEA and The Wizard of Oz, labyrinths and mazes. The use of colour to craft a narrative within larger experiences. The importance of pace, and that sometimes a challenge is good for the experience.
“[Seven] is a beautiful number. It’s a prime number, it has an elegance within the sequence from one to ten. That’s very attractive. And of course, people can remember seven things, not me anymore.”
– Ellen Lupton
(Listening time: 31 minutes, transcript)
The post The rule of three with Ellen Lupton appeared first on UX Podcast.
Kathryn Grayson Nanz Is a designer who's written an ebook called Quote Foundations of design for developers. She understands that developers need to participate in the design process, and often developers can identify that something is wrong with the design but they can't figure out why. In this episode she talks to Scott about how engineers and developers can learn design and even become actively interested in the topic!
I am nearly – and only – a five year old software engineer. And I’m still enlightened and entertained by all of the new frameworks, libraries, packages, ideas that surface every week in the Javascript community. One of the largest trends in recent years is a shift from frameworks to meta-frameworks..
These projects provide a larger architectural foundation. The metas take on more difficult problems and big decisions that prevent projects from getting a solid start. They do this by defining the way to build a your-brand-of-meta-framework app.
They provide convention. There are a few things the meta-framework brands have agreed upon. One convention is file-based routing – for example, using a project directory `/routes` and special filenames `/routes/thing/[id].js` to determine application routes. Another convention is utilizing a project directory for api endpoints or serverless functions. In simple terms, that is just a lot more problems that an application developer no longer has to manage.
The meta-ness of these frameworks comes from their ambition to solve problems beyond what single-page application (SPA) or rendering frameworks have been solving. And each are, in fact, built atop these frameworks – soo meta.
Meta-frameworks are also considered to be full-stack frameworks. In a variety of flavors, they each allow components to be rendered or streamed from a server (SSR), statically generated (SSG) at build time, completely client side (SPA), or any combination of the above (and probably other ways).
Because of the different rendering approaches, each framework has layers of abstraction for fetching data and managing state. This allows authors to follow familiar patterns of making declarative UI while the framework handles the lifecycle on both the server and client seamlessly.
One of the first advantages of these frameworks that I became aware of is SEO, a sore spot for traditional SPA applications. Because most of the application is rendered on the server and can include dynamic meta tags, it is much more likely to index on search engines. Hear that? All the traditional full stack app framework developers just giggled in unison.
And all that giggling – it’s allowed. Look, I didn’t live through it. But a lot of folks are saying these types of problems were created by SPA frameworks and that meta-frameworks are taking us back to a time before these problems existed. There have been full stack frameworks for longer than there have been frontend frameworks, young man. But the promise of this new wave is that they address the full stack from the front end rather than from the back end. You are able to build a highly interactive application that feels like a SPA while leveraging server-side capabilities. Offering flexibility, from simply utilizing advanced hybrid rendering techniques to building the entire backend within the same application, including API, cloud functions, database schemas, type systems, and shared application logic – all written in the same language and context.
Perhaps the first of the breed. Next popularized the idea of the meta framework. It just provides so much that React intentionally avoids as a library vs a framework. Many former React core members now work on Next. And it is often the first to adopt new features from React itself ( like server side components ).
When Remix came on the scene, its major contribution was (and is) its focus on web standards. With super novel ideas like using a `<form/>` to submit a form. Its founding authorship also includes folks from React Router. So there’s a deep knowledge of the inner workings of React and what applications need to thrive.
Originally inspired by Next.js. Nuxt changed a letter and uses Vue for rendering. Over time though, Nuxt has become entirely its own thing. Since Nuxt version 3, there has been a huge push to separate all of the components that make up the project. As such there’s also a push for modularity. Giving contributors the opportunity to hook into the framework and author Nuxt modules to extend its abilities.
Svelte and its founder Rich Harris have one main goal: to make web application development better and fun. SvelteKit is an extension of that goal that brings Svelte to the full stack. One of primary differentiators is that it is compiled; meaning the framework has complete control over the output of the application and its performance.
“The web framework for content-driven websites” says it all. Static generation is the primary target, though it does allow for other rendering depending on project needs. Which makes it a great choice for a website vs web app. Astro has its own component syntax that is designed with content in mind. One of its coolest features is that it allows you to bring in components written in any of the most popular frameworks. So, you can write your main content in Astro and some super highly interactive pieces in the framework of your choice (or the choice of the npm package you’re stealing).
SolidStart isn’t even in 1.0. It was almost there…but made some heavy changes inspired by the Nuxt project’s move to a more modular architecture for the underlying framework. The same architecture in fact. Solid’s claim to fame is signals… which nearly every other UI framework has since adopted (even Angular!) and has even led to a proposal to add signals to JS. The component syntax is heavily inspired by React; but it famously does not use a VDOM and has the finest fine-grained control of any of the frameworks I’m aware of.
Built by former members of the Angular team; Qwik and QwikCity aim to be…quick. Speed is its main goal; especially quick at all of the metrics Chrome uses in its lighthouse score. It does this by sending completely interactive HTML and lazy loading all of the JS using a variety of tactics. It then “resumes” loading the page in the background. And theoretically reduces the amount of javascript that ever has to be loaded in order to use the app.
The folks at Deno have their own framework. Like some others on the list, Fresh tries to minimize client-side JS for speed and progressive enhancement. It uses a technique called Islands to isolate client side code from the rest of the application. Its relationship to Deno means it is focused on things important to Deno. The “edge”. JIT rendering, and Typescript.
Potentially and probably the most important factors in choosing a meta-framework is the underlying rendering framework. While the meta-frameworks all have particular niche focuses that their next versions are chasing after; their underlying feature sets are very similar. And they frequently adopt each other’s good ideas in future versions.
That being said, the community and framework beneath the meta-framework are much more established, though they are also looking more similar than they were just a few years ago (or maybe it’s just my eyes).
At the time of writing, the projects mentioned in this article are all at varying stages. Again, their underlying frameworks also vary greatly in maturity. For example, React’s age and project numbers are huge, so there is a lot of support and ready-made solutions out there. Vue is known for having an incredible community around the world and has great international support. Svelte has been dubbed “most loved” for its simplicity and small learning curve and for its ability to work seamlessly with vanilla JS libraries. It’s also worth considering if the flavor you’re most interested in is getting long term support from and for the team maintaining it.
Most importantly, which option fits you? What about your co-developers, and the project you’re creating? Like with everything in software, there are tradeoffs. The choices in meta-frameworks are mostly about developer experience and are somewhat philosophical; but choosing something you will love to work with can make all the difference.
And hey, the time and opportunity for choosing tools like these only comes up every so often. To me, meta-frameworks are like brand new power tools with all of the potential to make better products more quickly. And reading about them is like walking down the power tool aisle in a hardware store letting my imagination run wild about what I could build with this thing. Listening to their brilliant contributors talk through the why of their decisions is inspiring, making me want to build something brilliant too. about you can be satisfied just to know about all the interesting and different ideas these super brilliant framework authors come up with every couple of days or so. You and your project may be much more suited to an entirely different approach. But I think if you’re starting to build a web application with Javascript in 2024, then these meta-frameworks are the best place to start.
I’d love to hear your thoughts! Please feel free to share any comments you have about the ever-expanding world of Javascript frameworks.
The post Shopping for a Javascript Meta-Framework appeared first on Simple Thread.
With our recent 1.19 release, performance was our biggest focus for the C++ Extension in Visual Studio Code. This included features like progressive population of IntelliSense results and faster symbol searching. With these enhancements, you can begin writing C++ code when opening a file quicker than ever before. Additionally, we also added support for fuzzy results when searching for symbols.
Searching for symbols using the “Go to Symbol in Workspace” command now uses a new algorithm which returns relevant results in a fraction of the time it took previously.
This new algorithm uses a full-text-search index of symbols that is maintained on the fly, supporting a variety of search methods to find symbols depending on which will be the fastest way to provide results. The search is handled through several different queries, starting with literal matches and progressively moving towards fuzzy matches. This has also added support for fuzzy search results when searching for symbols.
Through our testing, we found an average 5.8x speedup on MacOS, 2.1x on Linux, and 3.1x on Windows. Testing was done using VS Code 1.86.2 on a low-tier machine and searching for a symbol in the PyTorch source code.
Experience this for yourself by upgrading to the new version and using the “Go to Symbol in Workspace” command in the command palette:
When opening a source file with the 1.19 version of the C++ Extension installed, semantic highlighting is now much faster. This change is due to the C++ Extension now providing colorization in increments, starting with the visible area, rather than waiting for an entire file to be analyzed before colorization can begin.
Based on our testing, we found an average 1.5x speedup for time to colorization for Windows, 1.8x for Linux, and 1.2x for MacOS. This testing was done using VS Code 1.86.2/1.85.2 on a low-tier machine and colorizing a file in the PyTorch source code.
But what does this difference feel like? Especially when opening large, complex files you can see the change – for example, the amalgamation source file for SQLite which is 8.8MB. Full colorization in this windows based example used to take 11 seconds, now it only takes 3 seconds (3.7x faster than before!):
Note that the colorization speedup might vary based various factors such as the machine used, workspace size, and file size.
There have been many other enhancements, performance improvements, and bug fixes included in version 1.19. For example, we added several enhancements when adding #includes to a file. To learn more about these changes, please reference the 1.19 changelog.
Download the C/C++ extension for Visual Studio Code today, give it a try, and let us know what you think.
If you have any questions around this release, feel free to start a discussion in our GitHub repository. Otherwise, if you run into any issues, please report them in the issues section. We can be reached via the comments below, per email at visualcpp@microsoft.com, or through our team on X/Twitter at @VisualC.
The post VS Code C++ Extension 1.19 Release: 3.6x faster Go To Symbol & 1.5x faster colorization appeared first on C++ Team Blog.
