The number of the language occurrences in August 2018 Who is hiring thread:
React 377
Python 306
Node 153
Ruby 118
Rails 113
Django 69
Just numbers to think about. It's not scientific in any way.
Is Rails still relevant in 2018?
291–300 of 346 posts
Re: Is Rails still relevant in 2018?
#292Earlier quoted context omitted.
> These days if your chosen language doesn't have things like strong typing, interfaces, good debugging tools, a good compiler, etc, then you should definitely be asking yourself if it's the right tool for the job. All of these things existed long before Ruby on Rails gained in popularity. Unless the popularity of Rails, Python, PHP, and Javascript was all just collective insanity, dynamic languages do offer benefits…
Python is a strongly typed language and language dynamism has no relationship to strong typing. you're likely thinking of static typing. With Python's type annotation feature as well as the work being done with MyPy, Python is also beginning to grow some static typing behavior as well.
First of all, zzzeek, thanks for your great software. While working on SQLAlchemy, have you ever run into situations where you really missed static typing? Do you ever see yourself wanting to introduce Python's static typing behavior into that project, and why or why not?
Re: Is Rails still relevant in 2018?
#293Earlier quoted context omitted.
For Rust, there's [1] for OpenGL and [2] for Vulkan. I don't know about Vulkano, but Glium is much more pleasant to use than the raw OpenGL API. [1] https://github.com/glium/glium [2] https://github.com/vulkano-rs/vulkano
The sentence in the top of the readme for the github repo is: "Glium is no longer actively developed by its original author." Which links to: https://users.rust-lang.org/t/glium-post-mortem/7063 Which pretty much states that Glium is not a really long term viable solution at the moment. I've toyed with cool open source libraries for 20 years. I'm too old to get caught up with something new and shiny only to find out…
Immediately after that, it says: "That said, PRs are still welcome and maintenance is continued by the surrounding community."
> Which pretty much states that Glium is not a really long term viable solution at the moment.
Except what that post-mortem is _really_ saying is that OpenGL is not a long-term viable solution. The whole post-mortem is about the fact that OpenGL drivers are so buggy that you can't write portable code to target it.
Re: Is Rails still relevant in 2018?
#294Earlier quoted context omitted.
> Web dev is in a different place now. Yup, but why? This is still true: > 97.2% of web projects were all about making an application server talk nicely to a relational database and then generating a front end that reflected the data model and that had javascript that Just Worked (everywhere).
> Yup, but why? Mobile and mobile-first thinking, perhaps. "webdev" is far more js-driven than it was 10-15 years ago. I'm not sure whether that's good or bad, but imo that accounts for much of the difference. 15 years ago I could build entire applications with a minimum of JS, and they were acceptable to clients. That's not really the case any more - there's more demand/need/expectation of js in web projects today.…
> there's more demand/need/expectation of js in web projects today
On the backend too?
There are headless Rails applications. Is that what you are talking about? If I understand it correctly, it's essentially a Rails server that exposes an API that a Javascript client uses.
Re: Is Rails still relevant in 2018?
#295Re: Is Rails still relevant in 2018?
#296Earlier quoted context omitted.
> ...jQuery, which in turn was supplanted by vanilla js actually becoming useful. jQuery is written in vanilla js so vanilla js can do anything jQuery can. I'm always irritated when people claim that vanilla js can't do something X can do.
It's hyperbole, but the point is that vanilla JS couldn't accomplish it easily without a lot of headache. Handling browser compatibility alone made jQuery extremely useful back when it first emerged.
It could be accomplished just as easily by writing your own function just as jQuery did.
My point is that such wording, as above, gave people the impression that jQuery was not javascript and you could not accomplish things in vanilla js. Such false impressions are still around today.
Re: Is Rails still relevant in 2018?
#297Earlier quoted context omitted.
I work in a lot of Django shops and my Ruby is nowhere near as good as my Python but I'll pick Rails every time if I'm working on a side project. Why? Because the development velocity when using it is unparalleled. I can have an MVP up orders of magnitude quicker than I can with Django/Flask/Twisted. You're absolutely right on the Admin interface and auth, but auth is a gem install away [1] and Django's admin won't f…
You might know Python but it sounds like you don't know Django very well. Django does have built in JSON support[1]. There's also Django Rest Framework[2], which while not built into the core, is well supported and hardly a burden to add. And finally, Django's "scaffolding" functionality is built around its models. You define your model as a plain Python class inheriting from Django's model class, and then the variou…
I fear you've contrived to miss both underlying points.
In order to access a JSON endpoint in Django, I need to install DRF, integrate it with Django, configure it, edit my urls.py and perhaps set up a serialiser. I won't detail the procedure in your first link because I think you very well know that is simply a response object with a crude serialiser and a content header set. The inclusion of both misses the point, which is that in Rails, I would simply navigate to /model-name.json (so in fact, yes, it is absolutely a burden to go through that when you compare the two). That's it. No parsing. No route configuration. No concerning myself with edge-cases unless I'm doing something odd. Requirement satisfied, and I can sleep soundly knowing I'm not bequeathing some custom car-crash on whoever inherits my codebase. Debate aside, I wholeheartedly encourage you to try out this framework sometime - I've found going from Django to Rails to be an absolute joy to develop with.
Generic Views. Ah. Well that has its own set of problems. Why am I wading through the docs (or more accurately ccbv.co.uk because the actual docs are a verbose, time-sinking miasma; recall that in my previous comment, I am championing the development-velocity of Rails in contrast to Django) to discover which method from which class I need to override to implement the functionality I need? I can intuit a lot more now, after doing this for years, but why do I need this knowledge at all? It is the job of the framework to abstract and ameliorate bullshit. Corollary: why is it that every Django codebase I inherit has at some point converged on its natural state of 'car-crash' because of the combination of a bunch of rigid inheritance chains and my predecessors not putting in an escape hatch? At risk of being a bit of a zealot, MI is almost always an anti-pattern and I would prefer the flexibility afforded to me by composing things in the traditional fashion.
In Rails, I would build a model like this in my shell: `rails g scaffold Blog title:string content:text`. That's again, literally it. From that, I now have a Blog model with title and content, created and updated fields, controllers (or 'Views' in Django parlance for some reason) and both HTML and JSON views ('Templates', in Django-land), unit tests, assets for my asset pipeline (we don't have to run collect static btw - it seamlessly transitions into production because it was designed on the basis that people might actually be deploying their projects), my equivalent of urls.py has been updated to accommodate my new model and I have full CRUD functionality at this point. Genuinely, I implore you to try this framework. Django has come a long way since I first used it but it's nowhere near the level that modern frameworks like Phoenix [1] (you should give this a go too - the third party libs aren't quite there yet but it's a really well thought-out framework) are at, and I'm genuinely curious as to why.
Re: Is Rails still relevant in 2018?
#298Earlier quoted context omitted.
I work in a lot of Django shops and my Ruby is nowhere near as good as my Python but I'll pick Rails every time if I'm working on a side project. Why? Because the development velocity when using it is unparalleled. I can have an MVP up orders of magnitude quicker than I can with Django/Flask/Twisted. You're absolutely right on the Admin interface and auth, but auth is a gem install away [1] and Django's admin won't f…
>Why are websockets ... not present in a 'kitchen-sink' web framework? They are. Django Channels: https://www.djangoproject.com/weblog/2016/sep/09/channels-ad...
Right. Last I checked it was being brought into the fold but it hasn't been - I still have to install a third-party library to get what is rapidly becoming a normal thing to have in a web-framework. My point was more "why isn't this in my kitchen-sink framework" more than "I don't know how I would go about integrating websockets in Django"
Re: Is Rails still relevant in 2018?
#299For whatever it's worth: at Matasano we saw more Rails apps from startups than any other framework. At Latacora that has changed dramatically; we see Django a lot, rarely Rails, but most commonly we see Go, Python, Node, and Java API servers with React frontends and minimal frameworks. From my vantage point: Rails is still relevant and still a viable option for building new stuff, but it is less relevant than it used…
I see the same trend on Indeed.co.uk. In the last year or so there have consistently been about 40% more Django roles than Rails in London. At Angel.co, however, Rails is still more popular. I put this down to the general increase in Python adoption rather than anything specific to Django.
Re: Is Rails still relevant in 2018?
#300For whatever it's worth: at Matasano we saw more Rails apps from startups than any other framework. At Latacora that has changed dramatically; we see Django a lot, rarely Rails, but most commonly we see Go, Python, Node, and Java API servers with React frontends and minimal frameworks. From my vantage point: Rails is still relevant and still a viable option for building new stuff, but it is less relevant than it used…
How does Laravel rank in there?
To my knowledge I've never been asked to look at a Laravel app.