4 ms·

Modern HTML rendering engines are much much harder than you think, switching to webKit is a way to prevent obsolescence for any browser that doesn't have a huge

by tomxor 7y ago

Modern HTML rendering engines are much much harder than you think, switching to webKit is a way to prevent obsolescence for any browser that doesn't have a huge team of devs behind it.

asveikau 7y ago
Is this space really evolving that much anymore though? I don't follow this field; what's been going on in web standards lately? Seems like lately, from a user perspective, the current emphasis is mostly on doing the same things faster. So an indie browser developer probably won't get JS JIT down as well as a megacorp, but is that it? It seems to me like if you are standards compliant as of 5 years ago there shouldn't be a lot to do today.
- rched 7y ago
  I can understand why it might seem that way but it is actually evolving very quickly. Probably faster than any other time in history. There are a few things driving this evolution but I think the most important one is a desire to make the web a competitive platform for most types of software. This means lower level APIs, deeper integration with OS, and yes a large focus on performance. 3D graphics, offline support, push notifications, file system access, animation, Bluetooth, and more are all recent areas of focus for browsers. Web browsers really are becoming similar to operating systems in scope.
  - arcticbull 7y ago
    That sounds awful haha.
  - asveikau 7y ago
    There are a small number of people pushing that, but where is the adoption, and is the web at large really inaccesible without it? One example, I see a lot of websites offering to send me push notifications, and I always click no. A browser could not implement that feature and I would not notice, in fact it would be an improvement in experience.
    - saagarjha 7y ago
      That’s how you get articles from angry web developers that break things in your browser and call it “the new IE”.
    - Frondo 7y ago
      I think the unsatisfying reason why one should implement it is because it's a standard API now, and it is always better to implement standards.
    - jonfw 7y ago
      What industry are you in that people aren't adopting web apps? At my work we use a ton of web-apps. Chrome-books offer nothing but web apps and they're doing pretty well these days.
      - asveikau 7y ago
        OK, sure. My point is: how many of them hard-depend (no graceful failover) on APIs introduced in the last 5 years though? You could build a pretty good web app 5 years ago, and many people did. Has the fundamental abstraction changed that much? I'm extremely skeptical of the claim. If somebody does depend on something obscure like javascript APIs for bluetooth [like someone in this thread cited], are they doing that as a desktop app with chromium embedded or are they a more traditional webpage? Does it completely fall over and explode if you don't have bluetooth support in the browser? That would be pretty unreasonable for most developers. What I'm saying is there is a difference between the bleeding edge stuff or things that push boundaries and common practice. And if you are coding against that other stuff, you also need a fallback for if it doesn't work.
        neurostimulant 7y ago
        There are tons of changes under the hood that made webapps development easier in the past 5 years, and not all of them can be polyfilled. For example, ES6 Proxy is something an end user won't even notice it exist, but now used at fundamental level on many webapps. Developers that depend on it won't trade their productivity gain from using the new api with supporting browsers that has less than 1% marketshare.
- IggleSniggle 7y ago
  Oh my no. There's the plethora of Web APIs to attend to, with ever new things that require support in order for websites to work. And each of those creates complex security concerns. The js spec is ever moving, with new syntax and features. Accessibility concerns interact with all of these other parts. It's "normal" to ship complex desktop apps deployed to the browser now. And THEN, after all that, you need to maintain backwards compatibility with old standards. You basically need to handle an operating system where the VM is built on top of your browser, with all the security responsibilities and changing demands of developers working on your platform therein.
  - asveikau 7y ago
    People who ship desktop apps as a web browser are already doing that with chromium built in. As far as I can tell a typical user reading the normal web isn't going to be locked out of it with a browser that's a few years old. Not everyone writing web content is an activist trying to disrupt desktop apps.
    - saagarjha 7y ago
      Yeah, but Chromium is doing that work for them.

by tomxor 7y ago

Modern HTML rendering engines are much much harder than you think, switching to webKit is a way to prevent obsolescence for any browser that doesn't have a huge team of devs behind it.

asveikau 7y ago

Is this space really evolving that much anymore though? I don't follow this field; what's been going on in web standards lately? Seems like lately, from a user perspective, the current emphasis is mostly on doing the same things faster. So an indie browser developer probably won't get JS JIT down as well as a megacorp, but is that it? It seems to me like if you are standards compliant as of 5 years ago there shouldn't be a lot to do today.

rched 7y ago
I can understand why it might seem that way but it is actually evolving very quickly. Probably faster than any other time in history. There are a few things driving this evolution but I think the most important one is a desire to make the web a competitive platform for most types of software. This means lower level APIs, deeper integration with OS, and yes a large focus on performance. 3D graphics, offline support, push notifications, file system access, animation, Bluetooth, and more are all recent areas of focus for browsers. Web browsers really are becoming similar to operating systems in scope.
- arcticbull 7y ago
  That sounds awful haha.
- asveikau 7y ago
  There are a small number of people pushing that, but where is the adoption, and is the web at large really inaccesible without it? One example, I see a lot of websites offering to send me push notifications, and I always click no. A browser could not implement that feature and I would not notice, in fact it would be an improvement in experience.
  - saagarjha 7y ago
    That’s how you get articles from angry web developers that break things in your browser and call it “the new IE”.
  - Frondo 7y ago
    I think the unsatisfying reason why one should implement it is because it's a standard API now, and it is always better to implement standards.
  - jonfw 7y ago
    What industry are you in that people aren't adopting web apps? At my work we use a ton of web-apps. Chrome-books offer nothing but web apps and they're doing pretty well these days.
    - asveikau 7y ago
      OK, sure. My point is: how many of them hard-depend (no graceful failover) on APIs introduced in the last 5 years though? You could build a pretty good web app 5 years ago, and many people did. Has the fundamental abstraction changed that much? I'm extremely skeptical of the claim. If somebody does depend on something obscure like javascript APIs for bluetooth [like someone in this thread cited], are they doing that as a desktop app with chromium embedded or are they a more traditional webpage? Does it completely fall over and explode if you don't have bluetooth support in the browser? That would be pretty unreasonable for most developers. What I'm saying is there is a difference between the bleeding edge stuff or things that push boundaries and common practice. And if you are coding against that other stuff, you also need a fallback for if it doesn't work.
      - neurostimulant 7y ago
        There are tons of changes under the hood that made webapps development easier in the past 5 years, and not all of them can be polyfilled. For example, ES6 Proxy is something an end user won't even notice it exist, but now used at fundamental level on many webapps. Developers that depend on it won't trade their productivity gain from using the new api with supporting browsers that has less than 1% marketshare.
IggleSniggle 7y ago
Oh my no. There's the plethora of Web APIs to attend to, with ever new things that require support in order for websites to work. And each of those creates complex security concerns. The js spec is ever moving, with new syntax and features. Accessibility concerns interact with all of these other parts. It's "normal" to ship complex desktop apps deployed to the browser now. And THEN, after all that, you need to maintain backwards compatibility with old standards. You basically need to handle an operating system where the VM is built on top of your browser, with all the security responsibilities and changing demands of developers working on your platform therein.
- asveikau 7y ago
  People who ship desktop apps as a web browser are already doing that with chromium built in. As far as I can tell a typical user reading the normal web isn't going to be locked out of it with a browser that's a few years old. Not everyone writing web content is an activist trying to disrupt desktop apps.
  - saagarjha 7y ago
    Yeah, but Chromium is doing that work for them.