Rust is seeing production use in many places and its being accepted more as the sane alternative to C for modern development of high performance software. Ecosystem still not big or mature enough to make big waves, however, but that depends on how you interpret "big waves".
SPAs are used and abused, the tooling to make a performant progressive website with them has gotten better but the know-how is not widespread enough.
React has essentially won the mindshare battle and they are focusing more on functional components. But there are other things with their own healthy niche like Svelte compiling components that manage their own DOM, Elm is still around (and still not 1.0) and it has inspired other "Elmish" frameworks.
Desktop software quality has gone downhill and seemingly everyone is using Electron.
For many companies, Kubernetes is the new normal mode of operation. You should know it, but it's still far from "the way to do things" for industry in general, mostly due to its complexity and learning curve.
Casually job hunting right now, and it is insane how much React has won to me. Like I knew it was popular, but it seems like it has an outright monopoly with the remaining 5% of market share being split among all the other alternatives.
I don't know what the actual market shares are, but when looking at open positions around the US from coast to coast, it seems to have won.
React is currently in it's honey-moon phase, but many of its warts are starting to show. It probably has another year or two before peaking, but doubtful that such a large heavy-handed library will remain dominant forever.
Also doubtful? What about Java?
Not quite there yet.
Whatever its benefits, Rust remains quite obscure for now.
I'm looking to learn a front-end framework and had a few people recommend Vue. Sounds like maybe I should go for React instead? In case it matters, I'm not looking to be a front-end developer. I'd mainly like to improve some small projects I have. And get the most value out of my time learning a framework.
And we still like Vue a year later. It integrates well with the rest of our site, much of which still has not been rewritten in the functional-reactive style yet. And not having to do a full-on transpile/build step during development is a huge win for reducing cycle times.
I’d use vue if not for svelte, probably.
Svelte's reactivity was also something we had in Splash, the Microsoft-internal UI framework that was used to build the Zune desktop app and Windows Phone 7/8. I haven't enjoyed building UI since then, but with Svelte I can finally enjoy frontend development again.
One thing I don't like about React is that there are so many ways to skin a goat. We write functional components, and while I like them, this instantly makes half of google search results at least slightly irrelevant. However Vue is kind of doing this as well with the Vue 3 syntax change with backwards compatibility.
TL;DR
For resume building + career growth -> learn react
For quick and dirty side project -> use vue
For future proof / bleeding edge understanding -> use webcommponents
If there's one thing I got from these responses, is that I should look at Kubernetes.
Thank you for your answer.
The unfortunate ones that don't manage to move from it will be maintaining 5 year old kubernetes installations.
Kubernetes solves a huge variety of problems with a single platform. In five years, Kubernetes will still be around, but there will be layers built on top of it that simplify common use-cases.
The main problem comes when something breaks and building another abstraction layer on top of it won't help.
I haven’t done much web development in several years myself.
Typescript is mentioned a lot on HN. Saw ReasonML mentioned recently. Vue.js has a movie on the way.
As far as Web frameworks go, what’s popular seems to change every couple years.
The smaller-community frameworks are mostly interesting because they’re not React (i.e. they purposefully target different scopes, niches). The de facto standard framework for component-oriented front end development has been React for a while now. Typescript (which you see mentioned) complements react, it isn’t a component framework that aims to replace it.
K8s has its complexities for sure, but to me it's the simplest - or at least 'only figure it out once' way of running multiple machines (besides having 'the webserver', 'the db server' etc., of course.)
Docker is for building a computer program to run on a single computer.
Kubernetes is for building a cluster, often across many computers with many programs.
They work together.
Rust ranks lower than Delphi on TIOBE, isn't used in a single aerospace, defense, or critical application. Ada has been for almost 40 years, is backward compatible to Ada '83, and has a proof subset (SPARK).
Those waves look more like pond ripples caused by a light breeze.
How about, "Rust - now with bigger pond ripples."
as well as adjust the query for programming-specific engines like GitHub. To have a programming language index not even consider github or stackoverflow as primary sources makes it a laughing stock IMO
AWS has started to take on third-party, open source components e.g. Cassandra, ElasticSearch, MongoDB as they run out of things to build. Expect them to continue further up the stack possibly into applications.
Kubernetes has really taken off with every cloud provider having a solid implementation. And it's getting massive adoption within the enterprise as companies look to reign in their cloud cost, simplify their infrastructure and have better DevOps. It also allows them to standardise the NFRs across multiple applications e.g. metrics, logging, security, routing which is more important than ever.
Data Science has seen massive adoption in the last few years within the enterprise space as companies go after the low hanging fruit. Also seeing lots of traditional Data/Reporting Analysts been cross skilled in Data Science and vice versa. It's definitely here to stay for the long term just without the hype.
I'm aware of their Elasticsearch and MoongoDB offerings but what is their Cassandra offering?
AWS is still eating the world, Azure is doing well and growing faster in enterprise markets but devs still hate it, GCP seems mainly startup and ML loads and they have an ultimatum to become top 2 or bust by 2022.
Open source is a little under fire. AWS made a closed source MongoDB clone. I feel like things have moved a bit away from DIY toward settling on whatever the big three provide.
JS framework overload has settled down and it's pretty much React and Vue. NoSQL has too, there's still mostly the same players as in 2017 but I'm seeing far fewer new entrants. In general I'd say things have slowed down as a whole, and the level of innovation isn't what it was a couple years ago. Shiny new object fatigue has set in a bit and people just want to make things work.
Docker in production is very real (our team uses docker in production only, not dev), and k8s has the mindshare.
ML is still fairly hot, but various experts saying we're starting to hit a wall wrt ML capabilities, and others saying plow forward and see.
Really? While I've heard of a lot of experiments and a few companies using it in production, I'd hardly call it "mainstream".
My eyesight is becoming worse, but I read that as Perl
I'm legitimately asking because I'm pretty sure there is almost no functionality in Python that isn't in Perl.
In fact of the features I've read about that changed between Python 2 and 3, all of them remind me of a change in Perl. Except Perl didn't break old code in the process.
BigQuery is hot everywhere (I'd rank it as by far the most valuable GCP product). Tons of enterprises are AWS except for when they replicate their entire dataset from S3 to GCS so their BI teams can use BigQuery.
Should look at BPF/eBPF. Mainly bcc & bpftrace packages that come with ~70 tools out of the box.
Examples of the kind of tooling built by the community that betrays the cultish appeal of Laravel (yep, people actually make a living off Laravel-specific tooling)
What an incredibly strange framing.
I feel like a peasant sharecropper when I use Java.
The more familiar slight is that it's 'the language of choice for script kiddies', but I suppose they've grown up and gotten apprenticeships.
And that's pretty well borne out by its history, and is part of PHP's enduring appeal to many people who don't have formal educational backgrounds in the computing sciences.
- fully interpreted
- very weakly typed
- highly applicable to a broadly desired use case, i.e Personal Home Pages (hence the name PHP)
It's not too different from what made Excel such a broadly accessible and impactful 'programming' tool.
You realize Vue.js is fundamentally an SPA framework, right? It's got built-in router, state management, etc. In frontend dev, those are all things that are only SPAs really need.
To people "suspicious" of SPAs: are you suspicious of Gmail? Slack? Those are typical use-cases of SPAs. What you're actually suspicious about are ill-informed devs building SPAs when they should be using simple static websites, or server-side includes, or simple progressive enhancement in vanilla JS. But none of those options are practical if you want to build something like Slack, GMail, or Google Docs, or any of the myriad other desktop app replacements we find now on the browser.
All the said, I agree that Laraval looks like an attractive framework. I haven't had the chance to work in it professionally, and probably never will, but it looks solid and with the improvements PHP is making as a language, probably would be totally tolerable and perhaps even enjoyable to work in.
EDIT: Ok, the router and state management are official, but not built-in. Fair enough. I've not used VueJS professionally before (only React, AngularJS, Backbone, and custom frameworks before them) but it's one of the appealing things about VueJS compared to React, which seems to be its major competitor presently.
I had no idea. I've only used React, Angular, Backbone, and custom frameworks at work (mostly React in recent years), but I like what I've seen of VueJS because of its "batteries included approach" (which is React's weak point, although they seem in some ways to be moving toward being a full framework).
VueJS seems about as different from jQuery as you could get. I mean, it's even got a virtual DOM.
The closest thing you could get to jQuery? Modern, vanilla JS, whose recent APIs were often inspired by jQuery. But the jQuery crowd vehemently rejects that option because their idea of vanilla JS is stuck in the year 2010.
Microsoft bought GitHub and LinkedIn.
Oracle is disliked like before.
Relative to other frameworks, ASP.NET Core is sort of like the tooling maturity of Java (great editor/libraries, rock-solid VM, everything typed and static) combined with the simplicity / "start from scratch" feel of Padrino, Sinatra or Flask, with the expressiveness of a really nice language with type inference, good functional primitives (e.g. LINQ). You can probably serve hundreds/thousands of customers on a single Heroku dyno or three due to extremely robust non-blocking I/O, faster code execution, and much better memory management than Python/Ruby.
Give it a shot. I really like it.
Probably just a bias in my circles, as we're heavy OSS users and contributors..?
The universal availability of debugging and intelligence in all relevant editors (Code, Atom, vim, emacs, etc) through the LSP and the related debug protocol make things easy.
https://openai.com/blog/gpt-2-1-5b-release/
https://talktotransformer.com/
https://github.com/openai/gpt-2
(GPT-2 docker image needs a version tweak to get it working)
and BERT:
Flutter is also coming in hard on mobile. Also not something I've had enough experience to comment on, but there's also little criticism, which suggests it's a good thing.
It was order-of-magnitudes easier than what existed when it was first released. IMO once CSS modules became common (around 2017 IIRC, so OP may not have known about it), that was when React won - we got fully-styled and functional web components for free.
JEE was somewhat disliked by many even at his peak, while react+ts seems to be beloved by most users :)
Personal biases are involved I'm sure. Ruby is fine, Rails is great, I just don't see it used very often.
On the other hand, I still see a ton of JEE being heavily utilized in a number of sectors. Ruby might have in the past taken over Java for small shops that basically create a frontend to a database, but I'd argue that was never true for the enterprise sector.
React is, from my perspective, an attempt to abstract away a lot of DOM, with the objective of decreasing the size of the solution space to common problems.
The idea is that two engineers working in two different parts of a company would write more or less the same code in react, whereas the jquery solutions would have been very divergent. React enforces patterns and makes it harder to write bad code. That’s the dream, at least!
I wouldn’t compare the two directly, they’re solving totally different problems. Jquery makes writing vanilla JS less verbose. React is more like an engine that’s written in JS and programmable with JS, with the goal of making browser code more composable and opinionated (wrt data flow).
Long answer is that they don't do the same thing. I think jQuery was an incredibly clever and durable library and became so ubiquitous that most of it's most valuable features got folded into the JavaScript and CSS standards and no longer require dependency on a library. React is a modern way of structuring components. It's a fresh learning curve, but it's actually pretty intuitive and very useful.
react is a compiles-to-plain-js framework for building data heavy complex applications in the web browser.
React has its own template language built into your functions, quite opinionated data flow paradigms, and tries to abstract all of the direct attacking the DOM away into passing pure data around.
JQuery gives you better tools for hitting the DOM, but still is just a set of tools, not a development methodology.
This is simplified, obviously, but trying. :-)
In 2010 terms: let's say you want to write a web app. jQuery : your library of useful PHP functions :: React : Ruby on Rails. That analogy breaks down in many obvious ways (React isn't MVC and [modulo JSX transpilation and whatnot] uses the same language as jQuery, Rails is not easy to reason about especially if you're in 2010 and method_missing isn't considered harmful yet), but hopefully the basic idea comes through - library of functions vs. very opinionated framework that facilitates rapid development.
jQuery: Add some javascript features like ajax/animation/some DOM manipulation to a (dynamic/static) HTML page.
React: Create the dynamic HTML from scratch, that will still do ajax/animation etc.
Server-side React is a great way to generate HTML.
I could be misrepresenting from just what I’ve read here but trying to be helpful. Ymmv
How you do that comes down to mostly a matter of preference with a smattering of "engineering".
Nothing new under the sun.
I don't think he ever caught on.
I've got to say, they sound totally believable. I'm not entirely convinced you're making a joke here.
1: https://pangolinjs.org/ 2: https://github.com/josephschmitt/Clamp.js/
The Javascript frontend scene almost literally exploded, in various ways.
Webasm got some serious traction. Old serious people like this, becuase it may eventually allow them to avoid the increasingly crazy javascript scene.
Computer vision (by means of machine learning/deep learning) got quite a bit easier to use, even if you're not a PhD in Computer Vision. Real-time inference from static photos is now easy. Real-time inference from video is still sorta hard/expensive, depending on your deployment target (embedded, backend).
Python people are still using Python even though it's dead slow.
A bunch of people moved from Java to Go and suddenly felt a lot happier.
SPA's are a pain in the arse. Usually close to twice the amount of code to avoid page refreshes. Usually the apps are way slower than a page refresh as well - with lots of JSON calls to get data that would be in one server side page load.
Yeah. It's infuriating.
I think a lot of people got burn when they adhered to the "i want to use just this thing for everything" mantra, which is pure illusion. And as with all illusions we tend to nurture, it will lead to a crash with the status-quo of reality.
This was also what happened with Javascript. If you used it as the script language that it is meant to be, everything will be fine.
The problem, as i understand it, is trying to follow the misguided and over-hyped steps of Java.
Is node.js dead yet?
Theres a difference between being a pioneer or an adventurer from being a fool who let their emotions turn technology akin to a religious cult.
Node.js, of course, can be a great tool, but only if you know when and where to use it (just like the demonized PHP, can be great and work like a charm, you should also know when to nevermind the boll..).
I'm an intermediate level web developer. I enjoy working with ReactJS-- I like that it's a framework and way of doing things.
1. manages to accomplish everything that I need to get done
2. has a huge community & huge amount of open source reactjs components available
3. is highly customizable
If one isn't going to use a modern, prolific SPA framework such as Vue/Angular/React, other options seem to be:
1. Vanilla JS (potentially a mishmash of vanilla JS + CDN/local js libraries)
2. jQuery
3. other jQuery-era frontend frameworks
ReactJS in my experience makes development faster, easier, better organized and more enjoyable.
> ReactJS in my experience makes development faster, easier, better organized and more enjoyable.
Maybe it makes development faster, but in my experience it makes debugging someone else's code a whole lot more difficult. CSS for example. It seems nice to define the style in the same file as the component code and it makes development a little bit faster. But when you have to debug, it's far easier to have styles defined in classic stylesheets in a different file rather than trying to track down the location of some dynamically generated CSS class. (I know as I have been degugging code that was written by an agency, and the CSS styles are defined in a mix of both React files and normal CSS).
From your list of benefits I don't see anything that couldn't be achieved with sever side rendering and a bit of jQuery. If your front end needs to have a lot of user interaction, then SPA's will be the correct tool for the job. For most web apps they are overkill.
The React frontend we have at my current workplace is incredibly bloated compared to a similar complexity website I created using Django and Jquery. Doing certain simple tasks is like pulling teeth.
For example, React is meant to build small components not SPA. But you can build a SPA using react-router. But you can build SPAs using vanilla JS as well.
The only thing that truly defines SPAs is lack of “true” page changes. JS is taking control of your browser url bar and history. Which I personally dislike.
React is meant to build (composable) user interfaces.
Why do we need frontend routing?
Cool.
What's the worst thing about React?
Python/Django is a great choice for line-of-business/workflow applications where you have dozens or hundreds of users. If you're trying to be "web scale", then Java or Go are probably better choices.
FWIW, neither Python or Ruby are speed kings, but I think that you'll find ruby is on par, or faster than Python in many benchmarks. It is Rails that is renowned for its slowness.
I had a go at my manager recently for letting people do technical tests then telling them they didn't have enough experience after. He could have worked that out before wasting their time.
- Stronger requirements regarding specific frameworks and languages.
Generically, five years ago it felt like you could be an all around good engineer in some domain and be a good candidate in an adjacent domain. Today, it seems that you need to be completely up to date on the language in addition to all the best practices, build tools, and _all-in_ on a very specific set of libraries and frameworks. A candidate with any deviation is rejected.
Economics tells us it's because of a tighter labor market but in a way it says to me there's less room for learning and creativity.
1) All day interviews. Seriously, I've had an 8 hour interview. They served me breakfast, lunch and dinner. This was after several other rounds of interviews.
2) Expecting me to perform "free work". I have had several companies insist that I create and submit "sample" projects. This is NOT simple stuff like FizzBuzz. The projects realistically take 20+ hours and are solving non-trivial problems. This is before you even talk to anyone.
3) It can take weeks or months to go through the process and finally get an answer: one way or the other.
4) Companies straight up lie about everything, from working conditions to performance expectations.
Everyone is data scientist. Load Excel into python? Data science. Divide x by y, and run some algo, data science and ML.
From this description, it sounds like nothing has really changed in the past 3 years. This could easily describe today.
There have been some shifts in the fighting JS frameworks though; Vue is a big rising star, has overtaken Angular and is now challenging React for the top spot. Angular is still used a lot, but I think it's on the way out. React is still strong. Typescript is becoming standard.
Server-side rendering is big, though. People talk a lot about static sites (which can still be dynamic), and serverless (which still has a server, obviously).
Rust is more than a cool project; I have no experience with it, but it sounds increasingly like the low-level language of the future. On the JVM, Kotlin is on the rise, has overtaken Scala and Clojure and is second behind Java.
They were probably equal in 2017, but now go seems to have far surpassed it in terms of server side relevance.
This month was the 25th anniversary of Delphi, but I guess that is not relevant for the industry.
Also, everyone has given up on chatbots. Voice assistants are increasing in penetration, but they're just defaulting to transactional modes and not conversational.
[0] A lot of JEE Frameworks heavily rely on reflection and other dynamic features that cannot be used in a native image.
Edit: And yes... the folks I was working with were excited at how much lighter-weight Spring Boot was compared to whatever it was they were using before. When I showed them a Go-based server just using net/http, they almost had a stroke!
Backend hottest: Rust, Graphql is gaining adoption at the enterprise level.
Edit: ML is still very hot but tough to get a job as a Data Scientist without actual experience.
you meant "nestjs"?
It's a server side rendered framework for React. It can also do static sites but doesn't have as many plugins as Gatsby JS, which focuses on static site building with React.
But I can see it being useful in the niche area of someone who needs to do server side rendering for performance (every millisecond to first render counts), while keeping the code simple by not having a second technology to do that rendering, and they need the same thing to be a SPA. Maybe a GMAIL type application? And again the user has to care - I don't care if I wait 10 seconds for my mail app to load as I'll be spending minutes in there once it does, and you've locked me in for other reasons anyway.
This might matter for SEO but to be honest you could just have a non-JS version of the same page which looks different for SEO purposes.
Next.js seems pretty hot, so I am probably missing something :-).
I'd rather not use JS on the server myself, so for my projects I'd either make a SPA with API backend and no server side rendering. Or just a classic "rails style" crud app with a sprinkle of JQuery.
I hope someone chimes in and tell me what I am missing and why to use Next.js other than "I only want to do JS and React for all the things."
See this discussion [1] with the response from rauchg (framework author and Zeit founder) outlining where they are heading.
This ability to easily mix SSG and SSR pages within the one project, the PHP-inspired philosophy of simple file-based routing for pages, and pre-configured babel / webpack with easy customisation are a few things that draw people into next.js dev.
Like anything that deals with reasonable complexity there are a bunch of concepts to understand, but once that happens next.js feels like a thin layer around "it's just react".
I particularly like being able to drop api functions with a standard req / res signature into `pages/api` to immediately have some server-side api endpoints available, which can be deployed to Zeit's now as Lambdas with minimal fuss. It significantly reduces the friction of thinking about and implementing front-end sites with custom api endpoints for whatever you're building.
Do you get type safety in Handlebars?
But... let's forget Handlebars because Typescript/ES6 allows you to write code like this:
mythings.map(thing = `<li>${thing.name}</li>`).join();
And the question is do I want to pull in not just React but Next.js and learn all of it's ways to do this? I think for a static site no.
Experiments with new "open source" licenses are unknown
Low code has entered the hype frey
Email me if you'd like some help debugging and stabilizing
It seems Kubernetes is often the wrong tool for the job. The industry, and even Google is starting to recognize that, e.g. Kelsey with his "Monoliths are the future" [1] statement.
That said, boy do I like Kubernetes... It is extremely complex, though, and often its deployment seems not to be justified.
Monolith / microservices is a separate conversation from orchestration. I have deployed both to Kubernetes for great benefit
So far I have seen little benefit.
Almost no one has a decent implementation for micro-frontends. Although ING bank released a nice framework related to this - https://medium.com/ing-blog/ing-open-sources-lion-a-library-...
React is performant now, so if I was you I'd take a good hard look at Clojurescript / Reagent / Porting those to React-Native.
And welcome back, good to hear your health problems are sorted!
Windows 7 and Python 2 are officially dead now :)
Ruby and Clojure are dead, literally for Clojure, most libs are from >7 years ago.
Javascript(and TS) and Python are the tools of the trade to achieve most common things.
Devs are starting to realize how they got fooled by Rust's marketing/hype train for general purpose programming/exploration/prototyping and productivity because it's too restrictive and its compile times are atrocious.
A more accurate Rust slogan:
A language empowering everyone to build reliable and efficient software at a very high cost.
Which is fine is you really need that efficiency.
Java's market share is still huge. Clojure never really had a big market share and Ruby is still very popular.
It seems to me Clojure ecosystem is in good shape, a lot of new libs keep coming out and there's a healthy & growing actively maintained set of libs. The Clojure way of data-centric APIs also means that stable libs don't need to be tweaked often to keep them working while the surrounding world changes. In the early days there were more hobby projects published and less serious use, currently the user base is more tilted towards inhouse business software. I grant that it would be cool if there were more stuff like Overtone or Quil from the early days happening now..
Java market share is declining but the JVM is still as good as ever. Instead everyone is moving to Kotlin and Scala.