5 ms·

I have no doubt that the web will eat desktop application (maybe native app as well at some point). However, they are plenty fields from machine learning, to r

by seren 11y ago

I have no doubt that the web will eat desktop application (maybe native app as well at some point). However, they are plenty fields from machine learning, to robotics that are also likely on the rise that would require some SW development skills. Also, as mentioned by d0lph, I believe the high churn in web technology makes more people relying on SO, compared to let's say someone coding in C99. But my view is probably skewed by working in embedded SW.

TheLogothete 11y ago
>I have no doubt that the web will eat desktop application Both Steve Jobs and Bill Gates disagree with you[1]. [1] https://m.youtube.com/watch?v=wvhW8cp15tk https://m.youtube.com/watch?v=wvhW8cp15tk
- xemoka 11y ago
  In 2007. Everything changes, it's our only constant.
  - TheLogothete 11y ago
    What has changed in the limitations of the DOM?
    - xemoka 11y ago
      Perhaps not in the limitations of the DOM, but how we deal with it is changing.
      - TheLogothete 11y ago
        Their arguments are just as valid as then. Web interfaces will never be as rich as desktop ones. Cloud connected desktop applications will gain a lot of momentum going forward.
        vram22 11y ago
        Right, roughly what I said in a parallel comment. Good to see others think so too.
    - nostrademons 11y ago
      Quite a bit, actually. Since 2007, we've gotten Javascript JITs, Canvas, WebGL, consistent box models, consistent event models, flexbox, CSS transitions & animations, CSS transforms, localstorage, IndexedDB, websockets, HTML5 audio & video, history.pushState, and several other features. And components (custom elements + Shadow DOM) are coming, and already implemented in some browsers. Pretty much anything you could do in a native Windows app in 2007, you can do in a webapp now, except pwn your computer. Only problem is that the goalposts have moved: now everybody expects you to be able to do it on a phone as well, as well as access the camera, accelerometer (which you can do on the web, actually), contacts, calendar, and bluetooth hardware.
      - TheLogothete 11y ago
        Uhm... the DOM is single threaded and sequential. It will never EVER be comparable to native clients.
        nostrademons 11y ago
        Web Workers.
        TheLogothete 11y ago
        Yeah man. I've never heard of those. They sound like the best thing since sliced bread. Only if they could access the DOM... Seriously... what are you even talking about? Why do you even mention them? You read single threaded and thought "Quick, I must come up with an answer! I can't let a stranger on the Internet change my opinion!"?
        nostrademons 11y ago
        So, it's hard to understand exactly what it is you're trying to accomplish and why Web Workers wouldn't work for you because basically every single desktop GUI framework is single-threaded when it comes to actually updating the components on the screen. Win32 uses the GetMessage/TranslateMessage/DispatchMessage event loop. Swing has the UI thread, and then to update the UI from a background thread, you need to call invokeAndWait or invokeLater and pass a Runnable. Cocoa and iOS have Grand Central Dispatch, and to update the UI you pass a block to dispatch_async on a dispatch queue. Android has you call View.post() with a Runnable that contains your UI modifications. WPF has two threads, a rendering one and a UI thread, and you're supposed to pass long-running operations off to a threadpool and then call Invoke or BeginInvoke with a delegate to actually update the UI from them. Web Workers are exactly this model, applied to the web. It's a dispatch queue running inside a threadpool. To update the DOM, you postMessage back to the UI thread and make your modifications there. Are you willing to let a stranger on the Internet change your opinion?
vram22 11y ago
>I have no doubt that the web will eat desktop application I hope not. There's nothing like a well-done desktop GUI EXE for richness of UI / UX. And desktop GUI apps can still connect to back-end services over HTTP or other technologies.
manyxcxi 11y ago
The thing is, with the ML code or the code for robotics that I've written over years, it's been predicated on the fundamentals of software development I've learned doing everything else. Good habits are good habits, disorganized code is disorganized code. In some ways all the C/C++ I've written for my various robots and gadgets have been easier than even web development UI code because my button is LITERALLY a button, my screen resolution is a 2 row LCD, and I'm designing the system my code will run in. Don't get me wrong, I'm half kidding, but my point is that a good developer is a good developer in whatever area of development they want to work in. You take a good web app developer and move them in to robotics, they'll be good quickly. At first they're obviously not as familiar with the domain, so there is a curve. But they will get strong eventually- assuming the EE side of things doesn't drive them away.
- seren 11y ago
  I agree with your point. When I said "development skills" it was not a judgement about talent, rather about "body count".
  - manyxcxi 11y ago
    Ah, that makes sense and I definitely agree. The ability to write code in a decently maintainable fashion will certainly be necessary in fields that it wasn't and new fields entirely. The upside for people that do this, as I alluded to, is that if you have these skills and want to do a new thing in a new field, it's an option. Things like SO will help you play with the new thing in the new field where you might otherwise not have any help.

