I expect Microsoft to drop Windows Phones in the next 2 years, unless it rebounds, it doesn't make financial sense to continue investing in the platform.
It's interesting that the OS is not really a separate thing, after the unification of Windows they did. So to a greater extent than Apple and especially Google, the software side of MS's phone project gets maintained "for free"?
The hardware on a Windows 10 ARM tablet is more or less the same (Snapdragon 835) as powers a mobile, only the screen is larger and they remove the app that makes phone calls.
There's even rumors that the Phone Call app will even show up on ARM tablets with SIM cards at some point, for people that like the "phablet" thing. (Which is hand in hand with the rumors/indications that Skype might eat the phone call app entirely and just light up SIM-based calling if the machine is capable, regardless of form factor, possible with inter-device VOIP communication like it manages SMS pass-through, when enabled, now.)
Err, the title is supposed to read "What Technologies Might Be Next [to bite the dust]?" I guess.
A replacement for timed/declarative animation on the Web is, of course, still needed (if for ads alone), but it looks like browsers/HTML5/JS libs are deemed good enough so instead of multimedia runtimes/engines we're going to see authoring tools.
Though audio/video sync and the state of SVG (and of SVG animation on FF in particular) leaves much to be desired IMO.
iOS lacks fork and kills your app if it doesn't yeild for some number of milliseconds. It also lacks a shell and a video terminal emulator which are kind of nice to have for these sorts of apps.
OP author here; in another blog post I explored the growth in questions about some cross-platform solutions. Ionic (now Ionic2) has been growing quickly, and React Native is among the fastest growing tags on the site. So you may get your wish!
Platform dependent apps will be here as long as the platforms will have different functionalities. And I hope that innovation in hardware space will not stall.
I'm not a Ruby/Rails fan at all, but I work at a Rails shop. It would be interesting to know why the decline is happening, and what alternatives are replacing it. I suspect Elixir and Go.
Bear in mind that this is about Stack Overflow attention. It's quite possible that there's now sufficient documentation and experience in the Rails community that there's just less requirement for interaction with Stack Overflow!
It also seems likely that newer developers are going to be steered towards other solutions for web development.
Well we have discussed this in other threads already :-).
That's the problem with Ruby in general that you can only solve certain problems with it.
Beyond Rails,devops and some obscure embedded stuff they do in Japan there is not much that you can do with Ruby.
Honestly I do not know. There was an article not long time ago mentioning that Ruby is not popular in Japan because of Rails but because it is used in a lot of places like embedded stuff etc.
I also work at a rails shop, but I'm a Django dev hired for a legacy project. rails has been much harder to pick up than other frameworks for me. I think my biggest difficulty has been figuring out how parts of the code connect/work together, by mechanisms like filename. Python is much more verbose in contrast.
I wonder if other people have the same experience.
I've been a ruby dev since way before rails, when it was considered "the language to build RPGs" (because of RPGMaker). Go is definitely the language I use the most, those days (go for the backend, react for the frontend). I still often use rails, though, it's not a pure replacement (I'll use rails when I want to quickly test an idea that does not require big frontend dev).
I also regularly work for a company that was full rails, and is now migrating away. In their case, they're going with nodejs (they have many developers, big turn over, and all devs seem to know javascript).
> How is react experience couple with Go for you ?
It just makes sense. Which is funny, because I got in both of them in a separate way. I didn't use angular because I didn't want to replace rails router with angular one. React allowed me to let it take control of just a part of the page, which was cool. My react components got bigger and bigger from there. I first started go because I wanted to parallelize huge background jobs. Then I started writing dev tools with it. Then small APIs.
At one point, I realized that my main objection about SPAs (I say "webclients", nowadays), which was that they could not be properly indexed by search engines, was irrelevant : all apps I wrote where behind auth, and landing pages didn't need a framework, static pages were perfectly good enough. So I started using react-router, and it made a lot of sense to use go : adding a few endpoints was small a task enough, and then I could write background jobs by just prefixing method calls with `go`, not needing complex process management (I still use queues, because I don't want to discard a job when I deploy and restart app).
The biggest challenge with go has been to "think simple", which is quite a shock when you thought it was already what you were doing with ruby. Initially, I used custom types a lot, and embedded types, and interfaces. And then I realized I was doing OOP all over again - and as with OOP, I didn't know where the methods I called were coming from (since then, I adopted a more FP-like style).
The biggest challenge with react has clearly been flux and redux. I started with big root components containing all business logic and passing callbacks around, which became a problem when frontend apps started to get big. So I tried flux and redux, but... They just introduce a lot of concepts and rigid structure that I felt were too much. So I just wrote my own flux lib, trying to keep it as conceptually simple as possible. I still write redux apps from time to time, because it's good for big teams and I have to be fluent with it to work with them.
But this was worth it. Today, I feel like rails is becoming what we initially were boo-ing java for : a lot of overcomplicated architectures that solve no real problems. It's not even rails fault, it's rails users fault. I know when I work on a rails project with other people that it will be overcomplicated (so, the controller is calling a service object which calls five other ones which call decorators calling models and then passing them to adapters which call serializers...). Rails itself tends to go that path too, since it's what their users are asking for (actioncable? No way. And I'm a big fan of websockets, so I'm sad to say that). With go, I get that feeling we had with early ruby and early rails : just get the job done. Of course, I don't expect that to last :)
Perhaps - I write mostly Go and a little Elixir at a shop that still identifies as Rails first.
On the other hand, the recruiter spam I get gives me the impression that JavaScript is the main thing taking mindshare away from Rails. Both because Node is popular and because there are now a lot of front end monoliths.
Even if rails is declining overall, it is still one of the frendliest beginner frameworks out there. If it lives on in practically every bootcamp curriculum as the go to framework which can be taught in 3 weeks flat, why will it be replaced? Or is that not enough to ensure the ecosystem stays afloat?
POTS over copper wire. AT&T is legally obliged to continue offering/maintaining it (in California at least), but they don't market the service and you have to specifically ask for it.
a lot of people aren't aware of the situation. AT&T is continually trying to get out of their obligation (in California at least).
The fewer people who use it, the better AT&T's argument for discontinuing service becomes.
In the event of a widespread disaster, people who can make a phone call are going to have better access to emergency services.
They are jacking the prices up on renewal. They wanted 4x the current rate on every POTS line we had unless we bundled another service like wireless (cellular), DirecTV, or GoToMeeting
yeah it's relevant as a dying technology. the article includes the iPhone on a graph, so it's not much of a leap to mention traditional telephone service.
that's unfortunate. I'm curious about the possibility of some other entity (cities, counties, local groups) taking control over the systems and providing cheap or free service. ham radio groups might be good at that.
It's got to be a bit more consumer-friendly than this (and retrofittable into existing house wiring including power supply), but yeah this is what I was talking about.
> It's got to be a bit more consumer-friendly than this
If the demand is there, I encourage you to build such a solution! The BOM should only be ~$30-40, maybe a bit more.
> and retrofittable into existing house wiring including power supply
This is simple. You simply disconnect the wiring on the outside of the house where the ILEC terminates their on-prem wiring, and plug this device in to the house wiring (this is usually how cable providers and other non-ILECS do it when they put equipment on prem to provide phone services over fiber or coax). You then battery back it with a lead acid cell.
Believe me, I've thought about it. There's a lot more to do than just designing the device. There's service components to the whole system as well (porting numbers, signing people up, subscriptions, E911 services, etc).
>You then battery back it with a lead acid cell.
Well you also need to pump it up to 90VAC for ringing. Again, more details but they are important ones.
You also have to understand when talking with AT&T that it has a separate account system and personnel, and the system tends to route you to their more popular offerings by default. Confirm with everyone you talk to that you mean a LANDLINE and that person has access to the landline support and account systems, or you end up with pretty crazy results, personnel claiming you don't have service calls, trying to identify your account and getting the closet match as some old closed one. Really a pain to get routed around for 45 minutes to get transferred back to someone who doesn't deal with landlines again.
My problem isn't with PDF itself, but that it's overused in places where it really doesn't need to be. Academic papers are the big one, where HTML would almost always be a better choice. What's even more maddening is that papers aren't written using Adobe's PDF tools, they're written in TeX and then converted.
If you're an academic reading this, I implore you to please publish your papers in HTML (alongside PDF is fine too!). It makes them far easier to read, as browsers can reformat the document according to the readers needs.
PDF is a type-setting format for ensuring print-accurate documents. Please stop publishing content that is meant to be consumed online in it.
PDF is an OK format - if you're targetting print. TeX is better though.
Unfortunately many aren't aware that CSS can help a lot with printing HTML documents, making the formatting nearly as nice as with PDF, but it takes a lot of tests to make this sure, especially with images.
I wonder is there are any simple CSS templates that are view AND print friendly, possible passed to Pandoc[1], so you write your HTML and it'll just work.
For CSS Paged Media there's Prince (fka PrinceXML and expensive) and wkhtmltopdf (F/OSS, Webkit-based), but while these are certainly good enough for printing of invoices from web content and casual documents (and even academic publishing), I doubt CSS Paged Media will ever match facilities of dedicated print tool chains such as FrameMaker etc.
Prince is based on a transcription of CSS to constraint logic (using the Mercury Prolog-like system), so I wonder if there's a formal specification of CSS that could be lifted into a Prolog specification to yield a CSS renderer for print (the only work I'm aware of in that direction was [1]).
You are right, there are a lot of businesses that rely heavily on PDF and a fairly large software ecosystem supporting them. It isn't going away anytime soon.
The way PDF is used currently prevents a lot of stupidity found in HTML documents.
In theory, well written HTML would be easier to read, but even on my phone I prefer PDFs because I know the page won't move around while I'm reading it or try to do some aweful interactive thing.
A better format would be markdown with latex for equations (and maybe the bibliography.) It's portable, readable, and not a typesetting format. Plus it means paper authors don't have to worry about all the page formatting. All of the blogs already use this anyway.
I was thinking of doing some post-processing on arxiv PDFs, and as it turns out a lot of papers include the original TEX sources. Sadly, this isn't the case with the final published papers elsewhere.
(La)TeX is great when you don't want to manually handle formatting your text. I loved writing LaTeX for the simple reason that I could focus on the content, rather than having to constantly work on the presentation. The markup was simple enough that it did not get in the way.
Barring technical problems I much prefer LaTeX to Word or LibreOffice Writer.
Yes -- biology is 100% Word (some bioinformatics is done in LaTeX), and there is a whole industry of commercial products like EndNote which exist to handle citations and bibliographies in Word. Which is really weird. You'd think Microsoft would have added bibliographic management by now.
So long as the standard form of journals remain printed, PDF really is the best format for academic papers -- because you want a reprint to exactly copy the journal pages including page numbers -- it's basically like photocopying papers from journals (which is what we used to do prior to the mid 1990s).
What about CSS preprocessors and grid frameworks? SASS/less and Bootstrap are heavily used right now and I like using them, but I can see the end of the road with CSS 4 variables and CSS grid (if not with flexbox already).
Is questions asked really a good metric? StackOverflow actively discourages asking duplicate questions, and all the easy newbie questions haven't changed in a while, it seems inevitable that certain technologies appear to decline. I feel like traffic to questions, searches or other metrics would be a better indicator.
In particular, is facebook api usage really in decline? I'd be very surprised. For language/platform specific technologies, I would imagine if there were a decline the market for devs would get less tight. I'd argue that days a vacancy is open is a much better indicator than even raw number of job postings.
This is a question I usually ask too when I see those used in articles to evaluate a tech's popularity, but for the first time (afaik), it has been addressed in this article, in the section "Do question visits tell a different story?". Spoiler: they do not.
No metrics are perfect, this is a good one I think for trying to get at developer mindshare. Actual API usage (number of calls) I think is not useful at all. If heavy volume is concentrated in a declining number of apps using the Facebook API (just an example, I don't know) I think API usage can go up while mindshare is dropping.
Is questions asked really a good metric? StackOverflow actively discourages asking duplicate questions, and all the easy newbie questions haven't changed in a while, it seems inevitable that certain technologies appear to decline.
This is addressed in the article. There have been 1.4 million javascript questions asked and the pace is increasing, which indicates that it's hard to exhaust a subject.
I think it makes sense facebook api usage is in decline given that the game devs have moved away from it.
I also don't think days a vacancy is open is a good metric, because having been on the hiring side of trying to find Delphi developers I can assure you it is very tough. Plenty of people have relevant experience, but none of them want those jobs because they think it is career suicide.
It's a pity to see asp.net decline, MVC is really nice with great IDE support. If it's due to webforms dying then it's great news. It still angers me how webforms wasted my time as a junior developer thinking it was my lack of skill that made any page beyond the trivial extremely hard to build.
Again, with questions as a metric, this could not necessarily be viewed as a decline but more as a maturation. Wouldn't you expect less React questions in 7 years or so as well?
MVC is awesome, .net core will probably be awesome as well when it gets more production ready. We use it a lot, though we also still doing a lot of webforms.
Potential hires don't know or want to do razor though, and if you're doing angular/vue/react you're using web-api and then you might as well use a backend with a better time to market anyway.
.NET does a lot of things right, but then you suddenly need to do a SAML SSO component for your ADFS and it's more terrible than basicaly everything.
Before, I used to hate MS and .NET. Today I work as a .NET dev and love C# and .NET.
Honestly, I think the moves MS is doing right now is the correct ones. With .NET Core a lot of the "heavy" stuff has been liften away and projects can easily be run on any big OS.
I think we will soon see a rise in the use of ASP.NET. The productivity levels you get by using .NET and Azure is just insane.
MOAI gives me everything that Flash gave me, but I have better (full) control over the stack, what goes into it, how its used, etc.
And then I just compile it all to Javascript and voila! No distribution hassles (except where I want it: i.e. when delivering to iOS/Android app-stores..)
I think JavaScript could be salvaged if, let's say starting with ES8, the new version would be incompatible and old scripts would require some legacy mode. That would allow fixing the major issues.
The problem isn't so much with JavaScript as it is with the JavaScript mentality - that is not to say JavaScript doesn't have a ton of problems.
No, the real problem is the mentality of cranking out new frameworks instead of actually building something useful on top of existing ones. Every year, the JS framework of choice changes to something new and you have no choice but to move on because the one you were using until recently has suddenly been dropped as the developers have moved on to the backwards incompatible next version.
And then there is the mentality of writing libraries for the most trivial of tasks - left padding, seriously?
Javascript would benefit from something like boost. Not in a sense of a library because that already exists with lodash and underscore and what not. But in the term of community and acceptance: "Yes, boost is bloated and not always ideal, but it is almost always a better choice than reimplementing the thing"
Then the proposal of the comment you are replying where he wants to start from scratch is great. How I wish Javascript has a great standard library(like Python).
I'm not sure I agree about Java if for no other reason than you can just avoid it if you want to.
JavaScript, on the other hand, is compulsory for the web. It's probably our industries biggest failing and I wish we would just stop polishing that turd.
Uh, not sure if you're referencing a joke or something, but just to make sure no one gets confused by your post: JS absolutely is turing complete, as is trivially demonstrated by implementing a turing machine in JS.
About Bootstrap: I, too, have questioned the viability of grid frameworks and CSS preprocessors here when we have CSS grids and variables, but I think Bootstrap is such a useful thing for a split designer/developer workflow that it'll live on and eventually converge into using CSS grid directly in a couple years.
Bootstrap team has made slow but steady progress over the last few weekends and is working on documentation issues, so it looks like a new release is imminent.
XHTML and everything associated with it. Well okay, it's probably already considered dead, since HTML 5 has replaced in it about 95% of contexts.
Turns out most people didn't want a web where a single syntax error could bring down a web page and went to the more relaxed HTML 5 the minute it was released.
And while they won't die as far as their main purpose is concerned, I suspect webfonts will become a lot less popular in future. The idea of using them for icons has turned out to be a non semantic nightmare that's best done with SVG or plain old images instead. So the likes of Fontastic may not be long for this world...
You're on to something. The xhtml fiasco has a lot of parallels to Flash, when you consider the ECMAScript history and its relation to ActionScript's evolution.
105 comments
[ 8.8 ms ] story [ 169 ms ] threadA replacement for timed/declarative animation on the Web is, of course, still needed (if for ads alone), but it looks like browsers/HTML5/JS libs are deemed good enough so instead of multimedia runtimes/engines we're going to see authoring tools.
Though audio/video sync and the state of SVG (and of SVG animation on FF in particular) leaves much to be desired IMO.
I think "needed" and "ads" should not go into the same sentence...
My vote goes to Platform-Dependent Apps.
It's very intellectually unfulfilling work.
https://stackoverflow.blog/2017/05/16/exploring-state-mobile...
It also seems likely that newer developers are going to be steered towards other solutions for web development.
Now that's a story I want to hear. Any pointers?
http://engineering.appfolio.com/appfolio-engineering/2017/5/...
[0]: https://insights.stackoverflow.com/trends?tags=django%2Celix...
I wonder if other people have the same experience.
I also regularly work for a company that was full rails, and is now migrating away. In their case, they're going with nodejs (they have many developers, big turn over, and all devs seem to know javascript).
Of course, that's just two experiences :)
It just makes sense. Which is funny, because I got in both of them in a separate way. I didn't use angular because I didn't want to replace rails router with angular one. React allowed me to let it take control of just a part of the page, which was cool. My react components got bigger and bigger from there. I first started go because I wanted to parallelize huge background jobs. Then I started writing dev tools with it. Then small APIs.
At one point, I realized that my main objection about SPAs (I say "webclients", nowadays), which was that they could not be properly indexed by search engines, was irrelevant : all apps I wrote where behind auth, and landing pages didn't need a framework, static pages were perfectly good enough. So I started using react-router, and it made a lot of sense to use go : adding a few endpoints was small a task enough, and then I could write background jobs by just prefixing method calls with `go`, not needing complex process management (I still use queues, because I don't want to discard a job when I deploy and restart app).
The biggest challenge with go has been to "think simple", which is quite a shock when you thought it was already what you were doing with ruby. Initially, I used custom types a lot, and embedded types, and interfaces. And then I realized I was doing OOP all over again - and as with OOP, I didn't know where the methods I called were coming from (since then, I adopted a more FP-like style).
The biggest challenge with react has clearly been flux and redux. I started with big root components containing all business logic and passing callbacks around, which became a problem when frontend apps started to get big. So I tried flux and redux, but... They just introduce a lot of concepts and rigid structure that I felt were too much. So I just wrote my own flux lib, trying to keep it as conceptually simple as possible. I still write redux apps from time to time, because it's good for big teams and I have to be fluent with it to work with them.
But this was worth it. Today, I feel like rails is becoming what we initially were boo-ing java for : a lot of overcomplicated architectures that solve no real problems. It's not even rails fault, it's rails users fault. I know when I work on a rails project with other people that it will be overcomplicated (so, the controller is calling a service object which calls five other ones which call decorators calling models and then passing them to adapters which call serializers...). Rails itself tends to go that path too, since it's what their users are asking for (actioncable? No way. And I'm a big fan of websockets, so I'm sad to say that). With go, I get that feeling we had with early ruby and early rails : just get the job done. Of course, I don't expect that to last :)
On the other hand, the recruiter spam I get gives me the impression that JavaScript is the main thing taking mindshare away from Rails. Both because Node is popular and because there are now a lot of front end monoliths.
Node.js, and front end JS frameworks.
a lot of people aren't aware of the situation. AT&T is continually trying to get out of their obligation (in California at least).
The fewer people who use it, the better AT&T's argument for discontinuing service becomes.
In the event of a widespread disaster, people who can make a phone call are going to have better access to emergency services.
http://www.chicagotribune.com/business/ct-att-landline-end-i...
IMO what's needed is a product with a simple cellular voice modem that plugs into the telco interface box and simulates the legacy landline service.
http://www.portech-us.com/
It's called a cellular analog gateway.
If the demand is there, I encourage you to build such a solution! The BOM should only be ~$30-40, maybe a bit more.
> and retrofittable into existing house wiring including power supply
This is simple. You simply disconnect the wiring on the outside of the house where the ILEC terminates their on-prem wiring, and plug this device in to the house wiring (this is usually how cable providers and other non-ILECS do it when they put equipment on prem to provide phone services over fiber or coax). You then battery back it with a lead acid cell.
>You then battery back it with a lead acid cell.
Well you also need to pump it up to 90VAC for ringing. Again, more details but they are important ones.
My problem isn't with PDF itself, but that it's overused in places where it really doesn't need to be. Academic papers are the big one, where HTML would almost always be a better choice. What's even more maddening is that papers aren't written using Adobe's PDF tools, they're written in TeX and then converted.
If you're an academic reading this, I implore you to please publish your papers in HTML (alongside PDF is fine too!). It makes them far easier to read, as browsers can reformat the document according to the readers needs.
PDF is a type-setting format for ensuring print-accurate documents. Please stop publishing content that is meant to be consumed online in it.
Unfortunately many aren't aware that CSS can help a lot with printing HTML documents, making the formatting nearly as nice as with PDF, but it takes a lot of tests to make this sure, especially with images.
I wonder is there are any simple CSS templates that are view AND print friendly, possible passed to Pandoc[1], so you write your HTML and it'll just work.
[1]: http://pandoc.org/
Prince is based on a transcription of CSS to constraint logic (using the Mercury Prolog-like system), so I wonder if there's a formal specification of CSS that could be lifted into a Prolog specification to yield a CSS renderer for print (the only work I'm aware of in that direction was [1]).
[1]: https://lmeyerov.github.io/projects/pbrowser/pubfiles/extend...
In theory, well written HTML would be easier to read, but even on my phone I prefer PDFs because I know the page won't move around while I'm reading it or try to do some aweful interactive thing.
A better format would be markdown with latex for equations (and maybe the bibliography.) It's portable, readable, and not a typesetting format. Plus it means paper authors don't have to worry about all the page formatting. All of the blogs already use this anyway.
Barring technical problems I much prefer LaTeX to Word or LibreOffice Writer.
In particular, is facebook api usage really in decline? I'd be very surprised. For language/platform specific technologies, I would imagine if there were a decline the market for devs would get less tight. I'd argue that days a vacancy is open is a much better indicator than even raw number of job postings.
This is addressed in the article. There have been 1.4 million javascript questions asked and the pace is increasing, which indicates that it's hard to exhaust a subject.
I think it makes sense facebook api usage is in decline given that the game devs have moved away from it.
I also don't think days a vacancy is open is a good metric, because having been on the hiring side of trying to find Delphi developers I can assure you it is very tough. Plenty of people have relevant experience, but none of them want those jobs because they think it is career suicide.
Currently I am working with Mongoose and MongoDB. All the answers I find in StackOverflow are more than 2 years old.
Potential hires don't know or want to do razor though, and if you're doing angular/vue/react you're using web-api and then you might as well use a backend with a better time to market anyway.
.NET does a lot of things right, but then you suddenly need to do a SAML SSO component for your ADFS and it's more terrible than basicaly everything.
Honestly, I think the moves MS is doing right now is the correct ones. With .NET Core a lot of the "heavy" stuff has been liften away and projects can easily be run on any big OS.
I think we will soon see a rise in the use of ASP.NET. The productivity levels you get by using .NET and Azure is just insane.
You don't need to run Azure?
People did see it! That one was easy. You couldn’t convince Flash users.
Anyway, save yourself some time and skip the debate. It really wasn’t worth it.
Specifically, MOAI: http://getmoai.com/
MOAI gives me everything that Flash gave me, but I have better (full) control over the stack, what goes into it, how its used, etc.
And then I just compile it all to Javascript and voila! No distribution hassles (except where I want it: i.e. when delivering to iOS/Android app-stores..)
No, the real problem is the mentality of cranking out new frameworks instead of actually building something useful on top of existing ones. Every year, the JS framework of choice changes to something new and you have no choice but to move on because the one you were using until recently has suddenly been dropped as the developers have moved on to the backwards incompatible next version.
And then there is the mentality of writing libraries for the most trivial of tasks - left padding, seriously?
JavaScript, on the other hand, is compulsory for the web. It's probably our industries biggest failing and I wish we would just stop polishing that turd.
Over longer term: proprietary mobile app development platforms (windows phone, apple ios, android).
All replaced by client side JavaScript.
jquery UI. Jquery still has some use in banging out a quick page but it too is no longer essential
Also possibly Bootstrap. What the hell is going on with development there?
Bootstrap team has made slow but steady progress over the last few weekends and is working on documentation issues, so it looks like a new release is imminent.
Update: https://news.ycombinator.com/item?id=14926640
Turns out most people didn't want a web where a single syntax error could bring down a web page and went to the more relaxed HTML 5 the minute it was released.
And while they won't die as far as their main purpose is concerned, I suspect webfonts will become a lot less popular in future. The idea of using them for icons has turned out to be a non semantic nightmare that's best done with SVG or plain old images instead. So the likes of Fontastic may not be long for this world...