by seren 11y ago

TheLogothete 11y ago

>I have no doubt that the web will eat desktop application Both Steve Jobs and Bill Gates disagree with you[1]. [1] https://m.youtube.com/watch?v=wvhW8cp15tk https://m.youtube.com/watch?v=wvhW8cp15tk

xemoka 11y ago
In 2007. Everything changes, it's our only constant.
- TheLogothete 11y ago
  What has changed in the limitations of the DOM?
  - xemoka 11y ago
    Perhaps not in the limitations of the DOM, but how we deal with it is changing.
    - TheLogothete 11y ago
      Their arguments are just as valid as then. Web interfaces will never be as rich as desktop ones. Cloud connected desktop applications will gain a lot of momentum going forward.
      - vram22 11y ago
        Right, roughly what I said in a parallel comment. Good to see others think so too.
  - nostrademons 11y ago
    Quite a bit, actually. Since 2007, we've gotten Javascript JITs, Canvas, WebGL, consistent box models, consistent event models, flexbox, CSS transitions & animations, CSS transforms, localstorage, IndexedDB, websockets, HTML5 audio & video, history.pushState, and several other features. And components (custom elements + Shadow DOM) are coming, and already implemented in some browsers. Pretty much anything you could do in a native Windows app in 2007, you can do in a webapp now, except pwn your computer. Only problem is that the goalposts have moved: now everybody expects you to be able to do it on a phone as well, as well as access the camera, accelerometer (which you can do on the web, actually), contacts, calendar, and bluetooth hardware.
    - TheLogothete 11y ago
      Uhm... the DOM is single threaded and sequential. It will never EVER be comparable to native clients.
      - nostrademons 11y ago
        Web Workers.
        TheLogothete 11y ago
        Yeah man. I've never heard of those. They sound like the best thing since sliced bread. Only if they could access the DOM... Seriously... what are you even talking about? Why do you even mention them? You read single threaded and thought "Quick, I must come up with an answer! I can't let a stranger on the Internet change my opinion!"?
        nostrademons 11y ago
        So, it's hard to understand exactly what it is you're trying to accomplish and why Web Workers wouldn't work for you because basically every single desktop GUI framework is single-threaded when it comes to actually updating the components on the screen. Win32 uses the GetMessage/TranslateMessage/DispatchMessage event loop. Swing has the UI thread, and then to update the UI from a background thread, you need to call invokeAndWait or invokeLater and pass a Runnable. Cocoa and iOS have Grand Central Dispatch, and to update the UI you pass a block to dispatch_async on a dispatch queue. Android has you call View.post() with a Runnable that contains your UI modifications. WPF has two threads, a rendering one and a UI thread, and you're supposed to pass long-running operations off to a threadpool and then call Invoke or BeginInvoke with a delegate to actually update the UI from them. Web Workers are exactly this model, applied to the web. It's a dispatch queue running inside a threadpool. To update the DOM, you postMessage back to the UI thread and make your modifications there. Are you willing to let a stranger on the Internet change your opinion?

vram22 11y ago

>I have no doubt that the web will eat desktop application I hope not. There's nothing like a well-done desktop GUI EXE for richness of UI / UX. And desktop GUI apps can still connect to back-end services over HTTP or other technologies.

manyxcxi 11y ago

The thing is, with the ML code or the code for robotics that I've written over years, it's been predicated on the fundamentals of software development I've learned doing everything else. Good habits are good habits, disorganized code is disorganized code. In some ways all the C/C++ I've written for my various robots and gadgets have been easier than even web development UI code because my button is LITERALLY a button, my screen resolution is a 2 row LCD, and I'm designing the system my code will run in. Don't get me wrong, I'm half kidding, but my point is that a good developer is a good developer in whatever area of development they want to work in. You take a good web app developer and move them in to robotics, they'll be good quickly. At first they're obviously not as familiar with the domain, so there is a curve. But they will get strong eventually- assuming the EE side of things doesn't drive them away.

seren 11y ago
I agree with your point. When I said "development skills" it was not a judgement about talent, rather about "body count".
- manyxcxi 11y ago
  Ah, that makes sense and I definitely agree. The ability to write code in a decently maintainable fashion will certainly be necessary in fields that it wasn't and new fields entirely. The upside for people that do this, as I alluded to, is that if you have these skills and want to do a new thing in a new field, it's an option. Things like SO will help you play with the new thing in the new field where you might otherwise not have any help.